-
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 -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.-
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:
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.
-
-
-
-
-
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”
-
-
-
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.
-
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.
-
-
-
-
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.
-
-
-
-
-
-
-
-
-
-
I support workers of Google to unionize. Naver, the #1 tech company in South Korea, recently unionized.
-
-
-
They would definitely benefit from a union.
But they have stronger challenges in this process then most other employees around the west.
First the individualistic culture/propaganda they have been fed for years could prevent them from trading the promise of individual benefits for the reality of shared ones.
But most relevant is the distribution of the company around the world. There are different legal and economical environments out there and it’s likely that several different unions will compete for Google employees, each focused on the local issues and interests people see most.
OTOH Google guys are pretty smart, they could learn how to think globally and how to balance long term benefits with short term local ones more easily than other workers.
-
First the individualistic culture/propaganda they have been fed for years could prevent them from trading the promise of individual benefits for the reality of shared ones.
I would say this is widespread in the tech community. This is not just Google or the USA. The same situation is very common here in Europe. That’s why ideologies like libertarianism or identity politics are more easily spread in the tech community.
That said, I believe people like the Tech Worker Alliance are getting it right in the way they communicate: they disguise the unionist message as something else, avoiding “problematic words” and basically working around the prejudice of the average programmer. I believe this is the key for a new unionist movement around the West, because the old one cannot be revived and it’s tainted by its own problems and by years of anti-unionism.
-
First the individualistic culture/propaganda they have been fed for years could prevent them from trading the promise of individual benefits for the reality of shared ones.
The xkcd “sheeple” comic was given to the contrarian in this thread, but it applies to this too. Your hubris is just less overt and more civilized, but almost as off-putting from my perspective.
-
Your hubris…
Can you please elaborate?
I just noticed two issues that a union in Google would face: a cultural bias and the legislative/economic complexity due to the multinational nature of the company.
The cultural bias against the unions is well known in the USA, mainly because of the country narrative is based on the competition and on the solo hero/entrepreneur. In other states the country narrative value cooperation a lot more, for example in families (that are large group of people), in tribes, in church and so on…
This is an historical and sociological observation that could be false, but doesn’t look like hubris.The multinational observation is also self evident: in different states around the world, laws are different, cultures are different, economical issues are different and so on… the tendency to only focus in the local space could be exploited by the ownership of the company to divide and conquer the employees.
Finally, while I do not like the Google’s corporate culture that I’ve found among engineers, I acknowledge they hire very smart people and what happened with Project Maven show how much they care about their work.
So I think they have an unique chance to overcome these difficulties.
The fact is that in a company that has built an internal narrative based on knowledge and intelligence, now face the fact that the employees hold collectively more knowledge and intelligence than the ownership by several orders of magnitude.
If knowledge is power, in Google, the employees are more powerful than the ownership.
They still call the ownership as “leadership”, but they will soon realize they are the true leaders there.
-
Your hubris is in the implication that individualism is not a reasonable stance to hold. Why would anyone knowingly choose “promises” over reality?
I’m not interested in having a long drawn conversation with you on this topic. I’m just saying, as someone who disagrees with you, your comment is deserving of the “sheeple” xkcd. You might want to reconsider your approach.
-
-
-
-
-
-
The market and good software are antagonist? Nothing new under the sun.
This article, compared to other on the same subject, seems unnecessarily neutral. You want him to give you a moral suggestion until the end but the moral question is left open.
Shall we comply to this state of things or, as developers, shall we fight against the market pressure to preserve our dignity as humans, workers and software engineers? Well…
-
I don’t think the analogy holds. Most of the reason things end up getting off-track or getting out of hand are because the problem statement evolves and/or multiple people are working on the same codebase simultaneously. Cooking is a much better analogy for software, especially if the eater keeps changing their mind about what they want to eat. We all know what happens when there are too many cooks…
-
That’s indeed another very good analogy.
Anyway no analogy holds because programming is programming and by definition, analogies are just approximations. It’s just a way to capture parts of the reality we live everyday and the gardener, as much as the cook, cannot possibly capture all of it. Probably the cook for you works so much better because it looks more like your reality.
-
I think the analogy’s just slightly off target. The part that’s organic and alive and unpredictable isn’t the code that we directly build, it’s what the users do with it. We build structures, add fertilizer, and try to guide the plants into particular forms or directions.
Sometimes you spend a lot of time on some part of a project that people never end up using - nothing’s growing in that part of the garden. So you have to figure out whether that spot needs more light, or it’s too dry, or it’s too wet. Sometimes some part of an application that you threw together as an afterthought gets tons of use - wonderful, let’s expand that part of the garden and see what else we can get to grow there.
Maybe there’s some crappy part of your codebase that lots of people nonetheless depend on - this is like an old stone arch that’s crumbling, but has well-established vines growing up it. Now you have to decide whether to reinforce the arch and leave the vines alone, or build a better one and try to retrain the vines to grow on the new one.
-
-
I agree. AI shouldn’t even belong to an environment full of tech-savvy people.
-
It’s the pretty normal term used by researchers. I mean it’s not ideal, but we need some umbrella name. It’s especially useful to have an umbrella term for people who work on applications, where machine learning is usually just one of several tools in the toolbox. If you want to make a robot behave in certain ways, for example, you can use tools from many different subareas of AI: automated planning, reinforcement learning, “deep” reinforcement learning, classical estimation techniques like SLAM and Kalman filtering, subsumption architectures, reactive planners, etc., etc. Some of these techniques are “machine learning”, some are “deep learning” and some aren’t either, but they mostly fall within AI. You even see that on toy problems: AlphaGo used two AI techniques (deep RL and MCTS), only one of which is a machine-learning technique.
That said, I do kind of prefer the term my own degree has on it, “intelligent systems”. That name is supposed to deemphasize the philosophical and sci-fi angle and emphasize the systems-engineering aspect. Other places have experimented with other names. Oxford recently floated “autonomous intelligent machines and systems” (a name that sounds like it was written by a committee) or “autonomous intelligent systems” for short. We’ll see if any of these catch on…
-
-
Small geohash library for scala. There are a few options but all are ugly. I want to do something nicely packaged, maybe with some indexing included.
-
I’m studying deep reinforcement learning and playing around with rl4j. I’m also considering to start a text plotting library for python because there are only a few clusmy wrappers for gnuplotlib and none of them works decently. I need this for another project that it’s currently stuck because of this.
Teraki, Berlin, Python Senior Developer (possibly with Data Engineering e Machine Learning experience). We develop a ML-based compression solution for embedded systems on cars (and in the future for any kind of IoT device).
https://stackoverflow.com/jobs/191790/senior-backend-developer-teraki