Weekly Edition
Return to the Development page
| |||||||||||||
|
| |||||||||||||
Let's talk about Python 3.0
For those who are questioning the value of Python 3.0: James Bennett has
posted an interesting
discussion on why it is worthwhile. "It's rare that any
large/established software project manages to overcome this inertia and
actually take stock, figure out whether 'the way we've always done it' is
still a good way to do it, and then make changes in response. This week
Python 3.0 was released, and it represents one of those rare instances:
Python 3.0 was designed to clear up a lot of now-inertial legacy issues
with the Python language and figure out good ways to do things now instead
of unquestioningly sticking with what seemed like good ways (or, more
often, the least painful ways) to do things five or ten years ago."
(Log in to post comments)
Let's talk about Python 3.0 Posted Dec 7, 2008 1:18 UTC (Sun) by sbergman27 (subscriber, #10767) [Link]
Jens posts a response to James here:
http://mooseyard.com/Jens/2008/12/james-bennett-lets-tal...
And I want to highlight part of James' comment to that response, because I think it really hits the nail on the head:
"""
Python 3.0 signifies something good appearing on the horizon, and not an impending crisis of forced change. The sky is not falling. And I hope we don't see too many headlines like The Register's "Python 3.0 Appears, Strangles 2.x Compatibility".
Let's talk about Python 3.0 Posted Dec 7, 2008 4:02 UTC (Sun) by muwlgr (guest, #35359) [Link]
"... and runs 10% slower", yes :>
Python 3.0 is 10% slower Posted Dec 7, 2008 8:51 UTC (Sun) by smurf (subscriber, #17840) [Link]
They plan to implement optimizations for those in 3.1. The 3.0 focus was on a different problem set.
10% isn't too bad, IMHO.
Let's talk about Python 3.0 Posted Dec 7, 2008 10:16 UTC (Sun) by modernjazz (subscriber, #4185) [Link]
...but if you're doing serious computation you're using NumPy anyway...
Let's talk about Python 3.0 (offtopic) Posted Dec 7, 2008 21:40 UTC (Sun) by Frej (subscriber, #4165) [Link]
Very often it's actually fortran (in the physics world), although I'm sure some do use numPy.
Let's talk about Python 3.0 (offtopic) Posted Dec 8, 2008 14:11 UTC (Mon) by __alex (subscriber, #38036) [Link]
A lot of the NumPy/SciPy toolset is actually just wrappers for FORTRAN code.
Let's talk about Python 3.0 (offtopic) Posted Dec 8, 2008 16:46 UTC (Mon) by jordanb (subscriber, #45668) [Link]
Does NumPy give you access to IEEE flags? It always seemed to me to be a bit absurd that anyone would do number crunching in a language that hides important parts of the floating point hardware from you.
Let's talk about Python 3.0 (offtopic) Posted Dec 8, 2008 23:48 UTC (Mon) by njs (subscriber, #40338) [Link]
Yes -- it exposes the magic values NaN and the positive/negative infinities/zeros, plus you can specify error handling for the different IEEE exception conditions (ignore/warn/raise a python exception/invoke my custom handler -- though I haven't tested this part myself). You don't have quite as much control as in a low-level language, since you don't know exactly the 1-1 mapping between your lines of code and instructions the FPU executes, but if it really matters you can always write the relevant chunk in Cython or C or whatever.
Let's talk about Python 3.0 Posted Dec 8, 2008 2:14 UTC (Mon) by qg6te2 (guest, #52587) [Link] Sorry, using python with numpy etc as a base for implementing numerical algorithms is generally not advised. It's okay if the algorithm is simple (i.e. made up of a few calls to LAPACK / BLAS), but any more elaborate processing (i.e. using python code to manipulate matrix elements) causes the efficiency to go right out the window. One might as well use Matlab or Octave, which have richer functionality and a far more stable base. However, any serious number crunching work is either done in Fortran or, increasingly, C++.
Let's talk about Python 3.0 Posted Dec 8, 2008 2:44 UTC (Mon) by modernjazz (subscriber, #4185) [Link]
Of course (I don't use NumPy either...). But the original poster was
worried about the 10% slowdown on tasks that you wouldn't really be doing in regular Python anyway.
Let's talk about Python 3.0 Posted Dec 8, 2008 10:07 UTC (Mon) by joib (guest, #8541) [Link] Sorry, using python with numpy etc as a base for implementing numerical algorithms is generally not advised. It's okay if the algorithm is simple (i.e. made up of a few calls to LAPACK / BLAS), but any more elaborate processing (i.e. using python code to manipulate matrix elements) causes the efficiency to go right out the window.Yes, but there are multiple ways of calling C/C++/Fortran code for those critical loops while enjoying the productivity of Python for the rest of the code (assuming performance is important enough in the first place to be worth spending time on, of course). For a simple example comparing a few of the methods see e.g. Scipy/PerformancePython One might as well use Matlab or Octave, which have richer functionality and a far more stable base. Yes, matlab + toolboxes has a huge amount of functionality and good documentation, so it's no surprise it's wildly popular. But matlab-the-language is absolutely horrible, is not free software (octave obviously is but it's nowhere near matlab in terms of functionality and documentation), and the foreign function interface (MEX) is quite limited compared to what is available in the Python world. However, any serious number crunching work is either done in Fortran or, increasingly, C++. That's just patently false. For an example, see the (open source) quantum chemical simulation program gpaw, implemented in 30 Kloc Python (+ 15 Kloc in a support framework/library), 10 Kloc C (+ another 5 Kloc C in a library providing some of the core functionality shared with other simulation programs) [*]. The C code is basically the performance critical parts where one needs element-by-element access to arrays, and MPI calls. Where comparable, performance is roughly similar as other simulation programs implemented in Fortran or C, except that gpaw scales to thousands of processors (maybe even tens of thousands depending on the problem setup). Granted, the scaling is due to the choice of algorithms, not the implementation language, but just goes to show that performance doesn't need to suck even if most of the program is done in a very slow language (as compared to C et al). [*] LOC counts measured with the sloccount tool by D. Wheeler. If you do a simple 'wc -l' it's probably roughly twice the size.
Let's talk about Python 3.0 Posted Dec 11, 2008 5:55 UTC (Thu) by daniel (subscriber, #3181) [Link] Yes, but there are multiple ways of calling C/C++/Fortran code for those critical loops while enjoying the productivity of Python for the rest of the code (assuming performance is important enough in the first place to be worth spending time on, of course)."But why force users to do those stupid workarounds just because the language optimization is lame? I am increasingly seeing this as a fatal weakness of Python. Next.
Let's talk about Python 3.0 Posted Dec 7, 2008 4:58 UTC (Sun) by MattPerry (guest, #46341) [Link]
> And I hope we don't see too many headlines like The Register's "Python
> 3.0 Appears, Strangles 2.x Compatibility".
I've always found The Register to be a joke or troll site, something akin to Andy Kaufman writing IT articles. I have yet to meet a colleague in real life who takes the site seriously. I wouldn't put any stock in what it publishes beyond its entertainment value.
Let's talk about Python 3.0 Posted Dec 9, 2008 11:49 UTC (Tue) by sitaram (subscriber, #5959) [Link]
Entertainment is certainly high on their list.
But it's also a good source of "gut feel" and/or "shoot from the hip" comments and reviews. I like the slang, and I like the irreverence they bring to everything, although I agree they sometimes go too far. Some of their columnists are highly inconsistent in their quality, but I am yet to see a article that sounds like a planted pitch in the 4-5 years I've been reading them.
After LWN, it's my second visit on my daily RSS feed rounds. And yes you do need a good RSS reader to be able to pick the right articles to read, I admit they're a bit high on quantity.
Speaking as a person who has an interest in security, where else would I find news like http://www.theregister.co.uk/2004/06/18/blaggers_lift_cct... ? There's a very important security lesson in there, and I have used that example many times subsequently.
Let's talk about Python 3.0 Posted Dec 7, 2008 12:29 UTC (Sun) by zooko (subscriber, #2589) [Link]
Okay, so I read it, and as I understand it, the author is excited because:
1. Python 3.0 no longer automatically coerces between unicode and string type.
Also, the author doesn't mention it but there are many other small changes -- http://docs.python.org/dev/3.0/whatsnew/3.0.html .
I must say I'm underwhelmed. There are a lot of interesting new developments in programming languages. E, BitC, Erlang, and Haskell are all embodiments of powerful new ideas that might prove to have wide applicability.
By contrast, the improvements in Python 3.0 are minor.
I'm not saying that I want Python to try adopting some unproven innovation -- that's not its job in life. Its job is to keep being the easy, simple dynamic object oriented language with a vast library of good modules and legions of good programmers. These improvements help it to do that job, but breaking backwards compatibility will hamper its ability to do that job.
Whether 3.0 will make Python more valuable or less valuable to programmers remains to be seen.
Let's talk about Python 3.0 Posted Dec 7, 2008 15:47 UTC (Sun) by rsidd (subscriber, #2582) [Link]
Python has already borrowed from Haskell, at least: I'm thinking in particular of block-definition-by-whitespace and list comprehensions, and perhaps more, but those two are my biggest reasons to use python over other scripting languages. Are there other ideas in Haskell that you think are worth borrowing and would be a good fit? What about the other languages? Specific examples would be interesting. Just because there's a cool language out there doesn't mean Python must borrow from it: it may not suit Python at all.
Let's talk about Python 3.0 Posted Dec 7, 2008 16:09 UTC (Sun) by zooko (subscriber, #2589) [Link] "Just because there's a cool language out there doesn't mean Python must borrow from it: it may not suit Python at all." Sure, I agree. You asked what I thought was a new development in programming languages that could turn out to be important and also a good fit with Python. My answer is object-capability security. It hasn't been proven to be a good fit yet, or to have valuable uses, but it promises great benefits. You can experiment with it using the CapPython project. But you can't experiment with it in Python-3 -- only in Python-2. There are at least two reasons why Python-3 can't be secured in the way that Python-2 can: unbound methods now escape from type-checking so that they can be used to get access to the internal members of an object of any class, not just their own class, and extended string formatting gives access to internal members.
Let's talk about Python 3.0 Posted Dec 8, 2008 8:37 UTC (Mon) by tyhik (subscriber, #14747) [Link]
Block-definition-by-whitespace as one of the biggest reasons to use a language? Huh.
Let's talk about Python 3.0 Posted Dec 8, 2008 9:25 UTC (Mon) by rsidd (subscriber, #2582) [Link]
What I meant was, the lack of it is one of the biggest reasons not to use the other languages.
Let's talk about Python 3.0 Posted Dec 8, 2008 15:20 UTC (Mon) by elanthis (subscriber, #6227) [Link]
As someone who's had a need to convert data files to source code for embedded systems and (in one case) performance reasons, I'm pretty sure that forcing indentation is a point against, not a point for. Good code in any language is going to be properly formatted for readability; forcing it in those cases where it just flat out doesn't matter and doing the indentation is hard (generated code) sucks.
The only thing worse are the languages that try to be too clever with white space handling, e.g. Lua. It tries to pretend like it can automatically figure out where statements are (such as claming that a = 3 b = 5 is legal in Lua, without any statement separator, even a newline), but that just ends up making otherwise legal and clear code ambiguous in certain (admittedly rare) circumstances.
I'll always prefer a language that uses syntax instead of white space (or magic pixie dust) for communicating programmer intent to the parser.
Python's great, but I've never felt that its whitespace semantics were a bullet point in its favor.
Let's talk about Python 3.0 Posted Dec 8, 2008 17:06 UTC (Mon) by rsidd (subscriber, #2582) [Link]
I'm not sure I follow. What's hard about generating whitespace indentation? Internally it's some sort of parse tree, whatever the language. Output formatting is a trivial matter.
The only argument I can think of against whitespace formatting is it can get messed up when cutting-and-pasting to and from the web. But one can get around that by linking to the raw source file when posting code online.
Let's talk about Python 3.0 Posted Dec 7, 2008 20:00 UTC (Sun) by jordanb (subscriber, #45668) [Link] Python 3 wasn't ever supposed to be a groundbreaking new language. Rather, it was supposed to be the release where they finally got rid of cruft that had been building up in Python, but that couldn't be removed without breaking backwards compatibility. Python has been changing and incorporating features from research languages (like list comprehensions and decorators) all along, and it will continue to do so in the future, where that can be done without breaking compatibility. ISTR early in the process a discussion of how to go about fixing the language's warts. There were proposals to line everything up into a series of releases, where each release would deprecate then remove something new, to coerce people to change their code one feature at a time. The Python 3 effort was what they decided upon instead -- a bit of a ripping off the band-aid approach -- where they would queue everything up into one release with a major version rev, so they would only have a single backwards-incompatible release that would serve as a type of fault line. Regarding your post about object encapsulation below, you're right that Python couldn't get that without breaking compatibility again, and the fact that it isn't in this release likely means it will never be in Python. It doesn't strike me as a problem though as such mechanisms -- while useful -- are a poor fit for the dynamic, introspective scripting nature of the language. If your problem needs those sorts of features then Python is probably the wrong language for the task at hand. And that's fine, that's why we have multiple languages to choose from. To be honest I'm impressed that the Python developers were able to constrain themselves in this release to focusing on the 'warts' in the language and just removing them, rather than piling on every neat backwards-incompatible idea they ever thought up until the whole effort collapsed into a second-systems nightmare.
Let's talk about Python 3.0 Posted Dec 9, 2008 3:11 UTC (Tue) by smitty_one_each (subscriber, #28989) [Link]
Aw, c'mon:
There is no need to take potshots at Perl6. From a project management perspective, one could editorialize about Perl6. Consider that the very clear-headed approach you're applauding in Python3 is very much a reaction *to* the Perl6 experience, and therefore could be said to have benefited from that cautionary tale. Perl6 will get here one day, and, hopefully, shall have been worth the wait.
Let's talk about Python 3.0 Posted Dec 9, 2008 23:48 UTC (Tue) by rfunk (subscriber, #4054) [Link]
I'm just surprised it took this long for someone to mention the Perl6
debacle in this conversation.
Let's talk about Python 3.0 Posted Dec 7, 2008 20:09 UTC (Sun) by pboddie (guest, #50784) [Link] I'm not saying that I want Python to try adopting some unproven innovation -- that's not its job in life. Its job is to keep being the easy, simple dynamic object oriented language with a vast library of good modules and legions of good programmers. These improvements help it to do that job, but breaking backwards compatibility will hamper its ability to do that job. It's nice to read comments from underwhelmed people like yourself, zooko, who seem to understand that the whole picture is bigger than the Python language roadmap. It's also enlightening that in a single sentence you manage to summarise the Unicode/string changes in a way that has eluded others, especially those who have an interest in having everyone reinforce their decision to move to Python 3.0.
Let's talk about Python 3.0 Posted Dec 8, 2008 14:01 UTC (Mon) by zooko (subscriber, #2589) [Link]
Thanks for the compliment. Receiving a compliment spurred me to go back and re-read my comment to see if it was right, and I see that I missed something about the Python-3.0 unicode handling. I wrote:
"1. Python 3.0 no longer automatically coerces between unicode and string type."
But also important is that all the standard APIs which expect human-meangingful text have been changed to require unicode type.
My overall impression remains that these are good improvements, but that breaking compatibility is too high a cost for me to undertake in the near future.
Let's talk about Python 3.0 Posted Dec 7, 2008 15:35 UTC (Sun) by kjp (subscriber, #39639) [Link]
I'm quite happy with the 3.0 changes, although even though I've been following it for about a year I'm still digesting all of them. The unicode vs bytes is a big one and is well done and very welcome. They also cleaned up some horrible syntax like the except clauses. Tightening up what exceptions you can raise is probably smart too. You also have ints that never overflow and too many cleanups with user defined operators and container classes to mention easily. In my opinion, they future proofed the language by at least another decade.
I salute the python programmers for avoiding the "second system effect".
The only thing I don't like is them planning to deprecate the string % operator in 3.1. That is very handy and very safe for all of our uses - we have never had some bug slip in there. I guess I can live with the fact that "1" == 1 still won't throw a TypeError. That is one of the few ways where bugs slip in to our code today. (< and > will raise one, I believe, fortunately).
Let's talk about Python 3.0 Posted Dec 7, 2008 20:02 UTC (Sun) by mb (subscriber, #50428) [Link]
> The only thing I don't like is them planning to deprecate the string % operator in 3.1.
Huh, really?
What's it going to replaced with? The usual "string" + str(integer) + "string" crap?
Let's talk about Python 3.0 Posted Dec 7, 2008 20:08 UTC (Sun) by allesfresser (subscriber, #216) [Link]
Let's talk about Python 3.0 Posted Dec 8, 2008 0:13 UTC (Mon) by k8to (subscriber, #15413) [Link]
This text says "supplement".
I think string interpolation is one area that Python has really not gotten it right. There are now going to be three different implementations of variable expansion inside strings, which means different people will use, and be familiar with, diffferent types of parametric string replacement/expansion. Each implementation is incrementally both more complex and more verbose, without really having a compelling reason for existing users to shift wholly to the new implementation.
Three interfaces is notably worse than one, when one will do.
Let's talk about Python 3.0 Posted Dec 8, 2008 0:27 UTC (Mon) by k8to (subscriber, #15413) [Link]
Okay, now I read the PEP in full.
It looks like they plan to deprecate % entirely at some future date. That satisfies my goal of reducing redundant interfaces. I still don't like it though. % specifiers are familiar from other languages that almost everyone will encounter, and are brief. The {} stuff is flexible, to be sure, but significantly more complex to read, and features the kind of "operator overloading" that drove me away from C++. What do the format specifiers do? Who knows! The class can redefine them at will.
Boo.
Let's talk about Python 3.0 Posted Dec 8, 2008 11:00 UTC (Mon) by mb (subscriber, #50428) [Link]
> It looks like they plan to deprecate % entirely at some future date.
Duh, seems like % was really too easy use and read...
Let's talk about Python 3.0 Posted Dec 8, 2008 14:30 UTC (Mon) by macson_g (subscriber, #12717) [Link]
> Yeah, the new {} stuff is a bit more powerful, but who does actually need this in real life?
This is needed in real life for i18n.
Qt has similar feature ( QString::arg() ), and they provide nice example in their documentation: http://doc.trolltech.com/4.4/i18n.html#use-qstring-arg-fo...
Let's talk about Python 3.0 Posted Dec 8, 2008 18:16 UTC (Mon) by mb (subscriber, #50428) [Link]
Yeah I know about QT's QString.arg and I think it totally sucks ;)
(Where the rest of QT is a really nice toolkit)
How many projects with support for at least 10 languages do you have? Posted Dec 9, 2008 8:20 UTC (Tue) by khim (subscriber, #9252) [Link] Such features tend to suck for the person who writes quick and dirty program but are invaluable for proper i18n support. If you want quick and dirty - that's perl and php, not pythong and qt...
Only few billions of people Posted Dec 9, 2008 8:18 UTC (Tue) by khim (subscriber, #9252) [Link] I really don't get this. Yeah, the new {} stuff is a bit more powerful, but who does actually need this in real life? Oh, just a few billions of "other" people who by some accident don't use English. Unlefixble formatters like python's % are PITA. Even C added fewtures needed by i18n in GLibC! While I'm not sure PEP 3101 is right solution for the problem any formetter without the ability to rearrange the placeholders must be removed from all sane languages (that's why we DON'T use C++ streams here, for example). And situation here is the same as with Unicode: to make it usefull all other methods will be shot (% must be removed) - or else ignorant developers will use it. Sadly python 3 kept it...
|
|
||||||||||||