7 ms·

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

• xscott 7y ago
  Yeah, current versions of Python feel like Guido and the rest changed their minds about what they wanted.
  • BiteCode_dev 7y ago
    Python is a very old language. First version in 1991! 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.
    • xscott 7y ago
      I understand why people are willing to defend it or make apologies for it, but there really are some lessons to be learned from the mistakes it made, and dismissing legitimate criticism just ignores the opportunity.
      • BiteCode_dev 7y ago
        I agree, there is a long list of things I would change in Python. And believe me when I say people involved in the community listen to this very carefully. 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 https://twitter.com/bitecode_dev/status/1188130895653416966).
        • FartyMcFarter 7y ago
          > Because big projects using Python felt let down. 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...
          • goto11 7y ago
            Because big projects often start as small projects?
        • avip 7y ago
          I have a mantra, which this thread engraves so well: People always complain, and developers are the worse If only people cared for fellow human beings, or earth, as much as they care for esoteric Wulrus operations in this or that language.
          • xscott 7y ago
            I suspect it's healthier to judge a few misfeatures in a programming language than to judge all developers, or people as a whole. I'm really very optimistic about the future of humanity, but less so about the future of Python :-)
            • avip 7y ago
              Fair enough. Make it a longbet - python vs. human race, who's going down first.
              • xscott 7y ago
                I bet neither will go down, but the human race will improve! Seriously, things are getting better - it's just that paying attention to what needs fixing is how engineers contribute to the progress.
  • bakery2k 7y ago
    I think Python’s direction changed when Guido moved to Dropbox. Suddenly he was working on a million-line Python codebase, and started working to make the language more suitable for programming in the large.
    • xscott 7y ago
      Yeah, that certainly fits.
• BiteCode_dev 7y ago
  > there should be one-- and preferably only one --obvious way to do it. 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.
  • fxj 7y ago
    The new walrus operator now makes indentation obsolete. You can write averything within one line as an array and it is hard to read. This in combination with syntactic sugar, operator overloading and unicode variables can make the language very hard to read. e.g. # compute pi 1000000 >> ψ( ψ(χ>>op("(x**2+y**2)**0.5<1")@rlµ<<χ)>>Σ*4>> _/_) or this: # 10 fibonacci numbers [x:=[1,1]] + [x := [x[1], sum(x)] for i in range(10)] is valid python code. (for the first see my github jamitzky/iverson). Not that I wouldnt like it, but python3 has changed and the zen of python is not valid for some time now.
    • BiteCode_dev 7y ago
      You could do that with a lambda since Python 2.4. 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] As for the unicode caracters as variables... Remember you could do that in Python 2 ? # -*- coding: rot13 -*- cevag "Relax" But people don't do it. Just like they don't use "import *" everywhere, or monkey patch methods like it's going out of style the way Ruby loved it 15 years ago. 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.
• masklinn 7y ago
  Despite what many apparently think, this line very specifically does not say "there should be one way to do it", it is much more restrictive. 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.
• michaelcampbell 7y ago
  As a relative newcomer to Python (compared to most, but I do use it professionally every working day for a year, and some non-working days for personal stuff), I find this to be the case. At work I have to use Django, and it's almost a chore to find anything explicit or obvious in it. Its level of abstraction is "Too Damn High" as the meme goes, IMO. 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.
  • deleted 7y ago
    [deleted]
  • nickserv 7y ago
    This is the danger with high level frameworks, everything is abstracted away, and with a dynamic language like python the black magic can go very deep. 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...
    • michaelcampbell 7y ago
      Thanks; I've glanced at Flask and it makes a lot more sense to me, but this is a project of immense size and age, and not under my control, so I just have to live with it. Overabstraction for the sake of it seems to be Django's mantra. Then there's Django Rest Framework, and the 3-4 different filtering mechanisms. It's really a nuisance.
• at_a_remove 7y ago
  The many, many ways to print variables inside of a string are testament to that. I remember feeling kind of a chill when the number of methods hit three. Two is an acceptable number of methods if you are transitioning from one form to another as kind of a nod to the growing pains of a language, but at three you have hit some kind of watershed.
  • doteka 7y ago
    There's actually five now! 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.
    • BiteCode_dev 7y ago
      It's a problem, but not a failure in design. The language is old. It started with features from that times and evolved to add more modern ones. Removing the old ones would break the world. Why do you thing you can still use == and declare vars without keywords in JS ? 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.
    • guitarbill 7y ago
      in practice it's 3. and 4. though. we outright ban 2. through a linter. it not only looks ugly, but is inconsistent. e.g. it has the tuple pitfall with a (language?) hack to make it work with one variable. even for logging, it's possible to use the `.format` style - although this isn't default. i've never seen `string.Template` actually used, except for niche use-cases with untrusted input, where a full-blown templating engine was overkill.