8 ms·
Python language moratorium is accepted
- dschobel 17y agoAny word whether PEP 380 ("yield from") made it in before the cut-off?
- jnoller 17y agoIt did not. PEP 380 will not see the light of day until the moratorium is lifted. This made me sad while I was writing it, but it is what it is.
- fizx 17y agohttp://www.urbandictionary.com/define.php?term=it+is+what+it+is http://www.urbandictionary.com/define.php?term=it+is+what+it... > Used often in the business world, this incredibly versatile phrase can be literally translated as "fuck it." Edit: tongue-in-cheek
- jnoller 17y agoWell; 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.
- arkx 17y agoAre there some sort of studies or statistics out there regarding adoption of different versions? I'd be interested to see them.
- clutchski 17y agothe phrase "it is what it is" does not mean "fuck it", but rather "i accept this is beyond my control".
- dhimes 17y agoThat is also one (colloquial) interpretation (but not the literal interpretation) of "fuck it."
- viraptor 17y agoJust 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?
- jamwt 17y agoYeah, diesel (http://dieselweb.org http://dieselweb.org) takes this approach.
- dschobel 17y agoDrat. 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. [1] for everyone else's sake: http://jessenoller.com/2009/11/09/pep-3003-python-language-moratorium-accepted/ http://jessenoller.com/2009/11/09/pep-3003-python-language-m...
- jnoller 17y agoYes 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).
- statictype 17y agoIs there an rss feed available for PEPs?
- mattyb 17y agohttp://www.python.org/dev/peps/peps.rss http://www.python.org/dev/peps/peps.rss OT: Does Chromium (Dev channel, Ubuntu 9.10) not have feed autodetection? I had to look at the page source to find this.
- statictype 17y agoI 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.
- viraptor 17y agoAfter 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]
- jnoller 17y ago__future__ additions are banned under this. See "cannot change" point 4
- unohoo 17y agogreat 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 ?
- jnoller 17y agoNo - it does not apply to bugs or security issues
- dschobel 17y agoI think you'd be hard pressed to find a bug or security flaw in the language syntax or semantics. Remember, this doesn't mean that the implementations won't be improved underneath the covers, just the high-level language spec.
- wtallis 17y agoFundamental 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.
- unohoo 17y agocool - thanks. good to know.
- andreyf 17y agoThe 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.
- TwoBit 17y agoJust two years? I suggest six years.
- jrockway 17y agoThis 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. Oh yeah, it's Python.
- tsally 17y agoI'm not a zealot for either of the 3 languages, but I wasn't aware that Perl could be considered "ahead" of Python by any measure except libraries.
- jerf 17y agoOh, it's way ahead on operator count. http://www.ozonehouse.com/mark/periodic/ http://www.ozonehouse.com/mark/periodic/
- Kirby 17y agoI 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.
- enneff 17y ago
- jparise 17y agoIt's important to note that improvements to the standard library and C API are still permitted while the language (grammar) moratorium is in effect.
- cool-RR 17y agoI 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.
- sandGorgon 17y agoseconded. Ruby's gem might not be perfect, but it is much more intuitive than anything python has (no idea about "pip" though)
- jacobolus 17y agoWhat's unintuitive about easy_install, in your opinion? In general, all I have to do to install a Python package is: $ easy_install «package name»
- ErrantX 17y agoa reasonable percentage of the time it doesn't work correctly. 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)
- arkx 17y agoAnd 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.
- stevelosh 17y agoThe most unintuitive thing is that there's no easy_uninstall.
- nailer 17y agoThat'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.
- tptacek 17y agoI wish Ruby would make the same promise. I'm kind of bitter about 1.9.
- carbon8 17y agoWhy's that?
- jon_dahl 17y agoProbably 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.
- telemachos 17y agoThat 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). Also, it's significantly faster, no?
- Shana 17y agoSmart move...Also allows people time to learn the language, and then move into 3 gradually... Go Python People...
- cookiecaper 17y agoI 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).
- jacquesm 17y agoI wonder how much it was ever in doubt that this would happen, when a 'benevolent dictator for life' wants something it happens. 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.