9 ms·

What happened to Python?

51 points by happy-go-lucky 10y ago

nicolaslem 10y ago
The conclusion to stick to Python 2 just because the author does not like some optional features added in Python 3 seems far fetched. While the typing thing has been discussed here yesterday[0], I share his views about asyncio. I was a bit disappointed when asyncio lost its provisional status in Python 3.6. I was hopping that the community will wait a bit more and settle on something else. The work that David Beazley does on Curio[1] is amazing. This should be an inspiration for the standard library in my opinion. [0] https://news.ycombinator.com/item?id=13730494 https://news.ycombinator.com/item?id=13730494 [1] https://github.com/dabeaz/curio https://github.com/dabeaz/curio
- jimnotgym 10y ago
  I guess thats the point though, you don't have to use asyncio, in the same way most use requests rather than urllib.
- spangry 10y ago
  Agreed on Curio. Although async will probably never be straightforward (at least not in the way sequential execution is), grasping Curio is a walk in the park compared to learning the mystical magic of Asyncio. I would also just add, more generally, that while the standard library documentation is extensive, if there is any organisation principle behind it I have yet to discover it.
- scriptkiddy 10y ago
  Python has a history of treating standard library modules as a sort of reference implementation. Look at urllib and urllib2 for example. No self respecting Python dev will use either of those two packages if they can help it. They'll use requests instead. Other examples include Python's standard library json/xml parsers. Nobody really uses them out of the box. In my work, the only standard library module I really use extensively is the collections module.
  - nicolaslem 10y ago
    It's funny I have the exact opposite approach to the standard library. Sure some modules like urllib are really bad and I avoid them, but for the rest when the standard library gives me something I use it. I often find myself going through the standard library documentation and it's a real pleasure to read and discover things that I didn't know were just an import away. I use the standard json module all the time and I never felt like it was holding me back. I don't write performance critical software so I tend to value the simplicity more than the performance gain.
    - scriptkiddy 10y ago
      In the case of the Json module, I totally agree. I'm not really concerned with Performance either. It's mostly API flexibility that I care about. I mean, urllib is always such a great example of an overcomplicated and inflexible API with bad naming conventions. The Json module really did a good job in learning from previous mistakes. `json.loads()` and `json.dumps()` couldn't be any easier to use. Though, I would argue that the json module's ease of use is owed more to the fact that Python dictionaries map pretty much 1-to-1 with JSON already.
jimnotgym 10y ago
I'm afraid I cannot agree with the sentiment in this . The Python3 equivalent of his first example is no more complicated than the Python2 one he shows. You don't have to use decorators or type annotations. It is there if you want it > Did Python sell out? I don't know. Maybe Guido caved to some persuasive people with bad ideas. Maybe communists, wanting to reduce global productivity, railroaded through all these garbage PEPs. Maybe Python wanted to throw off its reputation as a toy language and become a serious language like Node.js... Whatever the case, when I look at all the PEPs that have been accepted over the past couple years, I can see that the inmates are now running the asylum. If you and a billion other people want Python2 so badly, fork it and keep developing it. If the maintainers want to push a language in one way, that is their prerogative! It is their time they are using.
- thehardsphere 10y ago
  > If you and a billion other people want Python2 so badly, fork it and keep developing it. If the maintainers want to push a language in one way, that is their prerogative! It is their time they are using. Seriously. If all of the time spent on whining on the Internet about how python3 killed the dinosaurs was used to make a python2 interpreter, a viable fork would already exist. I mean, there's allegedly a great economic incentive for it, right? All of these business-critical python2 apps are out there, so the whiners claim, you'd think somebody would pay for one if it was actually so much better than python3.
  - perlgeek 10y ago
    There's a fork that was featured on HN a while back, called python2.8 back then, now apparently it's https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon (FTR I'm one of the folks that think Python 3 is an improvement over Python 2 but we still have a monster 2.7 code base that won't be ported any time soon).
    - yokohummer7 10y ago
      Funny, it seems that, by the standards of the OP, the fork you mentioned is not "Python 2" either. It backported type annotations, async/await, and many more from Python 3. So when are we expected to see a "true" Python 2 fork? :)
spangry 10y ago
It's hard to disagree with the author's assessment of asyncio. It may just be because I'm stupid, but I cannot get asyncio to fit in my brain no matter how many attempts I make to learn it. Another HN thread on python strings got me thinking about the print() function. This is going to sound a bit trivial but bear with me. Although I agree that print() is more consistent with how functions are called in Python, I can totally see how irritating it would be for a Python 2 programmer. It's also just generally disruptive to typing flow: when you've finished typing the word 'print' your hands are 'out of position', making it a bit jarring to type the open parenthesis. This has me wondering: is there a language out there where deliberate thought has been put towards typing ergonomics and fluency? And I wonder if such a language would have a material impact on developer productivity?
- metafunctor 10y ago
  So little time in programming is spent typing that it would make little sense to optimize a general purpose language for typing speed. Reading, modifying and reasoning about programs are much, much more important.
- deleted 10y ago
  [deleted]
