Python language moratorium is accepted
python.org
python.org
$ easy_install «package name»
The pypi web interface is very poor.
There is lots of scope for improvement in locating and installing packages.
(though I agree it is as intuitive, at it's most basic, as ruby gems)
$ 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.
Try installing any major piece of python software (and no, easy_install does not always work, or work properly) and you're in for a world of grief.
Remember, this doesn't mean that the implementations won't be improved underneath the covers, just the high-level language spec.
> Used often in the business world, this incredibly versatile phrase can be literally translated as "fuck it."
Edit: tongue-in-cheek
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.
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.
[1] for everyone else's sake: http://jessenoller.com/2009/11/09/pep-3003-python-language-m...
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).
OT: Does Chromium (Dev channel, Ubuntu 9.10) not have feed autodetection? I had to look at the page source to find this.
From the introduction of the subject on the mailing list it seemed as though the moratorium was already in place at the time of the announcement.
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.
Also, it's significantly faster, no?
Oh yeah, it's Python.
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.
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.
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:
def important_condition():
return 1
FOO = "wrong"
if important_condition(): FO0 = "correct"
print FOO
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).
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.
Smalltalk traits and Perl 6 roles -- a missing feature of OO design.
Don't get me started on tests, what a waste...
Apparently not. Interesting, isn't it!
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.
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.
Would Charles Dickens stories been any less had he written them in French rather than English? :/
"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.
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.
Ruby: {|x| x+1}
Smalltalk: [:x | x+1]
What am I missing?
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.
> 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.