I hope very much that the freed up cycles will be used to improve Python's packaging/distribution mechanism, which I think is the weakest link in the chain of using Python.
And that's about all it does. You have to update packages manually and you can't remove them at all with easy_install. What's so beautiful about gem to me as a Python dev is this:
$ gem update && gem cleanup
A lot of headache I don't have to deal with at all. I really wish Python would grow an equivalent tool.
That's it's completely python specific. All Java and perl modules are typically installed via JPackage and cpan2rpm, there's no justification for Python to need its own unique non-native package management method.
great move. Most of hosts I use still are at 2.5 / 2.6 levels. This moratorium will indeed give time to catch up. Probably I missed it - but does the moratorium apply to bugs/security patches as well ?
Fundamental language bugs (ambiguity, etc.) can be fixed. Security bugs will almost certainly be the result of something in the standard library, which has not been frozen.
The releases will go on (probably faster), it's just the syntax that's frozen. This helps Python implementations like IronPython or jPython catch up, but it certainly won't help hosts.
Drat. I do agree with the analysis you posted on your site [1] that it only will affect early-adopters/language geeks and is probably for the best for the python community at large. But two years is a darn long time in the technology world.
It looks like it will be up to the library/framework builders to keep the python hype/momentum going while the language maintainers are playing grown-up and being responsible.
Yes and no; I actually think a stronger focus on the standard lib and the interpreter is plenty of work to keep the hype running. It's been my personal bugbear to do a heck of a lot of cleanup in that space.
For example, right now there's discussion about a futures library (ala Java's implementation) for inclusion. There's plenty of work to be done there to make sure some of our older batteries are cleaned up, new ones included, etc.
Two years is a long time - but how much of that needs to go into the syntax rather than the standard library? What about more abstractions on top of threading/multiprocessing? An actor implementation? More web technology support?
Python is more than the sum of it's implementation - and even that is fair game (see antoine's latest GIL work as an example).
Just curious... Isn't there an easier way to handle this case "from the other side"? I.e. a way to write a class that will behave like a "stacking" generator - if the original generator g1 yields a generator g2, then the control will be given to g2 and g1 is put on the stack until g2 is finished - then pops g1 back. It would be a bit uglier and would require the control code to know about the problem (for x in StackingGen(g1()), instead of for x in g1()) and would remove the posibility to yield generators themselves, but it should work ;) Or are there some other problems with this idea?
I don't think any version of Chrome currently supports rss, does it? I'm running the Windows developer channel and don't see any obvious way to subscribe to a feed.
Well; that's not what I meant when I said it. I would love to see PEP 380 in, but I think that the possible benefits of this moratorium outweigh the usefulness of a new feature only a relatively small populace of users will use over the next two years.
Remember, well above 90% of the users out there are still on 2.4 and 2.5 - even if pep 380 went in, it would more than likely be in 3k only (a few years from widespread adoption anyway) and in a release OS vendors won't ship for a few years.
After reading the PEP I'm still not sure: does it mean that no changes will be made at all, or are "from __future__ import ..." additions allowed (but won't be integrated until 3.3)? [Not allowed - now I see it, my bad]
That surprises me. I've been learning Ruby recently (only really working with 1.9), but every time I learn about something that's new or different in 1.9 compared with earlier versions, the new version seems better, cleaner to me (e.g. 'hello'[1] # => 'h' not 101, Enumerators and MiniTest::Unit, off the top of my head).
Probably because 1.9 isn't completely backwards-compatible with 1.8.
People were also upset by two things. First, some 1.9 features were backported into 1.8.7, meaning an upgrade from 1.8.6 to 1.8.7 was sometimes painful. Second is numbering confusion. Ruby used to use even numbers for stable releases, and odd numbers for experimental releases. So 1.9 should be experimental, and 1.10 or 2.0 stable. But for various reasons, they didn't want to go to either 1.10 (ever) or 2.0 (yet), so 1.9 will be used for production releases. It has taken a long time for Ruby folks to realize that they should be using 1.9.
I actually really think the Linux kernel would benefit from something like this too; it doesn't have to be a freeze for two years, but dedicating maybe every third release to strictly bugfixes and performance and stability improvements and no new features, or something like that, would do a lot of good, imo. Tightening sessions like that where Linux devs ask everyone to pitch in to tightening and accept no major feature additions or alterations would go a long to making things cleaner and faster, and maturing patches before they are merged (because the skipped cycle would allow extra improvement on features before the next merge window).
This will give Perl and Ruby a good chance to pull even farther ahead of Python. It would be nice if "we" didn't learn anything about programming that needs new language features, but we do, and it's silly to omit features that make programming easier.
Language wars are so pointless. Spend your energy on something else.
Guess what. The programming language you use is pretty irrelevant to success. It's a matter of taste, what other people are using (If you care), what has convenient libraries for what you're doing.
edit: OK I'll bite:
>> "It would be nice if "we" didn't learn anything about programming that needs new language features, but we do, and it's silly to omit features that make programming easier."
Examples? What have we really learnt about programming say in the last 5 years that requires new language features? Maybe it's just individuals that learn things about programming, and change their tastes.
"Language wars are so pointless. Spend your energy on something else."
I think flamewars on languages are painful and wrong, but not pointless. Programming Languages are how we frame our thoughts about problem solving, and I think too many people go with the theory any language is ok.
I hope for the sake of language design that the last 5 years would teach us a lot. Heck, for starters how many languages really have a good story about the multi-processor hardware that comes standard these days. I think leaving that solution to libraries really hasn't served us well.
Programming languages shouldn't be concerned about multi-cores IMHO. That should be some magic sauce that goes on without anyone knowing/caring. (Also, 5 years ago people were hyping it up saying we'll all have 20 CPUs. Most still have 2 at most. The need for CPU power on desktops is going down).
Would Charles Dickens stories been any less had he written them in French rather than English? :/
Well, all programming is not done on a client and poorly using the many CPUs of a server is not cost effective. I think we are a long way off from the "magic sauce" and languages designed to allow programmers to express their programs in a parallel manner are going to have an advantage.
"Would Charles Dickens stories been any less had he written them in French rather than English? :/" - yep, they would have been - a particular turn of phrase or expression doesn't always translate well. Different languages bring different world views.
People waste my time with language wars every time the word "Perl" is used positively. I thought I would waste other peoples' time to see if they liked it.
The trolling in Perl discussions seems almost organized. Then we find snide remarks about operator count voted to 14, here. (Edit: 15, http://news.ycombinator.com/item?id=931618)
Maybe we should add a link to this discussion, to let Perl people know how to handle language war trolls pro and contra?
I was talking about giving a link to when the insulting reference to operator count in Perl 6 was upvoted (17 now), the next time Perl discussions are trolled by Python/Ruby people... which is so common it seems organized.
Ruby's anonymous function syntax was pretty novel. I'm aware it was inspired by some syntax showed up in CLU, but it was fairly novel and remains a paragon of anonymous function syntax.
Actually, enough so that you now see it showing up (although some claim this is a resurgence) in Lisp clones like Clojure and appearing in common Scheme macro packs. So while it was "around for decades" it was "around for decades in a marginalized and primitive form that Ruby helped to popularlize and make mainstream."
In any event, this moratorium is stupid. Python already suffers from a paucity of modern language features under the aegis of "they are too complex." But it seems only hardcore Pythonistas seem to really feel this way, as the vast majority of other peer languages are–at the very least–adopting and embracing real lambdas and the elegant collection manipulation that follows from their reasoned use.
I'm sorry, but lambda notation was created around 193X and used for anonymous functions (in computer programming languages) in 197X. It's definitely not novel. People are simply rediscovering it now.
It would help if your example was syntactically correct Ruby. (EDIT: I see you fixed it)
And I meant novel in that it brought the notion into the dot-notation-happy world, where the majority of programmers lived and adapted it. Both Ruby an Smalltalk took the feature from a predecessor, as I understand it, and mentioning an also-ran like smalltalk slipped my mind.
Does that weaken the point significantly? The feature is good and Python should finish integrating lambdas rather than sitting on their half-cocked nod to it. They cannot now Fo that for 2 years, maybe more.
I de-edited the end of my comment, because of weird time-related issues.
> The feature is good and Python should finish integrating lambdas rather than sitting on their half-cocked nod to it. They cannot now for 2 years, maybe more.
It's hard to "finish" a thing that hasn't started. Python has a whole aesthetic, and multi-line lambdas will likely never be a part of it. It's really quite a minor difference.
I really think I'm not a zealot on the issue, and that I'm quite aware of the differences: http://billmill.org/multi_line_lambdas.html ; what I'd like you to demonstrate is a place where giving a function a name is more than a minor inconvenience, and list comprehensions don't satisfy the need.
I kind of am, but I think in reality perl and python appeal to a different enough mindset, and solve similar enough problems, that there's almost no real competition between them. Most people will instantly like one and loathe the other based on their opinions on compiler-mandated style. (It's not just that, but it's an immediate thing you encounter and exemplifies the philosophy through the whole language - the One True Way to do things, uniformly and consistently across programmers, or There's More Than One Way To Do It, the language accepting as many alternate ways as possible and adapting to the programmer.)
There exist performance benchmarks, but I tend to think they continue to trend close enough together to never be a more compelling argument than the underlying design principal, for people choosing a primary language to work in. Similar for featureset - comparing modern releases, there's a vanishingly small set of real differences, especially if you're willing to consider best practice modules freely available. (IE, yes, we're sorry about Perl's built-in object model, but really, we fixed that in libraries years ago, seriously guys, years.)
We can band together and agree that we hate java more than each other, though.
> (IE, yes, we're sorry about Perl's built-in object model, but really, we fixed that in libraries years ago, seriously guys, years.)
Can you be more specific? The tutorials (perlboot, perltoot, perlbot) still have the decade-old examples of rolling your own by blessing references. It's not at all clear which library has been made part of the language, and if there isn't one, what happens when your dependencies disagree about which version of, e.g., method dispatch should be used.
The languages are much more similar than they are different (in terms of feature set, not mindset), but one thing perl has which I don't understand how the python+ruby people get by without is 'use strict'. (ObLanguageWar: I'm not trying to promote perl here - I know the other languages have particular features perl does not - I'm just curious about this specific item.)
Every sane perl programmer will have this pragma enabled, and it requires you to declare lexical variables, otherwise you get a compile-time error.
I understand (please correct me if I'm wrong) that python+ruby instead allow lexicals to be created by assignement, leading to this problem:
I'm told there are lint-like tools for python which can catch this, but since people typically don't use Makefiles to manage their python/perl/ruby code I can't imagine they are routinely used on each edit/run cycle.
Can any python/ruby coders comment on this? Is it an error case which takes any significant debugging time? (Rather than the O/0 distinction above, I see this sort of error more often from inConsistent camelCase).