- digler999 10y ago
  > I cannot get asyncio to fit in my brain I found it extremely (to the point of a frustration-induced mental breakdown) hard. I still can't fit it all in my brain, but I got enough so that my code works. The best explanation I can give is by analogy: think of the kernel of an OS, and how it spreads CPU time across all the processes. Sometimes processes know they dont need to work, say they're waiting for a disk read, or a network message, so they surrender and say "ok kernel, I'm done for now, let someone use CPU". Thats like what the "yield" command does in asyncio, although yield requires a context. So you say "yield until this function does something interesting" (I think it's called 'await' now), then a mini-"kernel" (the io service) stops executing that function and polls all the other functions to see if any of their yields have changed state. It just keeps polling till it finds some work it can do. I dont yet fully grok the futures yet, but I think they're just a way of packaging up the "work item" produced when a yield actually gives you something. * Disclaimer: I barely understand this, so if I'm spreading bad information I apologize in advance. I have nothing against asyncio in python, I think its presence helps put python in the "big leagues" of languages, and not just a toy for noobs with arduinos. It's an additional language feature, like C++ templates. You dont have to use it, so the noobs can keep doing their thing. But it prevents more experienced devs from outgrowing the language and having to learn a new one, or port working code to a new language.
cagataygurturk 10y ago
> Maybe Python wanted to throw off its reputation as a toy language and become a serious language like Node.js... Is this a serious statement?
- thehardsphere 10y ago
  It may be a serious statement that shows the author is a person not to be taken seriously.
  - nilkn 10y ago
    I think you're overlooking the subtle jab of that sentence. He's denigrating Python 3 by comparing it to Node.js.
    - thehardsphere 10y ago
      He also called Node.js a "language" so I question whether he's capable of that much subtlety.
- fideloper 10y ago
  I read it with a heavy dose of sarcasm, but I suppose it could have been a genuine statement >.>
  - mafro 10y ago
    Surely sarcasm. Surely.
- blhack 10y ago
  I think that is the author talking about how (in their opinion) Python has gone from an elegant language that a beginner could easily learn, and understand, to a confusing stringy one that is difficult to follow. The beauty of Python is that you can learn it quickly, and then it can take you anywhere you want to go. That is quite the accomplishment, and that is why it is the perfect language for beginners. I think the authors statement is meant to contrast those properties with node.js, which imho has neither of the, and is also asynchronous by default; something I think makes it unnecessarily difficult for first-language learners to approach.
Alir3z4 10y ago
In latest version of Python it would be: def hello(name): print('hello', name)
jsnathan 10y ago
I may be in the minority with this here, but I mostly agree with this post. Python 2 is a simpler, and possibly more elegant language than Python 3. It's true that most of these new features are optional, but that doesn't change that code tends to be written differently in these two languages. I think the relationship between Python 3 and Python 2 is similar to the relationship between C++ and C in that regard. The goal that all new Python code will eventually be written in Python 3, I don't think will ever be achieved [1]. Personally I'm not using Python much these days, but when I do use it, I still prefer 2.7 [1]: https://semaphoreci.com/blog/2016/11/11/python-versions-used-in-commercial-projects-2016-edition.html https://semaphoreci.com/blog/2016/11/11/python-versions-used...
- StavrosK 10y ago
  > Personally I'm not using Python much these days, but when I do use it, I still prefer 2.7 Why? It mystifies me utterly that people think that having the option to do something is a burden. What is it about asyncio just sitting there in the stdlib that you find heinous? I don't use the shelve package either, but I never thought "I need to find a language where I can't easily import this monstrosity".
  - reikonomusha 10y ago
    The fact it's there means you'll probably come to a point where you'll have to interact with it by way of someone else's library, unless you NIH everything.
    - StavrosK 10y ago
      Is the alternative of interacting with some other, less supported/ubiquitous/documented package preferable?
      - reikonomusha 10y ago
        Perhaps not. All I'm claiming is that an "optional feature" isn't as free to avoid as one might think.
cgrubb 10y ago
I upgraded from 2 to 3 last year. I'm liking it. I've embraced type hints. Although they have no run-time effect, there is a command line tool called mypy which enforces correctness. It has caught more than a few errors for me. Declaring the types of arguments and return values is a help when reading the code imo.
- lexy0202 10y ago
  This. Running a script which takes hours to execute, only to find you have a TypeError on the last line just before you get the results you need is really frustrating. Static typing is a must-have imo.
  - FraaJad 10y ago
    you will probably like Nim - https://nim-lang.org/ https://nim-lang.org/ if you like Static Typing in a pythonish language, and writing long running (perhaps CPU intensive) tasks.
    - throwaway7645 10y ago
      Agreed
deleted 10y ago
[deleted]
anc84 10y ago
This might be hyperbolic sarcasm. If not, it's silly. Nothing to lose by not giving it your attention.
gigatexal 10y ago
This post screams of python 2 whining and the like with a general unwillingness to evolve with the language.
rbanffy 10y ago
Isn't it great there are enough languages that everyone can be happy?
- ajmurmann 10y ago
  That was partially the author's point. However, he came from the other direction: If you want a statically typed language with powerful asynchronous tooling then maybe Python is not the right choice. There are already languages that are great at that. So why make Python that's already great at being Python less good at being Python and instead into something that other languages are already great at?
  - rbanffy 10y ago
    Being the annotations (and asyncio) optional, how would that make the language any worse?
kennydude 10y ago
Node has a similar thing with these "async" commands and such. You don't have to use them. Python 3 is where the world is moving to, doesn't mean we're all turning async.
luhn 10y ago
> The garbage fire that is asyncio dramatically increases the complexity of the language. Despite asyncio being just one module among others, one might as well consider it built-in, because it is integrated so deeply in the object model and syntax. I don't quite understand. You can easily use Python without knowing asyncio exists. The last time I ever thought about asyncio while programming Python was when I was using asyncio.
hasenj 10y ago
What happens is people realized that python is not reliable enough for serious business applications and they to fix that. After experiencing static typing with TypeScript I don't really want to go back to dynamic typing.
- crdoconnor 10y ago
  >After experiencing static typing with TypeScript I don't really want to go back to dynamic typing. Javascript's main failing wasn't a lack of static typing it was a lack of type safety (which statically typed C also suffers from). Python didn't suffer from this. If you tried to convert an invalid string to an integer it won't just try and have a bad guess at what it thought that you meant (C, Perl and JS's default behavior), it would raise an exception instead.
  - hasenj 10y ago
    No the problem is when you have a method that takes three parameters you want know what these parameters are and what you can do with them. Trying to figure this out in a dynamically typed language is not fun. In TypeScript (with a decent editor, like VSCode) you just hover the parameter and you can immediately see what it is.
    - crdoconnor 10y ago
      >Trying to figure this out in a dynamically typed language is not fun. Sure it is. Fire up the IPython REPL at the point in the code where you're intending to use it and experiment. Not only can you see what it takes, you can see what it does in real time and you can experiment on the results. >In TypeScript (with a decent editor, like VSCode) you just hover the parameter and you can immediately see what it is. Well, you can see that it's a string of some kind.
  - vram22 10y ago
    >C, Perl and JS's default behavior That is the default behavior of Perl?
