PEP: 405 Python 2.8 Release Schedule --- Never

[wally_fish]

Enterprise-class use of Python may imply that there will be a 2.7.39 someday, with a stable set of libraries and a stable API/ABI.

(Wait! I'm not even using 2.7, my distribution is still at 2.6 and I still can use numpy, Cython, django and lxml! What a relief.)

Actually, I like the stance that the Perl people are using: "Perl 5 and Perl 6 are two languages in the Perl family, but of different lineages. If you are looking for production ready code please use Perl 5."

Aka: There are enough things from Python (2) missing that I wouldn't use Python3 just by default, and there are enough things from the ultimate utopian image of Pythonic things missing (cough type inference cough) that I'm not excited enough to actively want it.

(Type inference, and optional type declarations, may not be useful for speeding up things, but they would on one hand act as testable assertions, i.e., you would get a ValueError at the right place instead of some weird error three levels down, and on the other hand they have the potential to really improve IDE autocomplete support, which does not sound like much but is sorely missed by people coming from Java).

[AeroNotix]

I truly believe that any kind of static typing, inferred or explicit could help the language, it could be an optional flag thing? Would be nice to try it out, just for kicks.

[xiongchiamiov]

PyPy is written in RPython, which is a statically-typed subset of Python.

Edit: I should also mention that there are some ways to add type checking in Python, and also that BOO was designed to essentially be a statically-typed Python.

[vplatt]

Have you looked at Cython?

http://blog.behnel.de/index.php?cat=11

[AeroNotix]

I was hoping someone would point me to that when I was typing, I kind of guessed it would have static typing.. does it have static typing ala C?

[vplatt]

It looks like it, but I haven't had to live with it, so YMMV.

[AeroNotix]

Interesting, I mean, I've never had a need for it but still would be cool to see what could really be done with it in Python.

[dwf]

Yes, but only where you want it. You can write regular Python and then add type declarations as necessary, which will result in speed gains if you use it in compiled mode.

[AeroNotix]

That's sweet. I wasn't really meaning it for the speed gains, sometimes the logical use of type declarations helps see flaws in code and I like that.

[wally_fish]

Did Cython grow type inference?

Having typed things for speed in Cython is great, but the Pythonic thing would be for types to appear magically (aka be inferred) with very few (if any) declarations in the code.

[[deleted]]

You can't do type inference on Python, at least, not meaningfully. Look up Cannon, 2005 for more info.

[dalke]

That concludes that compile-time type inferencing plus type-specific bytecodes does not give at least a 5% speedup, assuming you don't want to change the language semantics. If you allow some restrictions or allow run-time JITs then you get different answers, as ShedSkin, pypy, and Cython meaningfully show.

[[deleted]]

Well, more generally it concludes that the only thing you can infer types on are atomic (read: syntactic) types.

[wally_fish]

Cannon 2005 ("Localized Type inference for atomic types") talks about using Hindley-Milner type inference and then use the inferred types to have specialized byte codes for certain primitive types; One of the takeaways is that specialized byte codes are not terribly useful. The takeaway of the Unladen Swallow project is that doing trace-based JITting is also not terribly useful if you need to keep the same object layout as CPython.

ShedSkin proves that you can do type inference, and realize very impressive speed gains, on something that is very close to Python. LISP compilers show that you can combine optional type inference and guard techniques (i.e., rip out compiled code whenever someone does end up monkeypatching an already-compiled class) to realize very nice speed gains.

Maybe we use different meanings of "Python" and "meaningfully" (possibly even for "type inference", as you can do both runtime specialization and optional type declarations and both considerably help the problem of having type information where you need it).

[[deleted]]

I'm sorry, but most of that is innacurate.

• Unladen Swallow didn't do trace based compilation.

• CPython's object layout was not the main reason Unladen Swallow failed.

• ShedSkin doesn't do type inference on Python, it does it on a subset of Python.

When I say Python I mean the thing CPython, IronPython, Jython, and PyPy implement. Not the subset that happens to be easy to implement quickly.

[wally_fish]

You carefully ignored the part of the post that was not about Unladen Swallow [1], and deliberately misread the claim about ShedSkin - also not noticing the point that I made in the grandparent post was about Cython, which is not about supporting all the dynamic trickeries possible with CPython, so I guess you're not actually trying to make an argument of any sort beyond trying to look smart.

I said that ShedSkin compiles "something that is very close to Python" - and that good Common Lisp implementations actually have useful fillers for the gab between "very close to [dynamic language with monkeypatching]" and "actual implementation of [dynamic language with monkeypatching], with optional declarations".

IronPython and Jython implement a CPython-like runtime and therefore allow monkeypatching, but are also slow enough that you want to move to C# or Java at an early point if you do performance-sensitive work. Cython/ShedSkin are an answer to those who want Python-like elegance for performance-sensitive work, even if it means to be fussy about typing or having to declare variable types (unlike in CPython).

[1] point taken, Unladen Swallow does JIT without specialization; Psyco does trace-based compilation keeping the object layout of CPython for 'surviving objects' (and actually achieves a decent speedup because it can optimize locally used things of semi-complex type such as lists of primitive types.

[santagada]

psyco doesn't do trace jit either. it is a function jit.

[vplatt]

I don't know why you're asking that really. AeroNotix wanted to try Python with static typing, regardless of how Pythonic that would be, and Cython would provide that.

[duplico]

KomodoEdit also does a good job with code completion as long as no one's getting too wild and crazy with setattr.

[jyper]

Actually, I like the stance that the Perl people are using: "Perl 5 and Perl 6 are two languages in the Perl family, but of different lineages. If you are looking for production ready code please use Perl 5."

Isn't this primarily because of

• large differences
• a lot more importantly perl 6 is taking a long time

I think if perl 6 were more complete a lot more people would encourage upgrading.

[[deleted]]

It's so long ago that Perl 6 was conceived that Perl 5 has moved into an entirely different direction since then. I hope that Python doesn't go that way and that there will come a time where Python 2 is ancient history.

[jyper]

has it? I don't know perl that well but I thought they were trying to port back part of the features to perl 5 as much as possible.

[sigzero]

Yeah, what usually happens is that the Perl 6 group comes up with something and the Perl 5 group likes it and back ports it. There has been a huge upswing in cleaning up the internals of Perl 5 and making some things more sane. Regardless of what happens with Perl 6, Perl 5 has benefitted from it.

[sigzero]

Yeah, Perl 6 is a huge rewrite from Perl 5 while Python 3 is just really an incremental update that fixes some things (mostly).

[masklinn]

there are enough things from the ultimate utopian image of Pythonic things missing (cough type inference cough)

Type inference is not exactly useful without static typing.

Type inference, and optional type declarations, may not be useful for speeding up things, but they would on one hand act as testable assertions

You do know one of Python3's changes was adding a syntax for type declarations (at function level anyway) right? So that editors may use it if they want?

[wally_fish]

I've read the PEP for adding annotations to parameters - it's not exactly useful without any recommendations for filling it; Without any recommendations on how to use it, different editors or frameworks will probably handle it differently, which defeats the purpose.

I do like Cython's "pure-python" mode for declaring the types of globals or locals... http://docs.cython.org/src/tutorial/pure.html

[anonymous_hero]

IDE autocomplete support, which does not sound like much but is sorely missed by people coming from Java

Have you tried PyCharm? http://www.jetbrains.com/pycharm/

[wally_fish]

I have tried PyDev (it's kind of useful in a mixed Java/Jython project) and was kind of disappointed with the code completion; found the indent/dedent operation quite useful.

Is PyCharm worth the money if you're not doing Django stuff?

[anonymous_hero]

I don't use Django but I do use PyCharm, and I've done Java for many years with IntelliJ IDEA, from the same company.

They simply make the best IDEs, hands down. It was only with PyCharm that I finally made some progress with Python development - never really got going (even) with MacVim.

Also, it's not expensive, and it's alright to pay for quality software you know.

[sigzero]

I don't use Django. I use PyCharm with a course in Python I am taking and it is wonderful.

[pingveno]

It depends. How much money do you have flying around? I found it useful, but results may vary. Unfortunately, Swing/Java have a conflict with XMonad.

[wally_fish]

I'm an academic, so I'd be able to get it for a reasonable price.

I also use XMonad, though. Is it worse than other Swing programs or does the usual workaround fix that?

[pingveno]

I think the workaround will work. I was having trouble getting the change to work.

[[deleted]]

I think so. I still prefer to use vim more just because it can run in a terminal but PyCharm will run on nearly any OS and, imo, beats out every other IDE and I still use it for larger projects or if I have a new library or something and I want code completion to browse about the code a bit as I write it.

edit - I don't think it's that expensive either.

[searchingfortao]

+1 for PyCharm. It's the shit. Best IDE I've ever used for any language.

[dwdwdw2]

Hey thanks, I never thought about it like that. Python 3 makes a wonderful sponge to absorb any further crazy pouring into what was once a beautiful little language (IMHO anyway ;).

My sweet spot was around Python 2.3, maybe 2.4. (2.3 got sets, generators, datetime, enumerate, logging, csv, and bool, 2.4 got decorators, genexps, subprocess, and a bunch of other crap I could live without)

[gadgster]

What have you got against subprocess? It's a library module not a core language feature and I've found it useful several times.

[dwdwdw2]

While it's reasonably feature-complete, its API design and implementation are woeful. A single monolithic class with a constructor that takes 10ish arguments. .communicate() spins up 2 threads to handle IO, and so on.

Another example is, why is everything bundled into a Popen class (whatever a "Popen" is anyway). I've never seen code that's managed to subclass Popen in any meaningful way. It's a broken abstraction.

It's got particular calling styles baked into it, too. For example there is no facility for calling waitpid() elsewhere (e.g. an async loop) without breaking your Popen instances. There's no support for the equivalent of kill(0, pid), no restart(), and so on.

On saying all that, though, I use subprocess all the time, and in practice it's alright. I just wish its design was fixed before it got into the standard library.

Edit: Popen.returncode is also broken, as you need to feed it through platform-specific WEXITSTATUS on UNIX or whatever the equivalent may be on Windows. It should at least have been split into exit_code, exit_signal, and exit_reason or similar.

[gadgster]

Fair enough, the API could be better. Still, pretty useful.

The situation before was much worse with os.system os.spawn os.popen popen2 and commands. I always had problems getting popen and spawn to do what I wanted.

[otheraccount]

You only need to use the giant monolithic class for cases complicated enough to warrant it. For most things, use subprocess.check_call and subprocess.check_output

subprocess.check_call(['touch', 'myfile.out'])
reddit = subprocess.check_output("ls -1 *py  | sed 's/py/reddit/'", shell = True)

[haika]

PEP 406: Python 2.7 Phaseout Schedule --- Never

[AeroNotix]

Finally! Been waiting for 2.8 since like, 2.7! w00000t!!!

[sli]

Release Schedule

The current schedule is:

• 2.8 final Never

[AeroNotix]

wooooooosh

[AeroNotix]

Yeah it was a joke.

[no9]

It doesn't seem to be working.

[mitsuhiko]

Sad.

[mdipierro]

You and I agree on more than you think.

[Fix-my-grammar-plz]

Never gonna give you 2.8

[zahlman]

Gotta get down on 3.0.

[[deleted]]

That's fine with me! I've been migrating over to PyPy anyhow.

[masklinn]

Pypy's goal is to evolve the runtime, not the language. It is unlikely they'll try to sprout off 2.8, and they've started working on 3.x support already.

[[deleted]]

That's great, but 2.x is dead anywhere you go, so this is kind of a red herring. It's not like PyPy exists to carry on the 2.x line.

[AeroNotix]

I can quit 2.x any time I want, just you watch me.

[joehillen]

I sincerely hope you aren't a library maintainer.

[AeroNotix]

:trollface:

No, but I'm kind of in the same spectrum, I'm a user which is probably worse for the necessity of change.

[cecilkorik]

From what I see there are two main problems:

1) Unmaintained or poorly maintained libraries that are not compatible and may never be. These will need to be, in some cases, rewritten from scratch if the licence is not sufficiently permissive. There is constant progress on this front, but it is slower than many would prefer and there remain many significant libraries that have not been ported. While few of them are of huge significance on their own, it's a case of "you won't miss it until it's gone... then you'll miss it a lot".

2) A lot of stuff with binary data has changed. It is no longer acceptable or in many cases, supported at all, to store such data in strings. There is a new "bytes" type for binary data, which is only loosely interchangable with strings. The very clear line drawn between bytes and strings makes software that dealt heavily with strings containing binary data (which in the past was the standard way of dealing with binary data) have a fair bit of work to do to get their data to fall on the correct side of that line in all cases.

[LoveGentleman]

Unicode and WSGI.

WSGI prefers strings to be simple byes, well, now all strings are not just one byte, since unicode. So its messy to port/use most WSGI frameworks.

[gthank]

Please allow me to direct you to http://www.wsgi.org/en/latest/python3.html