in the zen of python (import this) it says:
there should be one-- and preferably only one --obvious way to do it.
sadly this is not true for a while in python now. Python became a language that can be really hard to read now.
there should be one-- and preferably only one --obvious way to do it.
sadly this is not true for a while in python now. Python became a language that can be really hard to read now.
It feels like saving boilerplate for the sake of it which just makes obvious, readable code into magic incantations where shit happens and you don't know why or how or where to look.
If you've ever taken a look at something like Flask or Cherrypi, the difference is very apparent.
That said, I've been doing some Rails lately, after years of Django, and I'm finding the experience to be worse from a readability point of view. Metaprogramming everywhere, modifications of language constructs ... It gets very confusing very quickly. Could be simply a lack of experience of course.
In parallel, I've also been using Go and the experience could not be any different. So much easier to understand what is going on, but so much boilerplate code!
It doesn't look like it's possible to have both ease of use and explicitness...
It's really a nuisance.
Yes, this has been one of the hardest balance to find. And believe me when I tell you the community tries very, very hard. But it's a difficult problem: making the language evolves fast enough, but keeping it solid and stable. Very difficult indeed.
> Python became a language that can be really hard to read now.
Not in my experience.
My job involve going a lot from company to company. I see a lot of code, from a lot of different people.
The way people write Python hasn't change much during the last 15 years.
In fact, I'd say because of Python 3, there is less cruft all in all.
You do have a few heavy stuff. E.G: asyncio or the type hints. But how many code out there uses that ? Very little. Mostly, the code that needs it.
Which is good. This is what we want.
e.g.
# compute pi
1000000 >> ψ( ψ(χ>>op("(x**2+y**2)**0.5<1")@rlµ<<χ)>>Σ*4>> _/_)
# 10 fibonacci numbers
[x:=[1,1]] + [x := [x[1], sum(x)] for i in range(10)]
E.G, calculating primes:
>>> print(list(filter(None,map(lambda y:y*__import__('functools').reduce(lambda x,y:x*y!=0, map(lambda x,y=y:y%x,range(2,int(pow(y,0.5)+1))),1),range(2,1000)))))
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541, 547, 557, 563, 569, 571, 577, 587, 593, 599, 601, 607, 613, 617, 619, 631, 641, 643, 647, 653, 659, 661, 673, 677, 683, 691, 701, 709, 719, 727, 733, 739, 743, 751, 757, 761, 769, 773, 787, 797, 809, 811, 821, 823, 827, 829, 839, 853, 857, 859, 863, 877, 881, 883, 887, 907, 911, 919, 929, 937, 941, 947, 953, 967, 971, 977, 983, 991, 997]
# -*- coding: rot13 -*-
cevag "Relax"
Because such capabilities are restricted (one line lambda, parenthesis for walrus, not all unicode is allowed as var names or everywhere...), introduced slowly, and the community culture is to value readability, Python stays Python.
I was against the walrus personally, for the reasons you mention. But while I do see Raymond Hettinger trolling twitter regularly with his latest crazy walrus magic, in production we see no such thing.
Not to say it never happens. It does, I've seen monstrosities in the field. Like with every tech. I mean, you can start a fire with a water hose if you try hard enough.
But it's rare.
Tried to run this in a REPL and got invalid syntax.
let x = <val> in <expr>
(lambda x: <expr>)(<val>)
or this:
[<expr> for x in (<val>,)][0]
(yeah, i've used the second one in a repl, don't @ me)
This is no surprise Guido evolved with it, and changed his mind about a few things.
People are never happy. On the other side of the fence, you have others crying the language is not moving fast enough.
This is why we had Python 3 in the first place. Because text handling was such a cause of pain.
This is why we have type hints in the first place. Because big projects using Python felt let down.
And Python 3 and type hints are also a huge source of criticism (I was the first one to do so).
It's never ending. People will complain. People will be unhappy. Things, also, will be imperfect, as we are limited in resources and are submitted to many constraints. Not to mention taste and opinion, that are used to request changes.
But I'm not answering to dismiss valid concerns. I'm answering because as a very experienced Python dev, I now have a good grasp of what is due to culture, lack of experience, or a real deal.
E.G:
- := forcing parenthesis. Has not been a real problem in my experience, at least as of today.
- Packaging still more complicated that necessary. A real problem in the field (although 50% of it is a teaching problem: https://twitter.com/bitecode_dev/status/1188130895653416966).
Why big projects started using Python in the first place is a very good question, given that this language had not been designed for them...
If only people cared for fellow human beings, or earth, as much as they care for esoteric Wulrus operations in this or that language.
And as far as I'm concerned, the walrus operator breaks it in no way whatsoever: an assignment statement is the one obvious way to perform an assignment, and it's a syntax error to use a walrus as an assignment statement.
1. manual string concatenation 2. the old, printf-style. Still heavily used in e.g. stdlib logging module. 3. .format() 4. f-strings 5. string.Template in the stdlib
Yup, I definitely see this as one of the bigger failures in Python's design.
Even in the p3 transition, the community screamed to not remove them. Did you know we removed % for a few versiond ? We had to put it back because of all the complaints.