StavrosK 10y ago
I don't generally flag articles, but this one is so pointless and inflammatory that I had to flag it as flamebait.
- vram22 10y ago
  Have you checked out who the author is? I am not sure it qualifies as flamebait. The situation may be a bit more nuanced. I first read some of the comments in this thread, then went and read his article, then came back here to read some more comments. Charles Leifer (per his resume [1]) is a co-creator of readthedocs.org (where the docs for a lot of Python OSS projects are hosted), and of the PeeWee ORM (which I know of and have used a bit). [1] http://media.charlesleifer.com/blog/documents/resume.pdf http://media.charlesleifer.com/blog/documents/resume.pdf He also writes a lot of (technical) Python posts on his blog. I've read some of them in the past. Unlikely that a person like him would be interested in writing such a post as flamebait. I'm guessing the post is describing his genuine thoughts / feelings (right or wrong) about Python's evolution of late, even if some of his points may not have been well-thought-out, per what I read from some comments here. I haven't gone into an analysis of what he wrote vs. the comments here, in depth. But I think we should cut him some slack, and not flag the post as flamebait. Just my 2c as a Pythonista and HNer.
  - StavrosK 10y ago
    I guess my characterization of "flamebait" was unfair in that it implies intent. I actually meant "inflammatory", because the post makes a huge deal out of what is, in my opinion, not really so bad. I even agree that asyncio is a clusterfuck, but we're free to use Curio (which looks much better), and if you don't like how complicated type annotations make the language, don't use them. I agree that they've been bolted on rather clumsily (having to import the type system feels weird), but it's nowhere near as big a deal as the author makes of it, and I feel the post makes mountains out of molehills.
gillianlish 10y ago
fuck all y'all, im still using python 1
tghw 10y ago
tl;dr If you use Python 3 in ugly ways, it will be much uglier than if you use Python 2 in pretty ways.
pdabbadabba 10y ago
This is pretty exaggerated. I've been in coding in Python for more than 10 years and I only rarely encounter code that suffers from the issues this article complains about, including Python 2 and 3. And the reason, of course, is that this article focuses on complex cases like chained asynchronous functions and optional type decoration but criticizes them as though they were representative of typical Python code. Yes, if you want to write a system of asynchronous functions with type decorations, then yes it can get a little messy. But this isn't Python becoming less "austere and easy to read" over time, this is just identifying a case where Python is less readable than one might like. I'm not sure what to tell you if you were looking to write asynchronous code without some amount of syntactic cruft. There are languages that can do this with a prettier syntax and less boilerplate (Go, maybe). But I don't think has ever included any version of Python.
- lima 10y ago
  Not to mention that it'd be even more messy if you were to add type annotations and async in Python 2.
