Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.
I use Python, but don’t follow its development very closely and had no idea what he was talking about. Here’s a recent summary of the PEP 572 controversy for anyone curious.
Design choices where there are multiple options but none are clearly better than the other is where having a dictator is useful. You can sit around arguing forever whether green or yellow is a better color tone for the room, since it’s entirely subjective.
But even deciding what tie-breaker to use to end the stalemate is itself a never-ending process.
I am not going to appoint a successor. So what are you all going to do?
I suspect this is the correct approach for Guido van Rossum to take. If he appoints a successor and it doesn’t work out folk can blame him for it. If the Python community is going to assume the responsibility formerly held by Guido van Rossum qua BDFL they might as well start right away.
From the outside, the controversy over PEP 572 looks like out of control bike shedding. I’m honestly surprised anybody on either side felt strongly enough that it would get to this point. AFAICT, it’s just syntactic sugar to streamline a few common idioms and avoid a common typo.
Syntax is at the heart of Python’s value proposition, and assignment syntax is pretty core. In most languages I’d agree with you, but this is a language that prides itself on being “executable pseudocode” and is very commonly recommended as a teaching/first language for just that reason.
I realize that, but I just don’t see this new syntax as a big deal at all. It’s not mandatory. Existing code still works exactly like it always has. And the new extension isn’t difficult to understand or explain. There’s value in keeping the language small and simple, but that ship sailed a long time ago with Python.
But, at the same time, it’s just syntactic sugar and really isn’t necessary at all.
I honestly don’t care either way, I’m just surprised it blew up so much.
I’ll second this. Guido’s done fantastic things for Python and if he wants to back off and do something else now, then good for him! I wish him the best of luck in future and hope we’ll still see him around in the community.
Say what you will about the Ruby community, but I’ve never seen them fly into a moral panic over a tiny syntax improvement to an inelegant and semi-common construct.
The person-years and energy spent bikeshedding PEP 572 are just astoundingly silly.
Say what you will about the Ruby community, but I’ve never seen them fly into a moral panic over a tiny syntax improvement to an inelegant and semi-common construct.
Try suggesting someone use “folks” instead of “guys” sometime…
A man/woman (or nerd, I guess) after my own heart! This has been my go-to for a while, until one time I walked into my wife’s work (a local CPA / tax service) and said, “What up, nerds?” It didn’t go over so well and apparently I offended some people – I guess “nerd” isn’t so endearing outside of tech?
Thankfully, I don’t think I learned anything from the encounter.
I generally only use it in a technical setting – so within my CS friend group from college, other programmers at work, etc… whenever it’s clear that yes, I am definitely not trying to insult people because I too am a nerd.
as @lmm notes above, a minimalist, consistent syntax is an important part of python’s value proposition. in ruby’s case, adding syntactic improvements is aligned with their value proposition of expressiveness and “programmer joy”, so it’s far less controversial to do something like this.
Left unsaid is the fact that Python 3 has finally achieved escape velocity and is now the community preferred version of the language instead of Python 2. He can safely leave without jeopardizing the Python 3 project or the language as a whole. I have to imagine his constant pushing of 3 over 2 (and at times having what seemed like the entire community against him) is what lead to burn out, PEP 572 just being the final straw.
This is clearly not what happened. There may be pushback against Python 2 in wider community, but Guido doesn’t interact with that much. On python.org it has been Python 3 for a long time.
I think you’re being overly dismissive. He has been a constant drumbeat to the community for python 3 and for the discontinuation of python 2. I think the community’s perception, had he left earlier, would have been to assume he’d given up.
Consider Python as a means to write good code. Perhaps it may be difficult to decide what “writing good code” means in say a Dropbox environment, verses other environments, and since one has obvious human limits it may be impossible to step back from that.
More to the point with PEP 572, perhaps a threshold issue of how far to take a concept, and the manner of “selling” such to a much broader audience of Python programmers given the pattern suggested. Reminds of those I’ve seen who cross to another discipline, and then return later - they aren’t even aware of the perception changes that others notice, and the nuance others observe in scope of behavior.
To be honest, I’m glad he’s retiring. I feel like he’s been trying to take the language places it really shouldn’t go of late. If he wants a type safe language he should design something new and call it Guidothon :) Let Python do what it does well.
my day job is doing static type inference for python (in friendly competition with mypy), so i can speak to this - no one, from guido downwards, wants to turn python into a “type-safe” language. the PEPs have always been explicit about how type annotations are treated strictly as comments by the language, are not needed, and can be safely ignored if you don’t want to use them; they just provide a clean and natural way to document your types with a consistent standard that third-party tools can use to do static typechecking.
note also that your python code has types; they just aren’t enforced at compile time. consider the following code:
def f(a, b, c):
return b * b - 4 * a * c
def g(x):
return f(x, "hello", "world")
python will run this obligingly enough, only crashing when you call g which in turn calls f which throws an exception because you are trying to perform arithmetic operations on strings. now consider the same code with annotations:
def f(a: float, b: float, c: float) -> float:
return b * b - 4 * a * c
def g(x):
return f(x, "hello", "world")
python will still treat this code identically to the first version; you haven’t lost any of your ability to shoot yourself in the foot. but now you have two additonal things - someone can read the type annotations on f and know what it expects without having to read the actual code, and a static type checker can analyse your code and tell you that you’re calling a function that expects floats with strings before you ever run it.
all that PEP484 added to the language was a standard notation to add these helpful type comments, and some syntactic support from the parser and interpreter to make them a natural looking part of the code.
If Guido was the sort to name something Guidothon, then I strongly suspect he would have done decades ago, and now he’d be retiring because of GEP 527, etc, etc.
As one insignificant user of this language, please stop adding these tiny edge case syntax variations and do something about performance. But I am one small insignificant user …
This is exactly the attitude that leads to maintainers’ burn outs.
Do realize this:
Adding syntax variations is not done at the expense of performance, different volunteers are working on what’s more interesting to them.
Python is not a product, and you’re not a paying customer, you don’t get to say “do this instead of that” because none of the volunteer maintainers owes you to produce a language for you. Just walking by and telling people what to do with their project is at the very least impolite.
If you want something to happen in an open source project, volunteer to do it.
(None of this is aimed at you personally, I don’t know who you are. I’m dissecting an attitude that you’ve voiced, it’s just all too common.)
Python is not a product, and you’re not a paying customer, you don’t get to say “do this instead of that” because none of the volunteer maintainers owes you to produce a language for you. Just walking by and telling people what to do with their project is at the very least impolite.
I agree with the general direction of your post, but Python is a product and it is marketed to people, through the foundation and advocacy. It’s not a commercial product (though, given the widespread industry usage, you could argue it somewhat is). It’s reasonable of users to form expectations.
Where it goes wrong is when individual users claim that this also means that they need to be consulted or their consultation will steer the project to the better. http://www.ftrain.com/wwic.html has an interesting investigation of that.
Where it goes wrong is when users claim that this also means that they need to be consulted or their consultation will steer the project to the better.
Wait, who is the product being built for, if not the user? You can say I am not a significant user, so my opinion is not important, as opposed to say Google which drove Python development for a while before they focused on other things, but as a collective, users’ opinions should matter. Otherwise, it’s just a hobby.
Sorry, I clarified the post: “individual users”. There must be a consultation process and some way of participation. RFCs or PEPs provide that.
Yet, what we regularly see is people claiming how the product would be a better place if we listened to them (that, one person we never met). Or, alternatively, people that just don’t want to accept a loss in a long-running debate.
I don’t know if that helps clarifying, it’s a topic for huge articles.
I often find what people end up focusing on - like this PEP - is bike shedding. It’s what folks can have an opinion on after not enough sleep and a zillion other things to do and not enough in depth knowledge. Heck I could have an opinion on it. As opposed to hard problems like performance where I would not know where to start, much less contribute any code, but which would actually help me and, I suspect, many other folks, who are with some sighing, migrating their code to Julia, or, like me, gnashing their teeth at the ugliness of Cython.
Yeah, it’s that kind of thing. I take a harsh, but well-structured opinion any time and those people are extremely important. What annoys me is people following a tweet-sized mantra to the end, very much showing along the path that they have not looked at what is all involved or who would benefit or not knowing when to let go off a debate.
Adding syntax variations is not done at the expense of performance, different volunteers are working on what’s more interesting to them.
Regrettably, a lot of languages and ecosystems suffer greatly from the incoherence that this sort of permissive attitude creates.
Software is just as much about what gets left out as what gets put in, and just because Jane Smith and John Doe have a pet feature they are excited about doesn’t mean they should automatically be embraced when there are more important things on fire.
the incoherence that this sort of permissive attitude creates
The Haskell community would’ve just thrown PEP 572 behind {-# LANGUAGE Colonoscopy #-} and been done with it.
Sure, this doesn’t get us out of jail free with regard to incoherence, but it kicks down the problem from the language to the projects that choose to opt-in.
I find it hard to see this as a good thing. For me, it mostly highlights why Haskell is a one-implementation language… er, 2 ^ 227 languages, if ghc --supported-extensions | wc -l is to be taken literally. Of course, some of those extensions are much more popular than others, but it really slows down someone trying to learn “real world” Haskell by reading library code.
Of course, some of those extensions are much more popular than others
Yeah, this is a pretty interesting question! I threw some plots together that might help explore it, but it’s not super conclusive. As with most things here, I think a lot of this boils down to personal preference. Have a look:
Yes. Exactly this. One of the things I value about Python is its syntactic clarity. It is the most decidedly un-clever programming language I’ve yet to encounter.
It is that way at the expense of performance, syntactic compactness, and probably some powerful features that could make me levitate and fly through the air unaided if I learned them, but I build infrastructure and day in, day out, Python gets me there secure in the knowledge that I can pick up anyone’s code and at the VERY LEAST understand what the language is doing 99% of the time.
I find that “people working on what interests them” as opposed to taking a systematic survey of what use cases are most needed and prioritizing those is a hard problem in software projects, and I find it curious that people think this is not a problem to be solved for open source projects that are not single writer/single user hobby projects.
Python is interesting because it forms core infrastructure for many companies, so presumably they would be working on issues related to real use cases. Projects like numpy and Cython are examples of how people see an important need (performance) and go outside the official language to get something done.
“If you want something to happen in an open source project, volunteer to do it.” is also one of those hostile attitudes that I find curious. In a company with a paid product of course that attitude won’t fly, but I suspect that if an open source project had that attitude as a default, it would gradually lose users to a more responsive one.
As an example, I want to use this response from a library author as an example of a positive response that I value. This is a library I use often for a hobby. I raised an issue and the author put it in the backlog after understanding the use case. They may not get to it immediately. They may not get to it ever based on prioritization, but they listened and put it on the list.
Oddly enough, I see this kind of decent behavior more in the smaller projects (where I would not expect it) than in the larger ones. I think the larger ones with multiple vendors contributing turn into a “pay to play” situation. I don’t know if this is the ideal of open source, but it is an understandable outcome. I do wish the hostility would decrease though.
Performance has never been a priority for Python and this probably won’t change, because as you said, there are alternatives if you want Python’s syntax with performance. Also its interoperability with C is okeish and that means that the small niche of Python’s users that use it for performance critical operations that are not already supported by Numpy, Numba and so on, will always be free to go that extra mile to optimize their code without much trouble compared to stuff like JNI.
If you want raw performance, stick to C/C++ or Rust.
I also observe the same tendency of smaller projects being more responsive, but I think the issue is scale, not “pay to play”. Big projects get so much more issue reports but their “customer services” are not proportionally large, so I think big projects actually have less resource per issue.
I guess you are saying my grass roots campaign to displace “Should Python have :=” with “gradual typing leading to improved performance” as a higher priority in the Python world is failing here. I guess you are right :)
Yes to all of the above. But not understanding where all the personal hostility is coming from. Apparently having the opinion that “Should := be part of Python” is much less important than “Let’s put our energies towards getting rid of the GIL and creating a kickass implementation that rivals C++” raises hackles. I am amused, entertained but still puzzled at all the energy.
There was annoyance in my tone, and that’s because I’m a Python fan, and listening to people kvetch endlessly about how Python should be something it isn’t gets Ooooold when you’ve been listening to it for year upon year.
I’d argue that in order to achieve perf that rivals C++ Python would need to become something it’s not. I’d argue that if you need C++ perf you should use C++ or better Rust. Python operates at a very high level of abstraction which incurs some performance penalties. Full stop.
One of the fun things about Cython was watching how the C++ code generated approaches “bare metal” as you add more and more type hints. Not clear at all to me why Python can not become something like Typed Racket, or LISP with types (I forget what that is called) that elegantly sheds dynamism and gets closer to the metal the more type information it gets.
Haskell is a high level language that compiles down to very efficient code (barring laziness and thunks and so on).
Yes, I find this defense of the slowness of Python (not just you but by all commentators here) and the articulation that I, as one simple, humble user, should just shut up and go away kind of interesting.
I suspect that it is a biased sample, based on who visits this post after seeing the words “Guido van Rossum”
My hypothesis is that people who want performance are minority among Python users. I contributed to both PyPy and Pyston. Most Python users don’t seem interested about either.
For me that has been the most insightful comment here. I guess the vast majority of users employ it as glue code for fast components, or many other things that don’t need performance. Thanks for working on pypy. Pyston I never checked out.
Not clear at all to me why Python can not become something like Typed Racket, or LISP with types (I forget what that is called) that elegantly sheds dynamism and gets closer to the metal the more type information it gets.
Isn’t that what mypy is attempting to do? I’ve not been following Python for years now, so really have no horse in this race. However, I will say that the number of people, and domains represented in the Python community is staggering. Evolving the language, while keeping everyone happy enough to continue investing in it is a pretty amazing endeavor.
I’ll also point out that Python has a process for suggesting improvements, and many of the core contributors are approachable. You might be better off expressing your (valid as far as I can see) concerns with them, but you might also approach this (if you care deeply about it) by taking on some of the work to improve performance yourself. There’s no better way to convince people that an idea is good, or valid than to show them results.
Ah, I thought maybe MyPy actually could do some transformation of the code, based on it’s understanding, but it appears to describe itself as a “linter on steroids,” implying that it only looks at your code in a separate phase before you run it.
Typed Racket has some ability to optimize code, but it’s not nearly as sophisticated as other statically typed languages.
Be aware that even Typed Racket still has performance and usability issues in certain use cases. The larger your codebase, the large the chance you will run into them. The ultimate viability of gradual typing is still an open question.
In no way did I imply that you should “shut up and go away”.
What I want is for people who make comments about Python’s speed to be aware of the alternatives, understand the trade-offs, and generally be mindful of what they’re asking for.
I may have made some false assumptions in your case, and for that I apologize. I should have known that this community generally attracts people who have more going on than is the norm (and the norm is unthinking end users posting WHY MY CODE SO SLOW?
Hey, no problem! I’m just amused at the whole tone of this set of threads set by the original response (not yours) to my comment, lecturing me on a variety of things. I had no idea that (and can’t fathom why) my brief comment regarding prioritization decisions of a project would be taken so personally and raise so much bile. What I’m saying is also not so controversial - big public projects have a tendency to veer into big arguments over little details while huge gaps in use cases remain. I saw this particular PEP argument as a hilarious illustration of this phenomenon in how Python is being run.
Thinking about this a little more - sometimes, when languages ‘evolve’ I feel like they forget themselves. What makes this language compelling for vast numbers of programmers? What’s the appeal?
In Python’s case, there are several, but two for sure are a super shallow learning curve, and its tendency towards ‘un-clever’ syntax.
I worry that by morphong into something else that’s more to your liking for performance reasons, those first two tenets will get lost in the shuffle, and Python will lose its appeal for the vast majority of us who are just fine with Python’s speed as is.
Yes, though we must also remember that as users of Python, invested in it as a user interface for our code ideas, we are resistant to any change. Languages may lose themselves, but changes are sometimes hugely for the better. And it can be hard to predict.
In Python’s 2.x period, what we now consider key features of the language, like list comprehensions and generator expressions and generators, were “evolved” over a base language that lacked those features altogether, and conservatives in the community were doubtful they’d get much use or have much positive impact on code. Likewise for the class/type system “unification” before that. Python has had a remarkable evolutionary approach over its long 3-decade life, and will continue to do so even post-GvR. That may be his true legacy.
Heh. I think this is an example of the Lobste.rs rating system working as it should :) I posted an immoderate comment borne of an emotional response to a perfectly reasonable reply, and end up with a +1: +4 -2 troll, -1 incorrrect :)
I use Python, but don’t follow its development very closely and had no idea what he was talking about. Here’s a recent summary of the PEP 572 controversy for anyone curious.
Design choices where there are multiple options but none are clearly better than the other is where having a dictator is useful. You can sit around arguing forever whether green or yellow is a better color tone for the room, since it’s entirely subjective.
But even deciding what tie-breaker to use to end the stalemate is itself a never-ending process.
I suspect this is the correct approach for Guido van Rossum to take. If he appoints a successor and it doesn’t work out folk can blame him for it. If the Python community is going to assume the responsibility formerly held by Guido van Rossum qua BDFL they might as well start right away.
From the outside, the controversy over PEP 572 looks like out of control bike shedding. I’m honestly surprised anybody on either side felt strongly enough that it would get to this point. AFAICT, it’s just syntactic sugar to streamline a few common idioms and avoid a common typo.
Syntax is at the heart of Python’s value proposition, and assignment syntax is pretty core. In most languages I’d agree with you, but this is a language that prides itself on being “executable pseudocode” and is very commonly recommended as a teaching/first language for just that reason.
I realize that, but I just don’t see this new syntax as a big deal at all. It’s not mandatory. Existing code still works exactly like it always has. And the new extension isn’t difficult to understand or explain. There’s value in keeping the language small and simple, but that ship sailed a long time ago with Python.
But, at the same time, it’s just syntactic sugar and really isn’t necessary at all.
I honestly don’t care either way, I’m just surprised it blew up so much.
Politics, preferences, and arguments aside, Guido’s work on Python is really appreciated and I hope he’s not leaving with a foul taste in his mouth.
I’ll second this. Guido’s done fantastic things for Python and if he wants to back off and do something else now, then good for him! I wish him the best of luck in future and hope we’ll still see him around in the community.
Say what you will about the Ruby community, but I’ve never seen them fly into a moral panic over a tiny syntax improvement to an inelegant and semi-common construct.
The person-years and energy spent bikeshedding PEP 572 are just astoundingly silly.
Try suggesting someone use “folks” instead of “guys” sometime…
I switched to folks and do you know how satisfying of a word it is to say? “Hey folks? How’s it going folks? Listen up folks!” I love it.
On the other hand the interns weren’t too keen on “kiddos.”
I’ve gotten used to saying “’sup, nerds” or “what are you nerds up to?”
A man/woman (or nerd, I guess) after my own heart! This has been my go-to for a while, until one time I walked into my wife’s work (a local CPA / tax service) and said, “What up, nerds?” It didn’t go over so well and apparently I offended some people – I guess “nerd” isn’t so endearing outside of tech?
Thankfully, I don’t think I learned anything from the encounter.
It’s not endearing within tech to anyone over 40.
I generally only use it in a technical setting – so within my CS friend group from college, other programmers at work, etc… whenever it’s clear that yes, I am definitely not trying to insult people because I too am a nerd.
as @lmm notes above, a minimalist, consistent syntax is an important part of python’s value proposition. in ruby’s case, adding syntactic improvements is aligned with their value proposition of expressiveness and “programmer joy”, so it’s far less controversial to do something like this.
Left unsaid is the fact that Python 3 has finally achieved escape velocity and is now the community preferred version of the language instead of Python 2. He can safely leave without jeopardizing the Python 3 project or the language as a whole. I have to imagine his constant pushing of 3 over 2 (and at times having what seemed like the entire community against him) is what lead to burn out, PEP 572 just being the final straw.
This is clearly not what happened. There may be pushback against Python 2 in wider community, but Guido doesn’t interact with that much. On python.org it has been Python 3 for a long time.
I think you’re being overly dismissive. He has been a constant drumbeat to the community for python 3 and for the discontinuation of python 2. I think the community’s perception, had he left earlier, would have been to assume he’d given up.
Consider Python as a means to write good code. Perhaps it may be difficult to decide what “writing good code” means in say a Dropbox environment, verses other environments, and since one has obvious human limits it may be impossible to step back from that.
More to the point with PEP 572, perhaps a threshold issue of how far to take a concept, and the manner of “selling” such to a much broader audience of Python programmers given the pattern suggested. Reminds of those I’ve seen who cross to another discipline, and then return later - they aren’t even aware of the perception changes that others notice, and the nuance others observe in scope of behavior.
Previous discussion on Lobsters here.
To be honest, I’m glad he’s retiring. I feel like he’s been trying to take the language places it really shouldn’t go of late. If he wants a type safe language he should design something new and call it Guidothon :) Let Python do what it does well.
my day job is doing static type inference for python (in friendly competition with mypy), so i can speak to this - no one, from guido downwards, wants to turn python into a “type-safe” language. the PEPs have always been explicit about how type annotations are treated strictly as comments by the language, are not needed, and can be safely ignored if you don’t want to use them; they just provide a clean and natural way to document your types with a consistent standard that third-party tools can use to do static typechecking.
note also that your python code has types; they just aren’t enforced at compile time. consider the following code:
python will run this obligingly enough, only crashing when you call
gwhich in turn callsfwhich throws an exception because you are trying to perform arithmetic operations on strings. now consider the same code with annotations:python will still treat this code identically to the first version; you haven’t lost any of your ability to shoot yourself in the foot. but now you have two additonal things - someone can read the type annotations on
fand know what it expects without having to read the actual code, and a static type checker can analyse your code and tell you that you’re calling a function that expects floats with strings before you ever run it.all that PEP484 added to the language was a standard notation to add these helpful type comments, and some syntactic support from the parser and interpreter to make them a natural looking part of the code.
If Guido was the sort to name something Guidothon, then I strongly suspect he would have done decades ago, and now he’d be retiring because of GEP 527, etc, etc.
As one insignificant user of this language, please stop adding these tiny edge case syntax variations and do something about performance. But I am one small insignificant user …
This is exactly the attitude that leads to maintainers’ burn outs.
Do realize this:
(None of this is aimed at you personally, I don’t know who you are. I’m dissecting an attitude that you’ve voiced, it’s just all too common.)
I agree with the general direction of your post, but Python is a product and it is marketed to people, through the foundation and advocacy. It’s not a commercial product (though, given the widespread industry usage, you could argue it somewhat is). It’s reasonable of users to form expectations.
Where it goes wrong is when individual users claim that this also means that they need to be consulted or their consultation will steer the project to the better. http://www.ftrain.com/wwic.html has an interesting investigation of that.
Wait, who is the product being built for, if not the user? You can say I am not a significant user, so my opinion is not important, as opposed to say Google which drove Python development for a while before they focused on other things, but as a collective, users’ opinions should matter. Otherwise, it’s just a hobby.
Sorry, I clarified the post: “individual users”. There must be a consultation process and some way of participation. RFCs or PEPs provide that.
Yet, what we regularly see is people claiming how the product would be a better place if we listened to them (that, one person we never met). Or, alternatively, people that just don’t want to accept a loss in a long-running debate.
I don’t know if that helps clarifying, it’s a topic for huge articles.
I often find what people end up focusing on - like this PEP - is bike shedding. It’s what folks can have an opinion on after not enough sleep and a zillion other things to do and not enough in depth knowledge. Heck I could have an opinion on it. As opposed to hard problems like performance where I would not know where to start, much less contribute any code, but which would actually help me and, I suspect, many other folks, who are with some sighing, migrating their code to Julia, or, like me, gnashing their teeth at the ugliness of Cython.
Yeah, it’s that kind of thing. I take a harsh, but well-structured opinion any time and those people are extremely important. What annoys me is people following a tweet-sized mantra to the end, very much showing along the path that they have not looked at what is all involved or who would benefit or not knowing when to let go off a debate.
Regrettably, a lot of languages and ecosystems suffer greatly from the incoherence that this sort of permissive attitude creates.
Software is just as much about what gets left out as what gets put in, and just because Jane Smith and John Doe have a pet feature they are excited about doesn’t mean they should automatically be embraced when there are more important things on fire.
The Haskell community would’ve just thrown PEP 572 behind
{-# LANGUAGE Colonoscopy #-}and been done with it.Sure, this doesn’t get us out of jail free with regard to incoherence, but it kicks down the problem from the language to the projects that choose to opt-in.
I find it hard to see this as a good thing. For me, it mostly highlights why Haskell is a one-implementation language… er, 2 ^ 227 languages, if
ghc --supported-extensions | wc -lis to be taken literally. Of course, some of those extensions are much more popular than others, but it really slows down someone trying to learn “real world” Haskell by reading library code.Yeah, this is a pretty interesting question! I threw some plots together that might help explore it, but it’s not super conclusive. As with most things here, I think a lot of this boils down to personal preference. Have a look:
https://gist.github.com/atondwal/ee869b951b5cf9b6653f7deda0b7dbd8
Yes. Exactly this. One of the things I value about Python is its syntactic clarity. It is the most decidedly un-clever programming language I’ve yet to encounter.
It is that way at the expense of performance, syntactic compactness, and probably some powerful features that could make me levitate and fly through the air unaided if I learned them, but I build infrastructure and day in, day out, Python gets me there secure in the knowledge that I can pick up anyone’s code and at the VERY LEAST understand what the language is doing 99% of the time.
I find that “people working on what interests them” as opposed to taking a systematic survey of what use cases are most needed and prioritizing those is a hard problem in software projects, and I find it curious that people think this is not a problem to be solved for open source projects that are not single writer/single user hobby projects.
Python is interesting because it forms core infrastructure for many companies, so presumably they would be working on issues related to real use cases. Projects like numpy and Cython are examples of how people see an important need (performance) and go outside the official language to get something done.
“If you want something to happen in an open source project, volunteer to do it.” is also one of those hostile attitudes that I find curious. In a company with a paid product of course that attitude won’t fly, but I suspect that if an open source project had that attitude as a default, it would gradually lose users to a more responsive one.
As an example, I want to use this response from a library author as an example of a positive response that I value. This is a library I use often for a hobby. I raised an issue and the author put it in the backlog after understanding the use case. They may not get to it immediately. They may not get to it ever based on prioritization, but they listened and put it on the list.
Oddly enough, I see this kind of decent behavior more in the smaller projects (where I would not expect it) than in the larger ones. I think the larger ones with multiple vendors contributing turn into a “pay to play” situation. I don’t know if this is the ideal of open source, but it is an understandable outcome. I do wish the hostility would decrease though.
Performance has never been a priority for Python and this probably won’t change, because as you said, there are alternatives if you want Python’s syntax with performance. Also its interoperability with C is okeish and that means that the small niche of Python’s users that use it for performance critical operations that are not already supported by Numpy, Numba and so on, will always be free to go that extra mile to optimize their code without much trouble compared to stuff like JNI.
If you want raw performance, stick to C/C++ or Rust.
I also observe the same tendency of smaller projects being more responsive, but I think the issue is scale, not “pay to play”. Big projects get so much more issue reports but their “customer services” are not proportionally large, so I think big projects actually have less resource per issue.
He did say “please”.
There’s a better forum, and approach, to raise this point.
I guess you are saying my grass roots campaign to displace “Should Python have :=” with “gradual typing leading to improved performance” as a higher priority in the Python world is failing here. I guess you are right :)
Have you tried Pypy? Have you tried running your code through Cython?
Have you read any of the zillion and one articles on improving your Python’s performance?
If the answer to any of these is “no” then IMO you lose the right to kvetch about Python’s performance.
And if Python really isn’t performant enough for you, why not use a language that’s closer to the metal like Rust or Go or C/C++?
Yes to all of the above. But not understanding where all the personal hostility is coming from. Apparently having the opinion that “Should := be part of Python” is much less important than “Let’s put our energies towards getting rid of the GIL and creating a kickass implementation that rivals C++” raises hackles. I am amused, entertained but still puzzled at all the energy.
There was annoyance in my tone, and that’s because I’m a Python fan, and listening to people kvetch endlessly about how Python should be something it isn’t gets Ooooold when you’ve been listening to it for year upon year.
I’d argue that in order to achieve perf that rivals C++ Python would need to become something it’s not. I’d argue that if you need C++ perf you should use C++ or better Rust. Python operates at a very high level of abstraction which incurs some performance penalties. Full stop.
This is an interesting, and puzzling, attitude.
One of the fun things about Cython was watching how the C++ code generated approaches “bare metal” as you add more and more type hints. Not clear at all to me why Python can not become something like Typed Racket, or LISP with types (I forget what that is called) that elegantly sheds dynamism and gets closer to the metal the more type information it gets.
Haskell is a high level language that compiles down to very efficient code (barring laziness and thunks and so on).
Yes, I find this defense of the slowness of Python (not just you but by all commentators here) and the articulation that I, as one simple, humble user, should just shut up and go away kind of interesting.
I suspect that it is a biased sample, based on who visits this post after seeing the words “Guido van Rossum”
My hypothesis is that people who want performance are minority among Python users. I contributed to both PyPy and Pyston. Most Python users don’t seem interested about either.
For me that has been the most insightful comment here. I guess the vast majority of users employ it as glue code for fast components, or many other things that don’t need performance. Thanks for working on pypy. Pyston I never checked out.
Isn’t that what mypy is attempting to do? I’ve not been following Python for years now, so really have no horse in this race. However, I will say that the number of people, and domains represented in the Python community is staggering. Evolving the language, while keeping everyone happy enough to continue investing in it is a pretty amazing endeavor.
I’ll also point out that Python has a process for suggesting improvements, and many of the core contributors are approachable. You might be better off expressing your (valid as far as I can see) concerns with them, but you might also approach this (if you care deeply about it) by taking on some of the work to improve performance yourself. There’s no better way to convince people that an idea is good, or valid than to show them results.
Not really. Mypy’s goal is to promote type safety as a way to increase program correctness and reduce complexity in large systems.
It doesn’t benefit performance at all near as I can tell, at least not in its current incarnation.
Cython DOES in fact do this, but the types you hint with there are C types.
Ah, I thought maybe MyPy actually could do some transformation of the code, based on it’s understanding, but it appears to describe itself as a “linter on steroids,” implying that it only looks at your code in a separate phase before you run it.
Typed Racket has some ability to optimize code, but it’s not nearly as sophisticated as other statically typed languages.
Be aware that even Typed Racket still has performance and usability issues in certain use cases. The larger your codebase, the large the chance you will run into them. The ultimate viability of gradual typing is still an open question.
In no way did I imply that you should “shut up and go away”.
What I want is for people who make comments about Python’s speed to be aware of the alternatives, understand the trade-offs, and generally be mindful of what they’re asking for.
I may have made some false assumptions in your case, and for that I apologize. I should have known that this community generally attracts people who have more going on than is the norm (and the norm is unthinking end users posting WHY MY CODE SO SLOW?
Hey, no problem! I’m just amused at the whole tone of this set of threads set by the original response (not yours) to my comment, lecturing me on a variety of things. I had no idea that (and can’t fathom why) my brief comment regarding prioritization decisions of a project would be taken so personally and raise so much bile. What I’m saying is also not so controversial - big public projects have a tendency to veer into big arguments over little details while huge gaps in use cases remain. I saw this particular PEP argument as a hilarious illustration of this phenomenon in how Python is being run.
Thinking about this a little more - sometimes, when languages ‘evolve’ I feel like they forget themselves. What makes this language compelling for vast numbers of programmers? What’s the appeal?
In Python’s case, there are several, but two for sure are a super shallow learning curve, and its tendency towards ‘un-clever’ syntax.
I worry that by morphong into something else that’s more to your liking for performance reasons, those first two tenets will get lost in the shuffle, and Python will lose its appeal for the vast majority of us who are just fine with Python’s speed as is.
Yes, though we must also remember that as users of Python, invested in it as a user interface for our code ideas, we are resistant to any change. Languages may lose themselves, but changes are sometimes hugely for the better. And it can be hard to predict.
In Python’s 2.x period, what we now consider key features of the language, like list comprehensions and generator expressions and generators, were “evolved” over a base language that lacked those features altogether, and conservatives in the community were doubtful they’d get much use or have much positive impact on code. Likewise for the class/type system “unification” before that. Python has had a remarkable evolutionary approach over its long 3-decade life, and will continue to do so even post-GvR. That may be his true legacy.
Heh. I think this is an example of the Lobste.rs rating system working as it should :) I posted an immoderate comment borne of an emotional response to a perfectly reasonable reply, and end up with a +1: +4 -2 troll, -1 incorrrect :)