| |||||||||||||
|
| |||||||||||||
Python 3.0 releasedPython 3.0 releasedPosted Dec 5, 2008 2:46 UTC (Fri) by brouhaha (subscriber, #1698)Parent article: Python 3.0 released And in 2014 or so, there will finally be a release of Zope that runs on Python 3.0, but by then the current Python release will be 4.3. Sigh.
(Log in to post comments)
Python 3.0 released Posted Dec 5, 2008 3:35 UTC (Fri) by sbergman27 (subscriber, #10767) [Link]
The buzz in the general community suggests that "top of the food chain" applications, e.g. Django, will likely take their time and support Python 3.x in about a year. I suspect that the 3.x series will be around for some time, similar to the 2.6.x Linux kernel. The change in major version number represented changing some design decisions made up to 20 years ago. It's hard to imagine anything at this point that would warrant a 4.x series, barring someone abducting Guido and hijacking the project. ;-)
As for Zope... well it hasn't been the most agile fish in the pond, has it. At DJangoCon this year, Mark Ramm's presentation was basically a "Reefer Madness" style propaganda exhibition attempting to scare the Django devs into thinking that Django could become "like Zope". Being the very archetype of what a Python project shouldn't want to become is probably not what the original Zope devs set out to accomplish.
Python 3.0 released Posted Dec 5, 2008 6:07 UTC (Fri) by elanthis (subscriber, #6227) [Link]
So... where does Guido live? >:)
(No, really, I have a beneficial purpose in mind! I want to kidnap Larry, Guido, Yukihiro, and Bjarne, to create the world's first true object-oriented systems language with a pleasant syntax and Perl regexp support! It'll be the most wonderful thing evar@~~!)
Python 3.0 released Posted Dec 5, 2008 12:01 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]
I suspect I'm not alone in working on something like that in my spare time. What I have in mind is a statically typed, garbage collected language with a C/C++/D/Java-like basic syntax, but with two major twists to make it much more pleasant to work with:
* Something very much akin to Pythons duck typing, but still using static typing. You might think of it as implicit interfaces - if a class has all the methods of another class and the same method signatures, it can be used as if it was of the same type in e.g. as a parameter in a function call.
* Lisp-like macros, i.e. function calls that are executed at compile time, and whose input and output are nodes in the parse tree. This allows you to extend the language wiuth things like Pythons 'with'-statement and built in regexp support. The plan is to use this to use this syntax for regexp matching:
r"[a-zA-Z.]+@[a-zA-Z.]+" == someString
(notice the 'r'-prefix) create a regexp object overloads the '==' operator top perform a regex match on a string.
New system programming language Posted Dec 5, 2008 21:55 UTC (Fri) by ncm (subscriber, #165) [Link] ... garbage-collected ...FAIL
New system programming language Posted Dec 6, 2008 1:03 UTC (Sat) by liljencrantz (subscriber, #28458) [Link]
1995 called. They want their unjustified preconceptions back. Unless you're writing a kernel or a gaming engine, garbage collection makes a huge amount of sense.
New system programming language Posted Dec 6, 2008 6:14 UTC (Sat) by njs (subscriber, #40338) [Link]
Going back to malloc/free is clearly insane. Garbage collection is handy, and works well for lots of purposes. But, gc isn't perfect: my job as a programmer is to understand and control the computer's operation; garbage collection makes memory management opaque and nondeterministic. (The usual place this bites you is when trying to optimize for memory usage - it's still possible with gc, and tools can help, but it's harder and the result more fragile.)
So there's room to explore more structured systems for memory management, that let you precisely define object lifetime when possible/convenient, or fall back on gc in a controlled way. Well-written modern C++ -- with its stack allocation and multiple flavors of smart pointers -- often looks something like this, but too many people still just use new/delete and "real gc" isn't one of the available flavors. But C++ is the only game in town for this kind of thing, because everyone else just bakes gc into their runtime as The Way Memory Works. It'd be wonderful to have a better language than C++ with a better memory management system than pure gc.
New system programming language Posted Dec 6, 2008 10:38 UTC (Sat) by liljencrantz (subscriber, #28458) [Link]
That I can agree with. The op expressed the opinion that a langauge that includes garbage collection are instafail, which I belive to be a silly argument that has been disproven time and time again in the last 10 years. But it's not a silver bullet, no. And there are definitely situations where the coder could do a lot better than even the best automatic collectors with very little effort.
New system programming language Posted Dec 6, 2008 18:18 UTC (Sat) by drag (subscriber, #31333) [Link]
There are module writing languages for python.. I am aware mainly of cython/pyrex. (pyrex being more serious, cython more open to add-ons)
http://en.wikipedia.org/wiki/Pyrex_(programming_language)
The old story for python performance is:
This way you get the app rapidly prototyped and written and identify areas were performance and optimization work is actually necessary rather then trying to guess ahead of time.
I don't know particularly how successful this approach is, but it's what is mentioned in the literature and seems to make sense to me.
This way you get to use GC and then also do the manual memory stuff were it matters. Have your cake and eat it, too.
New system programming language Posted Dec 7, 2008 0:24 UTC (Sun) by njs (subscriber, #40338) [Link]
Pyrex/Cython are indeed *fantastic*. But they don't really create the kind of system I'm talking about here, because 1) they're usually used to define little self-contained computational cores and simple wrappers around foreign code, so their interaction with overall memory management is minimal (except that they let you temporarily avoid the constant heap allocations that tend to bottleneck pure Python code), 2) they don't provide any tools beyond malloc/free anyway.
Python 3.0 released Posted Dec 6, 2008 18:29 UTC (Sat) by nix (subscriber, #2304) [Link]
Useful Lisp-like macros without a Lisp-like syntax is going to be very
painful to design. I wish you luck, but without much hope.
Python 3.0 released Posted Dec 7, 2008 10:12 UTC (Sun) by liljencrantz (subscriber, #28458) [Link]
Thank you for the wellwishes. :)
But yes, the simple structure of Lisp obviously makes it much easier both to implement a macro system and to use it for creating new code. Just the simple little addition of static typing makes writing macros significantly harder.
On the other hand, people have been doing some impressive things by using C++ templates for metaprogramming, and that is a significantly more anemic and archaic interface than what I have planned.
My plan is that regular projects will very rarely contain custom macros, they should mostly be used for extending the language to provide features like enums, python-style with-statements, etc..
please don't use Python-3 Posted Dec 5, 2008 14:01 UTC (Fri) by zooko (subscriber, #2589) [Link]
Ugh, I personally intend to cling to Python-2 for as long as I can. I haven't heard of any features in Python-3 that I actually care about. Maybe there are some in there, but glancing at the first few paragraphs of "What's New in Python 3" has never showed me anything that I care about.
I have a lot of code in various packages written in Python-2, and I'm secretly hoping that nobody gets around to upgrading to Python-3 for a few years so I can just ignore Python-3 and keep hacking.
The main feature that Python lacks that I want is more programmatic, automated sharing of modules, through tools such as setuptools and services such as http://pypi.python.org . The incompatibility of Python-3 makes this problem worse, not better.
Also, there's a really cool feature that I'm interested in that works in Python-2 but is fundamentally incompatible with Python-3: capability-based restricted Python:
http://lackingrhoticity.blogspot.com/2008/08/introducing-...
Perhaps this post will come back to haunt me...
please don't use Python-3 Posted Dec 5, 2008 19:56 UTC (Fri) by edlenz (guest, #12021) [Link]
This feature is intersting...
a=[1,2,3]
works with any object with .__str__ mehtod.
please don't use Python-3 Posted Dec 5, 2008 22:11 UTC (Fri) by nevyn (subscriber, #33129) [Link]
That's not a feature, just different syntax (I agree it's better, but it's also different):
a = [1,2,3]
please don't use Python-3 Posted Dec 6, 2008 0:39 UTC (Sat) by pcharlan (guest, #29128) [Link]
> I haven't heard of any features in Python-3 that I actually care about.
I am relatively new to Python, but how someone could have designed a language with closures that lacks nested lexical scoping ("nonlocal" in Python3.0) is baffling to me.
I'm in the "I wish Python were Scheme" camp, and so also miss tail-call optimization, but I'm used to languages not seeing the beauty in that. But nested lexical scopes are so basic that their omission from Pythons previous to 3.0 was just weird.
please don't use Python-3 Posted Dec 6, 2008 5:01 UTC (Sat) by sbergman27 (subscriber, #10767) [Link]
I'm not certain if I am understanding you clearly. Nested functions have always been able to refer to variables in the immediately enclosing function. They just haven't been able to rebind them. Here is the relevant PEP for nonlocal, for reference:
please don't use Python-3 Posted Dec 6, 2008 6:28 UTC (Sat) by njs (subscriber, #40338) [Link]
>Nested functions have always been able to refer to variables in the immediately enclosing function.
Not true -- see __future__.nested_scopes.
Until 2.1, Python didn't even have the concept of doing recursive lookup through a stack of applicable scopes. Every piece of code had access to exactly 3 scopes: "local", "global", and "builtin", checked in that order.
I think Python tends to confuse programming language enthusiasts, because the actual language core is incredibly simple and stupid (though it's become somewhat less so over time). Another example: the first time I tried learning Python, I gave up in disgust when the tutorial mentioned that lambdas were syntactically limited to a single expression (wtf?). The trick is to realize that the actual Python core is basically a hacky, simplest-thing-that-could-possibly-work language runtime, with the best human factors design in the world stuck on top.
It's a little disconcerting to try and do something Clever, squint at the details of some bit of the runtime, and discover them melting away into a bunch of local conventions and baling wire instead of some beautiful principled thing like you'd find in Haskell. But it's a great insight that the beauty and consistency of a *language* is not the same as the beauty and consistency of its internals.
please don't use Python-3 Posted Dec 6, 2008 13:45 UTC (Sat) by zooko (subscriber, #2589) [Link]
Nicely put, NJS.
By the way, I suspect that the reason Python's human-factors are so good is because its immediate, strong ancestor ABC was subjected to iterated user testing. Imagine! A tool intended for use by users actually being *tested* on users and then changed in response to what is observed.
If I were the emperor of the programming languages research universe, I would summarily reject all papers that didn't come with studies on real humans, which would be all of them.
please don't use Python-3 Posted Dec 6, 2008 15:56 UTC (Sat) by sbergman27 (subscriber, #10767) [Link]
I'm not certain exactly what you are saying is not true. If you are saying that functions could not access variables in their enclosing function until 3.0 then you are incorrect, as this has worked for as long as I have been using Python, which goes back to about 2.2. I know, because I've been using it.
If you are saying that my use of the word "always" was not entirely accurate, which is what I think you are saying, then I would agree, and further add that the support for this was introduced in 2.0, back in Oct 2000 and turned on by default in 2.1, released Apr 2001. So all this occurred 8 years ago, back when Python was about half its present age. In this case, you can take "always" to mean "versions as far back as I can imagine any significant number of people might be running today".
Ignoring the loaded and essentially meaningless terms "stupid" and "hacky", I can agree with "simple". But you seem to see the simple core and the human factors to be distinct entities. I would be more inclined to say that the simplicity is integral to the "human factors". If you are looking for C++ in Python, you're out of luck. Not here. Don't want it.
As to Haskell... it's like Jane Mansfield: "beautiful" and "dead". (Though its features will influence, and have influenced, other languages, including Python, for years to come.)
I'll take "practical" and "useful", please.
I would be curious as to whether you have any comments on Ruby.
please don't use Python-3 Posted Dec 7, 2008 0:18 UTC (Sun) by njs (subscriber, #40338) [Link]
I think you read more hostility into my comment than was intended (and understandably, because I have a bad habit of using words like "stupid" as technical rather than pejorative terms). I was indeed referring to the pre-2.2 changes in scope handling (though it was actually 2.1/2.2 where it was added/turned on -- python -c 'import __future__; print __future__.nested_scopes' -- unless there was another round of scope tweaks that I'm forgetting about).
And I think -- again, remember I'm talking about how a language designer/aficionado sees and gets confused by Python -- the simple core *is* somewhat distinct from the human factors; it would be entirely possible to put Python's syntax etc. on top of a Lisp or Smalltalk, and you would have more consistent internals without any harm to the language's essential spirit[1]. But my central point was -- this is where experts get confused -- it turns out not to really matter much either way.
Ruby is also an interesting example, being a Smalltalk itself -- but I don't know much about it, because the perception of a culture of monkeypatching has scared me away, another example of the importance of "cultural"/non-technical/human factors in language use.
[1] A good example of this would be the evolution of R from S (the statistics programming languages, where S has a kludgy core and R is a Scheme... but users don't really notice the difference).
please don't use Python-3 Posted Dec 7, 2008 1:04 UTC (Sun) by sbergman27 (subscriber, #10767) [Link]
Yes, I did read some hostility in it. But I wasn't sure. I went back and reviewed your posts in the Perl thread and decided you seemed pretty even-handed.
You are correct about 2.1/2.2. I was correctly remembering what I had read in the Wikipedia article on Python:
http://en.wikipedia.org/wiki/Python_(programming_language)
which says, referring to 2.0:
"The release included a change to the language specification to support nested scopes, like other statically scoped languages.[13] (The feature was turned off by default, and not required, until Python 2.2.)"
But a review of the original "What's new in Python 2.0" and "What's new in Python 2.1" documents shows that to be inaccurate.
|
|
||||||||||||