pryelluw 10y ago
I put off upgrading to Python3 for a while because I was working on a codebase that had dependencies stuck in Python2. After moving on to the next gig, I started using Python3. Differences? Python3 has many nice optional features, and it fixed the unicode issues. That's it. People act like this is such a huge thing when it is not.
lngnmn 10y ago
Yeah, async is madness. The part of asynchronous and reactive mass-hysterias. Very few applications really require AIO and/or coroutines, and spawning a coroutine for each I/O request is a madness indeed. Last but not least, such kind of API should be general and minimalistic, the way Erlang does its processes. Or how Plan9 does I/O via general protocol. Unfortunately, Python guys are looking in a wrong direction (is that C#?) for inspirations.
throwaway7645 10y ago
Just come to Perl6...has all the nice things Python3 has plus a bunch in a really nicely designed package. Seriously, it is much prettier than the linenoise people think of with Perl5. The only problem is the implementation is very young and immature (but it gets daily fixes and improvements). Perl6 is a completely new language designed from the ground up over 15 years. It has some syntactical similarities though. Sometimes I wish Python would do the same thing and start over on LLVM like Crystal, or do something closer to Perl6. If you just want a simple scripting language, Lua and Rebol are nice and Red (when finished) will be like Rebol on steroids.
- vram22 10y ago
  Interesting. What online resources and books would you recommend to learn Perl6?
  - throwaway7645 10y ago
    There is an excellent Perl6intro tutorial out there for a lightweight overview along with learn x in y minutes to start. Diving deeper, there are several books that either just came out or are about to come out. I think they have links on the Perl6.org site. In particular, there is a recent O'REILLY release that you can read now, but still has a month until the paper edition is finished (Think like a Data Scentist with Perl6 by Laurent Rosenfeld) and it is very good as something that covers a lot, but not too crazy. Brian d Foy had a successful kickstarter to do a Learning Perl6 book (he has written several versions of Learning Perl5). There is a rumor that Larry Wall is working on a Perl6 version of his Programming Perl (Camel book). Probably one of the best resources is Rosetta Code. I really like how you can still use it for quick and dirty code, yet still write beautiful OO or FP code. It has what they call gradual typing in that it is dynamic like python, but you can add types to functions that help to catch lots of errors. Curtis "Ovid" Poe gave a Perl6 talk (slides and video online) that show how you can take something like the standard recursive Fibonacci sequence and restrict the input to an int that is greater than or equal to zero (it can even be more powerful than that). Despite what some might call feature overload, I've been pleasantly surprised by how easy parts are to grok and how well it fits together. Grammars as part of the language are especially cool. They've even built grammars to parse and execute Python, Lua, Perl5, and Scheme. So you can essentially use any Python library in your P6 script.
cletus 10y ago
I suspect the debate about Python3 will never end. My thoughts on this are: - Python2 seemed to enjoy some success because of its simplicity - Python3's breaking changes seemed ill thought out. As an example, PEP-414 [1], which reintroduced explicit Unicode string literals to ease porting Python2 to Python3. The fact that it was removed in the first place suggests there was a lack of thought about or concern for the effects of breaking changes. It's almost like once the decision was made to make breaking changes then considerations about porting and libraries maintaining compatibility between the two were of no concern. - IMHO there has been a shift away from dynamic languages that came at a rather bad time with the schism in Python land. - Non-backwards compatible changes have often gone badly. Perl5 to Perl6. PHP 6. Python 3. I mean gone badly in the sense that it seemed to hurt adoption, at least for awhile. - It seems like statically typed languages have somewhat supplanted some of the use cases for these languages. I'm thinking of Go as one specific example. The way I like to put it is that dynamic languages force you to have unit tests for spelling mistakes and typos. If you compare the Python3 async stuff with Go's I honestly think Go is more elegant here. - Lastly of course there's the GIL. I think this is increasingly becoming a problem in a multi-core/multi-threaded world. The GIL design really does simplify writing C extensions. This makes Python pretty convenient and well-suited for certain tasks. I'm thinking specifically of things using Numpy. Anyway I'm not saying you can't write, say, high-performance Web servers in Python with AsyncIO/gevent loops and the like. It's just not as... elegant and simple as things seemed back in the days when Python 2.7 was state of the art. [1] https://www.python.org/dev/peps/pep-0414/ https://www.python.org/dev/peps/pep-0414/
lima 10y ago
I have extensive experience working with Python 2, 3, asyncio and gevent so I'll comment on some of the points in this article. Python 2: def hello_world(name): print 'Hello', name Python 3: def hello_world(name): print('Hello', name) > The language, which was once simple and elegant, has become complicated and clumsy Python 3 is just as simple to use as Python 2 (simpler, even due to all the cleanup that happened - just think about the encoding mess in Python 2). What happened is that new, powerful features got added to Python 3 that solve specific issues that people were having. It's entirely optional to use these, but they make life much easier if you need them. Async programming is only really applicable to highly concurrent network programming or other applications that spend a lot of time waiting for IO. For everything else it's just unnecessary overhead. It is inherently complicated. In particular, the async/await paradigm is extremely powerful. I first encountered it in C# and immediately fell in love with it, and I'm happy to see major languages like Python and JavaScript adopt it. It makes clear where you hand off control back to the event loop and prevents all sorts of bugs where you'd accidentally block the main thread by invoking blocking IO. gevent, in comparison, is an ugly workaround that hides all of the complexity behind async programming. By monkey patching all IO libraries to be magically async, it makes it impossible to reason about the execution flow and it's extremely easy to get it wrong. That is an affront to the Zen of Python (Explicit is better than implicit). Type annotations are just a standardized way to do what large projects were doing anyway - documenting types. By moving it out of the docstrings and formalizing it, it opens the door to strict type checking. The resulting ugliness reflects the difficulty of typing a dynamic language and you only need it if you want strict type. You can write untyped code just fine. > I'm not even debating the value of type annotations [...] And why do this when there are hundreds of other languages out there that are statically typed? Do I have to point of the irony?
singularity2001 10y ago
I will start liking python 3 once print(str(b'hi')) will print just 'hi' That is: UTF-8 should be the default encoding, at least let me specify it somewhere.

The conclusion to stick to Python 2 just because the author does not like some optional features added in Python 3 seems far fetched. While the typing thing has been discussed here yesterday[0], I share his views about asyncio. I was a bit disappointed when asyncio lost its provisional status in Python 3.6. I was hopping that the community will wait a bit more and settle on something else. The work that David Beazley does on Curio[1] is amazing. This should be an inspiration for the standard library in my opinion. [0] https://news.ycombinator.com/item?id=13730494 https://news.ycombinator.com/item?id=13730494 [1] https://github.com/dabeaz/curio https://github.com/dabeaz/curio

jimnotgym 10y ago
I guess thats the point though, you don't have to use asyncio, in the same way most use requests rather than urllib.
spangry 10y ago
Agreed on Curio. Although async will probably never be straightforward (at least not in the way sequential execution is), grasping Curio is a walk in the park compared to learning the mystical magic of Asyncio. I would also just add, more generally, that while the standard library documentation is extensive, if there is any organisation principle behind it I have yet to discover it.
scriptkiddy 10y ago
Python has a history of treating standard library modules as a sort of reference implementation. Look at urllib and urllib2 for example. No self respecting Python dev will use either of those two packages if they can help it. They'll use requests instead. Other examples include Python's standard library json/xml parsers. Nobody really uses them out of the box. In my work, the only standard library module I really use extensively is the collections module.
- nicolaslem 10y ago
  It's funny I have the exact opposite approach to the standard library. Sure some modules like urllib are really bad and I avoid them, but for the rest when the standard library gives me something I use it. I often find myself going through the standard library documentation and it's a real pleasure to read and discover things that I didn't know were just an import away. I use the standard json module all the time and I never felt like it was holding me back. I don't write performance critical software so I tend to value the simplicity more than the performance gain.
  - scriptkiddy 10y ago
    In the case of the Json module, I totally agree. I'm not really concerned with Performance either. It's mostly API flexibility that I care about. I mean, urllib is always such a great example of an overcomplicated and inflexible API with bad naming conventions. The Json module really did a good job in learning from previous mistakes. `json.loads()` and `json.dumps()` couldn't be any easier to use. Though, I would argue that the json module's ease of use is owed more to the fact that Python dictionaries map pretty much 1-to-1 with JSON already.

jimnotgym 10y ago

I'm afraid I cannot agree with the sentiment in this . The Python3 equivalent of his first example is no more complicated than the Python2 one he shows. You don't have to use decorators or type annotations. It is there if you want it > Did Python sell out? I don't know. Maybe Guido caved to some persuasive people with bad ideas. Maybe communists, wanting to reduce global productivity, railroaded through all these garbage PEPs. Maybe Python wanted to throw off its reputation as a toy language and become a serious language like Node.js... Whatever the case, when I look at all the PEPs that have been accepted over the past couple years, I can see that the inmates are now running the asylum. If you and a billion other people want Python2 so badly, fork it and keep developing it. If the maintainers want to push a language in one way, that is their prerogative! It is their time they are using.

thehardsphere 10y ago
> If you and a billion other people want Python2 so badly, fork it and keep developing it. If the maintainers want to push a language in one way, that is their prerogative! It is their time they are using. Seriously. If all of the time spent on whining on the Internet about how python3 killed the dinosaurs was used to make a python2 interpreter, a viable fork would already exist. I mean, there's allegedly a great economic incentive for it, right? All of these business-critical python2 apps are out there, so the whiners claim, you'd think somebody would pay for one if it was actually so much better than python3.
- perlgeek 10y ago
  There's a fork that was featured on HN a while back, called python2.8 back then, now apparently it's https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon (FTR I'm one of the folks that think Python 3 is an improvement over Python 2 but we still have a monster 2.7 code base that won't be ported any time soon).
  - yokohummer7 10y ago
    Funny, it seems that, by the standards of the OP, the fork you mentioned is not "Python 2" either. It backported type annotations, async/await, and many more from Python 3. So when are we expected to see a "true" Python 2 fork? :)

