| |||||||||||||
Python moratorium and the future of 2.xPython moratorium and the future of 2.xPosted Nov 12, 2009 5:56 UTC (Thu) by felixfix (subscriber, #242)Parent article: Python moratorium and the future of 2.x
I don't use Python much at all, it didn't seem to have any advantages over Perl, not that Perl is the best language ever... but good enough that Python held no interest other than curiousity in trying a new language.
However! I have tried to keep up with what is going on, and I got the distinct impression that the biggest problem with the 3.x branch was its lack of backwards compatibility. Perl6 looks to be taking even longer to come to life, but at least they have made provisions for compatibility packages, from what I think I remember reading, so that you could run perl5 packages in perl6 programs with at least mostly good prospects of succeeding.
If Python 2.x ---> 3.x really does have no compatibility provisions, if you really do have to run either 2.x or 3.x, and there is no way to include 2.x packages in 3.x, that seems incredibly brain dead to me. If there is no migration path, how are people supposed to migrate? I am serious in asking that. Was there any kind of plan for how people could switch from 2.x to 3.x? Were package maintainers supposed to maintain two versions of everything for several years? Were production developers supposed to maintain two versions of their code for several years? It all seems as if someone (BDFL?) had unrealistic ideas of how much spare time real life provides for such fantasies.
(Log in to post comments)
Python moratorium and the future of 2.x Posted Nov 12, 2009 7:18 UTC (Thu) by drag (subscriber, #31333) [Link] Last time I checked... Perl6 does not actually exist yet. It's been under development since 2000 or so and the ETA is 'sometime in 2010'. Meanwhile Python 3 is actually out and is usable. So forgive me if I choose true unicode support, cleaned up syntax, and proper handling of binary data over backwards compatibility with a non-existent-for-another-decade release. :)
Python moratorium and the future of 2.x Posted Nov 12, 2009 8:37 UTC (Thu) by ptman (subscriber, #57271) [Link]
Perl6 does exists. It's not ready yet, though. There is an effort underway
to create a somewhat stable release of rakudo (one implementation) called rakudo star in the spring.
Python moratorium and the future of 2.x Posted Nov 12, 2009 8:44 UTC (Thu) by chromatic (guest, #26207) [Link] Last time I checked... [Perl 6] does not actually exist yet. I've had working Perl 6 code running for four and a half years. Rakudo (a Perl 6 implementation) will have its 23rd monthly release in a row in a week. The Rakudo spectest status page has an informative graph which, I believe, addresses your ontological questions.
Python moratorium and the future of 2.x Posted Nov 12, 2009 13:54 UTC (Thu) by drag (subscriber, #31333) [Link]
So hows the backwards compatibility then? Can you just pull in Perl5 modules
from CPAN and have them work?
Python moratorium and the future of 2.x Posted Nov 12, 2009 20:34 UTC (Thu) by chromatic (guest, #26207) [Link]
That's a work in progress; a project called Blizkost allows some interoperability with Perl 5 at the Parrot level. (XS modules complicate things somewhat, as you might expect... but the Blizkost approach is clever.)
Python moratorium and the future of 2.x Posted Nov 12, 2009 22:17 UTC (Thu) by lysse (guest, #3190) [Link]
I believe "no" was the word for which you were reaching? (Possibly "not yet"?)
Python moratorium and the future of 2.x Posted Nov 13, 2009 19:58 UTC (Fri) by chromatic (guest, #26207) [Link]
I haven't tried it, so I can't comment authoritatively on what works and doesn't work.
Python moratorium and the future of 2.x Posted Nov 15, 2009 12:12 UTC (Sun) by IkeTo (subscriber, #2122) [Link]
> I believe "no" was the word for which you were reaching? (Possibly "not
> yet"?)
That depends on what the OP want. The design of Perl 6 definitely have backward compatibility addressed, at least so long as Perl extension module is not involved (i.e., there is no C code involved). The Perl 6 is designed to be based on a virtual machine (Parrot) that can interpret many different languages, Perl 5 is one of them. Then the Parrot engine can run many back-end languages at the same time, with objects of different languages cooperating in a fashion similar to Java dynamic language interface. Finally, the Perl 6 language is designed so that modules are distinguishable from Perl 5 modules by just looking at the first few tokens, so that the eventual VM can load a module and decide whether to use Perl 5 or Perl 6 back-end automatically. So the design is there, it's just an issue about when it actually enters implementation.
Python moratorium and the future of 2.x Posted Nov 18, 2009 17:37 UTC (Wed) by cptskippy (guest, #62050) [Link]
So if I understand all of this correctly, the Python 3 implementation that I can download and use today sucks because it lacks a feature that Perl 6 supported since it's inception 10 years ago and I should disregard the fact that I can't actually use this feature in Perl 6 because no one has ever been able to create a complete implementation of Peal 6?
Python moratorium and the future of 2.x Posted Nov 19, 2009 6:42 UTC (Thu) by lysse (guest, #3190) [Link]
I believe designs for time machines also exist.
Python moratorium and the future of 2.x Posted Nov 15, 2009 5:57 UTC (Sun) by b7j0c (subscriber, #27559) [Link]
whoah, someone made a big commit on 9/28!
Python moratorium and the future of 2.x Posted Nov 12, 2009 9:46 UTC (Thu) by niner (subscriber, #26151) [Link]
If Python has "true unicode support" then I'm very happy to work with some untrue
unicode support which actually works and is not as painfull...
But let's not start another language flamewar.
Python moratorium and the future of 2.x Posted Nov 12, 2009 14:07 UTC (Thu) by drag (subscriber, #31333) [Link]
I don't care about Perl vs Python or anything like that. To each their own,
but there are definitely good and practical reasons why 3 is not backwards compatible.
Anyways it's always been something normal to have multiple versions of
--------------------------
As far as unicode support goes it is not a issue of 'true' vs 'untrue'
Python moratorium and the future of 2.x Posted Nov 12, 2009 14:12 UTC (Thu) by felixfix (subscriber, #242) [Link]
And a language which exists officially but is not usable is better than a language which exists unofficially and is usable?
If a language exists but is unusable because it has no backwards compatibility, does it really exist? If said language emulates the tree in the forest by falling down, will anyone emulate listeners and hear it?
Python user here Posted Nov 13, 2009 23:38 UTC (Fri) by man_ls (subscriber, #15091) [Link] If Python 2.x ---> 3.x really does have no compatibility provisions, if you really do have to run either 2.x or 3.x, and there is no way to include 2.x packages in 3.x, that seems incredibly brain dead to me.My feelings exactly. Why should I "upgrade" to Python 3.x? My favorite libraries all work in 2.x, I know it more or less and it's what people know. I like Unicode a lot, but pervasive use of Unicode should not mean incompatible changes. To my little program it meant changing all str() to unicode(), all __str__() to __unicode__() and little more. If there was a way to mix 2.x libraries with 3.x code, then users would be able to migrate at their own pace, and once there is enough 3.x code out there new libraries would be written in 3.x. But right now, it looks as if the chicken-and-egg situation might strangle 3.x.
Python user here Posted Nov 14, 2009 0:08 UTC (Sat) by anselm (subscriber, #2796) [Link] The fun thing is that Tcl/Tk got Unicode essentially nailed more than 10 years ago (in version 8.2, to be exact), and transparently at that. None of those flag-day incompatibilities that seem to haunt the Python world. In Tcl there is no notion of separate »byte strings« and »Unicode strings«. Things just work. Most of the other languages that have been around for about as long (e.g., Perl or Python) are still struggling. People may not like the Tcl language a lot (it is a bit of an acquired taste, to be sure) but much of the underlying engineering is really very good indeed.
Unicode and Bytes Posted Nov 15, 2009 0:31 UTC (Sun) by pboddie (subscriber, #50784) [Link] In Tcl there is no notion of separate »byte strings« and »Unicode strings«. Things just work. Maybe they do. It's probably no accident that custody of Tcl was with Sun around that time (or slightly earlier) and that Java APIs also occasionally have byte sequences becoming proper strings with a sprinkling of magic, although I forget where this was - probably the Servlet API, where you mostly do want strings, but where deficiencies in the standards require a bit of guesswork to actually provide correct strings (and not just bytes) to the API user when they ask for a request parameter or part of a URL. Of course, there's nothing to stop you storing byte values in a Unicode string type: Jython managed to do this, too. But again, cross your fingers that the right magic is being used.
Unicode and Bytes Posted Nov 16, 2009 13:50 UTC (Mon) by kleptog (subscriber, #1183) [Link]
I find it interesting that perl 5.6 introduced Unicode everywhere internally and no-one had to rewrite a thing. Internally everything is unicode but you generally don't even notice. Except all those people who *needed* unicode support could write their programs and all the extension modules just worked (for the most part).
For example, chr() can now return numbers greater than 255, but that doesn't bother people so much. Your *source* will still be interpreted as latin1 but that doesn't bother many people since you don't usually need unicode in your source (I'm somewhat baffled by pythons "unicode" construct at source level, assuming the source was latin1 would have made transitions easier).
What mostly happened is that when you tried to send unicode data over a pipe or to a file, you got an error. People filed bugs, the appropriate encode() call was added (or "use bytes" if people wanted to punt) and all was well. The workaround was to encode prior to calling the module so it was no big deal.
There is magic under the hood ofcourse, see the perlunicode manpage, but the result is a completely transparent transition and is why at my work we run perl5.8 and python2.4, because python upgrades always break something (for zero apparent benefit).
Unicode and Bytes Posted Nov 19, 2009 12:19 UTC (Thu) by yeti-dn (guest, #46560) [Link] I find it interesting that perl 5.6 introduced Unicode everywhere internally and no-one had to rewrite a thing. Maybe in the US because US-ASCII is good for everyone there (with a few reluctantly admitting that ISO-8859-1 exists too). But I remember perl 5.6 release well exactly because it broke important programs (for me anyway) working with international text and reencoding it. Somehow, perl 5.8 managed to break them again. Then I stopped counting.
Python moratorium and the future of 2.x Posted Nov 15, 2009 5:50 UTC (Sun) by b7j0c (subscriber, #27559) [Link]
i would describe python3 and perl6 at almost exactly the same place in their development cycles. python3 may be "released" and blessed, its adoption is only tentative...everyone is in the same boat, they want to be part of the future, but the tool isn't done yet and certainly everything else in module-land is a long way from catching up.
afaik python mysql support isn't even on 2.6 yet...getting to 3.0 is going to be a while
|
|||||||||||||