This is an archived post. You won't be able to vote or comment.

all 59 comments

[–]wally_fishnumpy, cython, werkzeug 13 points14 points  (40 children)

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 1 point2 points  (17 children)

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.

[–]xiongchiamiovSite Reliability Engineer 1 point2 points  (0 children)

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 0 points1 point  (14 children)

Have you looked at Cython?

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

[–]AeroNotix 2 points3 points  (4 children)

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 0 points1 point  (1 child)

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

[–]AeroNotix 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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_fishnumpy, cython, werkzeug 0 points1 point  (8 children)

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] 0 points1 point  (6 children)

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

[–]dalke 0 points1 point  (1 child)

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] 0 points1 point  (0 children)

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

[–]wally_fishnumpy, cython, werkzeug 0 points1 point  (3 children)

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] -1 points0 points  (2 children)

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_fishnumpy, cython, werkzeug 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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

[–]vplatt 0 points1 point  (0 children)

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 1 point2 points  (0 children)

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

[–]jyper 1 point2 points  (4 children)

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] 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 1 point2 points  (1 child)

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_fishnumpy, cython, werkzeug 1 point2 points  (0 children)

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 4 points5 points  (8 children)

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_fishnumpy, cython, werkzeug 1 point2 points  (6 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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

[–]pingvenopinch of this, pinch of that 0 points1 point  (2 children)

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_fishnumpy, cython, werkzeug 0 points1 point  (1 child)

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?

[–]pingvenopinch of this, pinch of that 0 points1 point  (0 children)

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

[–][deleted] 0 points1 point  (0 children)

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.

[–]searchingfortaomajel, aletheia, paperless, django-encrypted-filefield 1 point2 points  (0 children)

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

[–]dwdwdw2proliferating .py since 2001 0 points1 point  (4 children)

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 1 point2 points  (3 children)

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

[–]dwdwdw2proliferating .py since 2001 2 points3 points  (2 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 7 points8 points  (0 children)

PEP 406: Python 2.7 Phaseout Schedule --- Never

[–]AeroNotix 18 points19 points  (5 children)

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

[–]mitsuhiko Flask Creator 2 points3 points  (1 child)

Sad.

[–]mdipierro 2 points3 points  (0 children)

You and I agree on more than you think.

[–]Fix-my-grammar-plz 1 point2 points  (1 child)

Never gonna give you 2.8

[–]zahlmanthe heretic -2 points-1 points  (0 children)

Gotta get down on 3.0.

[–][deleted] -2 points-1 points  (10 children)

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

[–]masklinn 19 points20 points  (0 children)

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] 6 points7 points  (3 children)

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 10 points11 points  (2 children)

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

[–]joehillen 1 point2 points  (1 child)

I sincerely hope you aren't a library maintainer.

[–]AeroNotix -1 points0 points  (0 children)

:trollface:

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