spangry 10y ago

It's hard to disagree with the author's assessment of asyncio. It may just be because I'm stupid, but I cannot get asyncio to fit in my brain no matter how many attempts I make to learn it. Another HN thread on python strings got me thinking about the print() function. This is going to sound a bit trivial but bear with me. Although I agree that print() is more consistent with how functions are called in Python, I can totally see how irritating it would be for a Python 2 programmer. It's also just generally disruptive to typing flow: when you've finished typing the word 'print' your hands are 'out of position', making it a bit jarring to type the open parenthesis. This has me wondering: is there a language out there where deliberate thought has been put towards typing ergonomics and fluency? And I wonder if such a language would have a material impact on developer productivity?

metafunctor 10y ago
So little time in programming is spent typing that it would make little sense to optimize a general purpose language for typing speed. Reading, modifying and reasoning about programs are much, much more important.
deleted 10y ago
[deleted]
digler999 10y ago
> I cannot get asyncio to fit in my brain I found it extremely (to the point of a frustration-induced mental breakdown) hard. I still can't fit it all in my brain, but I got enough so that my code works. The best explanation I can give is by analogy: think of the kernel of an OS, and how it spreads CPU time across all the processes. Sometimes processes know they dont need to work, say they're waiting for a disk read, or a network message, so they surrender and say "ok kernel, I'm done for now, let someone use CPU". Thats like what the "yield" command does in asyncio, although yield requires a context. So you say "yield until this function does something interesting" (I think it's called 'await' now), then a mini-"kernel" (the io service) stops executing that function and polls all the other functions to see if any of their yields have changed state. It just keeps polling till it finds some work it can do. I dont yet fully grok the futures yet, but I think they're just a way of packaging up the "work item" produced when a yield actually gives you something. * Disclaimer: I barely understand this, so if I'm spreading bad information I apologize in advance. I have nothing against asyncio in python, I think its presence helps put python in the "big leagues" of languages, and not just a toy for noobs with arduinos. It's an additional language feature, like C++ templates. You dont have to use it, so the noobs can keep doing their thing. But it prevents more experienced devs from outgrowing the language and having to learn a new one, or port working code to a new language.

cagataygurturk 10y ago

> Maybe Python wanted to throw off its reputation as a toy language and become a serious language like Node.js... Is this a serious statement?

thehardsphere 10y ago
It may be a serious statement that shows the author is a person not to be taken seriously.
- nilkn 10y ago
  I think you're overlooking the subtle jab of that sentence. He's denigrating Python 3 by comparing it to Node.js.
  - thehardsphere 10y ago
    He also called Node.js a "language" so I question whether he's capable of that much subtlety.
fideloper 10y ago
I read it with a heavy dose of sarcasm, but I suppose it could have been a genuine statement >.>
- mafro 10y ago
  Surely sarcasm. Surely.
blhack 10y ago
I think that is the author talking about how (in their opinion) Python has gone from an elegant language that a beginner could easily learn, and understand, to a confusing stringy one that is difficult to follow. The beauty of Python is that you can learn it quickly, and then it can take you anywhere you want to go. That is quite the accomplishment, and that is why it is the perfect language for beginners. I think the authors statement is meant to contrast those properties with node.js, which imho has neither of the, and is also asynchronous by default; something I think makes it unnecessarily difficult for first-language learners to approach.

Alir3z4 10y ago

In latest version of Python it would be: def hello(name): print('hello', name)

jsnathan 10y ago

I may be in the minority with this here, but I mostly agree with this post. Python 2 is a simpler, and possibly more elegant language than Python 3. It's true that most of these new features are optional, but that doesn't change that code tends to be written differently in these two languages. I think the relationship between Python 3 and Python 2 is similar to the relationship between C++ and C in that regard. The goal that all new Python code will eventually be written in Python 3, I don't think will ever be achieved [1]. Personally I'm not using Python much these days, but when I do use it, I still prefer 2.7 [1]: https://semaphoreci.com/blog/2016/11/11/python-versions-used-in-commercial-projects-2016-edition.html https://semaphoreci.com/blog/2016/11/11/python-versions-used...

StavrosK 10y ago
> Personally I'm not using Python much these days, but when I do use it, I still prefer 2.7 Why? It mystifies me utterly that people think that having the option to do something is a burden. What is it about asyncio just sitting there in the stdlib that you find heinous? I don't use the shelve package either, but I never thought "I need to find a language where I can't easily import this monstrosity".
- reikonomusha 10y ago
  The fact it's there means you'll probably come to a point where you'll have to interact with it by way of someone else's library, unless you NIH everything.
  - StavrosK 10y ago
    Is the alternative of interacting with some other, less supported/ubiquitous/documented package preferable?
    - reikonomusha 10y ago
      Perhaps not. All I'm claiming is that an "optional feature" isn't as free to avoid as one might think.

cgrubb 10y ago

I upgraded from 2 to 3 last year. I'm liking it. I've embraced type hints. Although they have no run-time effect, there is a command line tool called mypy which enforces correctness. It has caught more than a few errors for me. Declaring the types of arguments and return values is a help when reading the code imo.

lexy0202 10y ago
This. Running a script which takes hours to execute, only to find you have a TypeError on the last line just before you get the results you need is really frustrating. Static typing is a must-have imo.
- FraaJad 10y ago
  you will probably like Nim - https://nim-lang.org/ https://nim-lang.org/ if you like Static Typing in a pythonish language, and writing long running (perhaps CPU intensive) tasks.
  - throwaway7645 10y ago
    Agreed

deleted 10y ago

[deleted]

anc84 10y ago

This might be hyperbolic sarcasm. If not, it's silly. Nothing to lose by not giving it your attention.

gigatexal 10y ago

This post screams of python 2 whining and the like with a general unwillingness to evolve with the language.

rbanffy 10y ago

Isn't it great there are enough languages that everyone can be happy?

ajmurmann 10y ago
That was partially the author's point. However, he came from the other direction: If you want a statically typed language with powerful asynchronous tooling then maybe Python is not the right choice. There are already languages that are great at that. So why make Python that's already great at being Python less good at being Python and instead into something that other languages are already great at?
- rbanffy 10y ago
  Being the annotations (and asyncio) optional, how would that make the language any worse?

kennydude 10y ago

Node has a similar thing with these "async" commands and such. You don't have to use them. Python 3 is where the world is moving to, doesn't mean we're all turning async.

luhn 10y ago

> The garbage fire that is asyncio dramatically increases the complexity of the language. Despite asyncio being just one module among others, one might as well consider it built-in, because it is integrated so deeply in the object model and syntax. I don't quite understand. You can easily use Python without knowing asyncio exists. The last time I ever thought about asyncio while programming Python was when I was using asyncio.

hasenj 10y ago

What happens is people realized that python is not reliable enough for serious business applications and they to fix that. After experiencing static typing with TypeScript I don't really want to go back to dynamic typing.

crdoconnor 10y ago
>After experiencing static typing with TypeScript I don't really want to go back to dynamic typing. Javascript's main failing wasn't a lack of static typing it was a lack of type safety (which statically typed C also suffers from). Python didn't suffer from this. If you tried to convert an invalid string to an integer it won't just try and have a bad guess at what it thought that you meant (C, Perl and JS's default behavior), it would raise an exception instead.
- hasenj 10y ago
  No the problem is when you have a method that takes three parameters you want know what these parameters are and what you can do with them. Trying to figure this out in a dynamically typed language is not fun. In TypeScript (with a decent editor, like VSCode) you just hover the parameter and you can immediately see what it is.
  - crdoconnor 10y ago
    >Trying to figure this out in a dynamically typed language is not fun. Sure it is. Fire up the IPython REPL at the point in the code where you're intending to use it and experiment. Not only can you see what it takes, you can see what it does in real time and you can experiment on the results. >In TypeScript (with a decent editor, like VSCode) you just hover the parameter and you can immediately see what it is. Well, you can see that it's a string of some kind.
- vram22 10y ago
  >C, Perl and JS's default behavior That is the default behavior of Perl?

StavrosK 10y ago

I don't generally flag articles, but this one is so pointless and inflammatory that I had to flag it as flamebait.

vram22 10y ago
Have you checked out who the author is? I am not sure it qualifies as flamebait. The situation may be a bit more nuanced. I first read some of the comments in this thread, then went and read his article, then came back here to read some more comments. Charles Leifer (per his resume [1]) is a co-creator of readthedocs.org (where the docs for a lot of Python OSS projects are hosted), and of the PeeWee ORM (which I know of and have used a bit). [1] http://media.charlesleifer.com/blog/documents/resume.pdf http://media.charlesleifer.com/blog/documents/resume.pdf He also writes a lot of (technical) Python posts on his blog. I've read some of them in the past. Unlikely that a person like him would be interested in writing such a post as flamebait. I'm guessing the post is describing his genuine thoughts / feelings (right or wrong) about Python's evolution of late, even if some of his points may not have been well-thought-out, per what I read from some comments here. I haven't gone into an analysis of what he wrote vs. the comments here, in depth. But I think we should cut him some slack, and not flag the post as flamebait. Just my 2c as a Pythonista and HNer.
- StavrosK 10y ago
  I guess my characterization of "flamebait" was unfair in that it implies intent. I actually meant "inflammatory", because the post makes a huge deal out of what is, in my opinion, not really so bad. I even agree that asyncio is a clusterfuck, but we're free to use Curio (which looks much better), and if you don't like how complicated type annotations make the language, don't use them. I agree that they've been bolted on rather clumsily (having to import the type system feels weird), but it's nowhere near as big a deal as the author makes of it, and I feel the post makes mountains out of molehills.

gillianlish 10y ago

fuck all y'all, im still using python 1

tghw 10y ago

tl;dr If you use Python 3 in ugly ways, it will be much uglier than if you use Python 2 in pretty ways.

pdabbadabba 10y ago

This is pretty exaggerated. I've been in coding in Python for more than 10 years and I only rarely encounter code that suffers from the issues this article complains about, including Python 2 and 3. And the reason, of course, is that this article focuses on complex cases like chained asynchronous functions and optional type decoration but criticizes them as though they were representative of typical Python code. Yes, if you want to write a system of asynchronous functions with type decorations, then yes it can get a little messy. But this isn't Python becoming less "austere and easy to read" over time, this is just identifying a case where Python is less readable than one might like. I'm not sure what to tell you if you were looking to write asynchronous code without some amount of syntactic cruft. There are languages that can do this with a prettier syntax and less boilerplate (Go, maybe). But I don't think has ever included any version of Python.

lima 10y ago
Not to mention that it'd be even more messy if you were to add type annotations and async in Python 2.

pryelluw 10y ago

I put off upgrading to Python3 for a while because I was working on a codebase that had dependencies stuck in Python2. After moving on to the next gig, I started using Python3. Differences? Python3 has many nice optional features, and it fixed the unicode issues. That's it. People act like this is such a huge thing when it is not.

lngnmn 10y ago

Yeah, async is madness. The part of asynchronous and reactive mass-hysterias. Very few applications really require AIO and/or coroutines, and spawning a coroutine for each I/O request is a madness indeed. Last but not least, such kind of API should be general and minimalistic, the way Erlang does its processes. Or how Plan9 does I/O via general protocol. Unfortunately, Python guys are looking in a wrong direction (is that C#?) for inspirations.

throwaway7645 10y ago

Just come to Perl6...has all the nice things Python3 has plus a bunch in a really nicely designed package. Seriously, it is much prettier than the linenoise people think of with Perl5. The only problem is the implementation is very young and immature (but it gets daily fixes and improvements). Perl6 is a completely new language designed from the ground up over 15 years. It has some syntactical similarities though. Sometimes I wish Python would do the same thing and start over on LLVM like Crystal, or do something closer to Perl6. If you just want a simple scripting language, Lua and Rebol are nice and Red (when finished) will be like Rebol on steroids.

vram22 10y ago
Interesting. What online resources and books would you recommend to learn Perl6?
- throwaway7645 10y ago
  There is an excellent Perl6intro tutorial out there for a lightweight overview along with learn x in y minutes to start. Diving deeper, there are several books that either just came out or are about to come out. I think they have links on the Perl6.org site. In particular, there is a recent O'REILLY release that you can read now, but still has a month until the paper edition is finished (Think like a Data Scentist with Perl6 by Laurent Rosenfeld) and it is very good as something that covers a lot, but not too crazy. Brian d Foy had a successful kickstarter to do a Learning Perl6 book (he has written several versions of Learning Perl5). There is a rumor that Larry Wall is working on a Perl6 version of his Programming Perl (Camel book). Probably one of the best resources is Rosetta Code. I really like how you can still use it for quick and dirty code, yet still write beautiful OO or FP code. It has what they call gradual typing in that it is dynamic like python, but you can add types to functions that help to catch lots of errors. Curtis "Ovid" Poe gave a Perl6 talk (slides and video online) that show how you can take something like the standard recursive Fibonacci sequence and restrict the input to an int that is greater than or equal to zero (it can even be more powerful than that). Despite what some might call feature overload, I've been pleasantly surprised by how easy parts are to grok and how well it fits together. Grammars as part of the language are especially cool. They've even built grammars to parse and execute Python, Lua, Perl5, and Scheme. So you can essentially use any Python library in your P6 script.

cletus 10y ago

I suspect the debate about Python3 will never end. My thoughts on this are: - Python2 seemed to enjoy some success because of its simplicity - Python3's breaking changes seemed ill thought out. As an example, PEP-414 [1], which reintroduced explicit Unicode string literals to ease porting Python2 to Python3. The fact that it was removed in the first place suggests there was a lack of thought about or concern for the effects of breaking changes. It's almost like once the decision was made to make breaking changes then considerations about porting and libraries maintaining compatibility between the two were of no concern. - IMHO there has been a shift away from dynamic languages that came at a rather bad time with the schism in Python land. - Non-backwards compatible changes have often gone badly. Perl5 to Perl6. PHP 6. Python 3. I mean gone badly in the sense that it seemed to hurt adoption, at least for awhile. - It seems like statically typed languages have somewhat supplanted some of the use cases for these languages. I'm thinking of Go as one specific example. The way I like to put it is that dynamic languages force you to have unit tests for spelling mistakes and typos. If you compare the Python3 async stuff with Go's I honestly think Go is more elegant here. - Lastly of course there's the GIL. I think this is increasingly becoming a problem in a multi-core/multi-threaded world. The GIL design really does simplify writing C extensions. This makes Python pretty convenient and well-suited for certain tasks. I'm thinking specifically of things using Numpy. Anyway I'm not saying you can't write, say, high-performance Web servers in Python with AsyncIO/gevent loops and the like. It's just not as... elegant and simple as things seemed back in the days when Python 2.7 was state of the art. [1] https://www.python.org/dev/peps/pep-0414/ https://www.python.org/dev/peps/pep-0414/

lima 10y ago

I have extensive experience working with Python 2, 3, asyncio and gevent so I'll comment on some of the points in this article. Python 2: def hello_world(name): print 'Hello', name Python 3: def hello_world(name): print('Hello', name) > The language, which was once simple and elegant, has become complicated and clumsy Python 3 is just as simple to use as Python 2 (simpler, even due to all the cleanup that happened - just think about the encoding mess in Python 2). What happened is that new, powerful features got added to Python 3 that solve specific issues that people were having. It's entirely optional to use these, but they make life much easier if you need them. Async programming is only really applicable to highly concurrent network programming or other applications that spend a lot of time waiting for IO. For everything else it's just unnecessary overhead. It is inherently complicated. In particular, the async/await paradigm is extremely powerful. I first encountered it in C# and immediately fell in love with it, and I'm happy to see major languages like Python and JavaScript adopt it. It makes clear where you hand off control back to the event loop and prevents all sorts of bugs where you'd accidentally block the main thread by invoking blocking IO. gevent, in comparison, is an ugly workaround that hides all of the complexity behind async programming. By monkey patching all IO libraries to be magically async, it makes it impossible to reason about the execution flow and it's extremely easy to get it wrong. That is an affront to the Zen of Python (Explicit is better than implicit). Type annotations are just a standardized way to do what large projects were doing anyway - documenting types. By moving it out of the docstrings and formalizing it, it opens the door to strict type checking. The resulting ugliness reflects the difficulty of typing a dynamic language and you only need it if you want strict type. You can write untyped code just fine. > I'm not even debating the value of type annotations [...] And why do this when there are hundreds of other languages out there that are statically typed? Do I have to point of the irony?

singularity2001 10y ago

I will start liking python 3 once print(str(b'hi')) will print just 'hi' That is: UTF-8 should be the default encoding, at least let me specify it somewhere.