16 ms·

I’ll just say. Since about 3.6/3.8 the language has been growing huge. Like C++ huge. I liked f-strings. Asyncio has its place but is waaay overused. Typing wa

• Night_Thastus 4y ago
  As someone who mainly sits in the C++ and not the Python space - why? Can't you still use all those old features just as you did before? If you don't like the complexity of newer libraries and features, they're still optional aren't they? Or did something fundamental shift (aside from the obvious P2->P3 switch) that has made existing features harder to use?
  • Galanwe 4y ago
    > If you don't like the complexity of newer libraries and features, they're still optional aren't they? Chances are you're not programming in a vacuum. These features will be used by third party libraries and you will have to read/understand this code. Even in your in house codebase, there will always be co-workers that want to use these features. The optionality of language features is not real. If they exist, they will be used, you will have to understand them, they will leak from other libraries, etc.
    • Night_Thastus 4y ago
      Ideally if it's a library you just need to know how to use it, not how it works internally right? Maybe that's too optimistic, but that's certainly how I use libraries in C++.
      • heavyset_go 4y ago
        You can't always trust your libraries and you might have to fix bugs or dig in the source code to figure out how/why something works.
        • bigyikes 4y ago
          Trusting foundations is the only way anything in computing gets done. If I’m at the point where I’m debugging 3rd party code, a little bit of unfamiliar Python syntax is the least of my problems.
          • Galanwe 4y ago
            > Trusting foundations is the only way anything in computing gets done. Hu, says who? Says the junior developer so as not to get overwhelmed? If you've done any kind of expertise work, digging under third party layers is a very regular exercise.
      • dataflow 4y ago
        That's not even the case in C++ (I find myself having to step through Boost and even the standard library once in a while) but it's about 10x worse in a language that has so little static verification. If you use the library wrong then you find out via a runtime error you'll have to track down. Instead of, say, a type checker complaining about the type mismatch of your template parameter.
  • bsder 4y ago
    > As someone who mainly sits in the C++ and not the Python space - why? For the same reasons that you can't "just" use C++11 and ignore C++20. The ecosystem moves forward, and you can't just sit behind no matter how much you would like to.
  • klyrs 4y ago
    As somebody who's comfortable with Python and C++... ugh. Types are frankly kinda silly. They don't do anything, the language doesn't even ship a blessed typechecker, they don't speed up your code, they don't make it safe, they just add useless notation that some mutually-incompatible third-party tools grok. And the mutually-incompatible thing is what really rubs me wrong. They didn't sit down and define a bombproof type system; they just added an optional notation and let the community figure it out (like packaging). Years later, and the community has not figured it out (like packaging). Compared to C++, where you can do incredible zero-overhead magic with the type system; for example duck-typing, once The Way, is now an absolute nightmare in Python's type system. Python typing is little but baggage and warts unless you've drunk the cool-aid and then you're horrified that people like me haven't. (and, all that said, I'm quite excited about py3.11, it's great on performance and ergonomics)
    • Daishiman 4y ago
      I don't use typing with type checkers; I use it to remind readers of my code what types my functions take whenever that's not immediately obvious. The history of Python means that coders make functions whose return is usually quite clear, but when it's not, I'm really glad I have typing. Also, some libraries like Pydantic make use of types in a very clever and productive way.
      • deleted 4y ago
        [deleted]
    • orf 4y ago
      They are not useless at all. Because they are introspectable new types of extremely ergonomic libraries have sprung up (FastAPI, Pydantic), as well as the developer experience improving.
    • pid-1 4y ago
      Check Pydantic out. Really cool for parts of your code in which runtime type enforcing is important (eg. external interfaces)
  • salmo 4y ago
    It’s not as much my code as reading my dependencies, troubleshooting others’ code, and the ecosystem sprawl. I keep up to date and pick and choose what I want. A lot of these issues just aren’t there in C++, and you probably wouldn’t even try to share a codebase for something with someone who’s not another expert. …and you’re most likely working on something big. The big thing that’s plagued Python since 3.x is the distribution problem. You can’t just hand someone a script and maybe another one to user-install some requirements. You need to BYO Python, dependencies, etc. Things like types, library management, etc. are being handled by external tools. If I want to onboard someone to collaborate with me they really have to have my version of Python (so probably pyenv), Pipenv or Poetry, mypy or whatever, pytest or whatever, black, and have the same config for some of them. The verbosity overhead of Go (or Nim, etc.) is worth the trade off to me for most of my uses of Python. I can just hand someone a binary and the dev just needs the language installed and maybe like goimports. I’ve never been married to one language. I like to use them for their wheelhouse. I’ll still use Python for 1-offs or some things I can ship in a container, etc. that I’m only working by myself or with experienced Python people on. A lot of this is that it’s really turning into more of an Analytics language. The output isn’t expected to be shared and everyone around you is a Python dev. And I’m old. I started when Python was so pretty to my Pascal/C self compared to PERL (shudder). The documentation is still amazing for the language and standard library. (No Google, I want the actual docs.) And you could onboard almost anyone to work on it if they had any programming background because it was such a simple language. The 2->3 shift was really only bad for complex legacy codebases and when you primarily deal with bytes vs Unicode. The latter is really painful anywhere. It didn’t bother me much. I usually just had to fix a few small things or it gave me a good excuse to kill something that should have been retired anyway.
    • nimmer 4y ago
      Verbosity overhead? Nim is very close to Python.
• heavyset_go 4y ago
  I felt the same way years ago, but in my case, that frustration was born out of lack of familiarity. With familiarity, I came to like the changes and directions the language was going. Maybe it's Stockholm syndrome, though. In the end, I'm glad that Python is changing to meet the changing developer zeitgeist, even if I might have to play catch up with new features sometimes. It means Python will stick around and won't be considered "old and outdated" and fall out of use because it failed to keep up with what the developer community wants and expects. It's also the same reason why I'm glad that Go got generics.
  • enragedcacti 4y ago
    For me Python feels like an accelerating train, as long as you are already on and don't get off then its great but it gets harder and harder to catch up for everyone else. I love stuff like 'match', the walrus operator, Typing, etc. but it definitely feels like a lot to grok and it will be increasingly hard for new programmers to read arbitrary python code without grokking all of the new stuff.
    • Daishiman 4y ago
      It's really not a lot to grok, at least by most other language's standards. PHP has a long history of doing things in a "right way" that subscribes to copying whatever one language is doing for 5 years. It first did things the C way, then the Java way, then got inspired by Ruby and Javascript, etc. The features are there, but executed in very awkward ways. Ruby as a language explicitly blesses many ways to do the same thing. Every new release in C# seems to bring in as many features as you'd get in 4 or 5 major Python or Java releases. I look at the Python I wrote 8 years ago and it's _fine_. Even Python 2.6 code written with large frameworks looks similar enough to modern Python. The same can't be said for Javascript, Java (Java's best practices have changed a lot since then), C++, or C#.
      • vertere 4y ago
        > It's really not a lot to grok, at least by most other language's standards. Yes, but people have been attracted to Python largely because it's not like a lot of other languages. It is/was concise, simple, dynamic and fairly easy to learn. I think some of the new features, even if they don't make it a worse language, make it less "Pythonic", and so tend to undermine its comparative advantage. For experienced programmers the new features might not seem complicated, but python is used by a lot of people who are not in that category, including people for whom software development isn't their primary job.
• brightball 4y ago
  Personally I wonder if all this is the reason that it seems like Ruby is having an uptick again. Seems like I hear more and more about people coming back to Ruby.
  • Qem 4y ago
    They did a lot of improvements on recent releases. Now the reference implementation even includes a JIT compiler.
• ajkjk 4y ago
  Counter position: it's totally fine. They haven't added much and almost nothing has changed.
  • darthrupert 4y ago
    Reason? This time of the day? Localized entirely into this thread?
  • zx14 4y ago
    Yep. Glad to see Python evolve, become more expressive and permit stronger static analysis.
  • grumbel 4y ago
    The new type system goes pretty much against the idea of duck typing, I'd consider that a pretty big fundamental change. And it's pretty half baked on top (e.g. `a: int = "foo"` goes through the python interpreter without even a warning). And while there it certainly does provide a lot of benefits, it does make the language look more and more like a huge pile of patchwork and afterthoughts. It neither feels simple nor consistent and the tooling is a mess as well, both overly complex (e.g. half a dozens tools to do basic type checking) and lacking really basic important features (e.g. easy way to compile ship able binaries). Especially after all the pain of the python3 transition, it feels just frustrating how much of a mess it all is. The "only one way to do it" philosophy seems to have been thrown overboard a long while ago.
    • goodoldneon 4y ago
      > The new type system goes pretty much against the idea of duck typing How so? Python’s Protocol and TypedDict have their limitations but are structurally typed. > `a: int = "foo"` goes through the python interpreter without even a warning As long as you’re validating inputs then you don’t need type validation at runtime. Input validation ensures that static types are representative of runtime types
      • grumbel 4y ago
• selcuka 4y ago
  I feel the same, but about more subtle features like the walrus operator, the dictionary merge operator, or proposals that fortunately weren't accepted [1] which I feel do not add much to the language. Type annotations, imho, are actually useful and not really hard to read. [1] https://lwn.net/Articles/888945/ https://lwn.net/Articles/888945/
  • kortex 4y ago
    For me, type annotations has been the single biggest ergonomics improvement to come to python. It's a very simple type system compared to many other languages (definitely simpler than rust, haskell, scala, java, and c++, I find it easier than go's generics but I am not practiced). I don't see how they add complexity to the language. In fact I find it limiting if anything. Walrus is...fine. I don't use it much, but I defo see how it's one more thing. Python's biggest complexity, imho, is its almost unrivaled dynamicism. There's just too many degrees of freedom at times. The import system continues to be a nuclear footgun. I consider myself a python expert with 15 years under my belt and today I was still fighting with imports in a pytest suite. Like wtf.
    • RugnirViking 4y ago
      my main issue with the typing is circular imports, and how ultimately for a lot of configurations the best solution is to just skip the typing that one time. Even "if type_checking:" often simply can't cut it I want to be able to use typing everywhere if I'm going to use it, it really grinds when I have to selectively not use it. That being said, im glad typing is in the language :)
      • selcuka 4y ago
        > my main issue with the typing is circular imports FYI: You can use strings as a workaround, or the from __future__ import annotations trick.
      • kzrdude 4y ago
        The official solution to this is to just use strings. I.e instead of Type, use "Type" where Type can't be in scope because of circularity.
• gonzo41 4y ago
  Python is entering the legacy zone. I feel the same way, there so many features that it's hard to do the right thing easily.
• Thorentis 4y ago
  I tried to use Go, and then realised I had to write my own contains method for slices and realised that the language is half-baked.
  • aunty_helen 4y ago
    Go is for people that want to build that sort of stuff though. It makes it feel like you’re being productive and scratches that itch as an engineer. But then yea, 1 line of python using an inbuilt function solves a 10 line go routine in a hackerrank.
    • vore 4y ago
      I don't think most people who are using Go really want to write their own contains method for slices every time: it seems antithetical to being productive and doing what you actually want to do and it is most definitely a shortcoming of the language. Fortunately with generics people can hopefully need to do that a lot less!
    • tgv 4y ago
      Just in case you forgot: Contains is a (nearly) standard lib function these days. Go did get generics, which are type safe (unlike some other languages I could mention). Before that, you had to write a slightly more clunky function yourself, but it was still a one-liner. Second: it's not a good function to use. Checking if something is present in an array is not something you should do often and thoughtlessly. It has its uses, I agree, but in general a "dict", or if you really need an array, binary search, should be used. Where's the one liner for that in python? O wait, there isn't one. Go does have it, though, since a long time. But it's a good thing we no longer use LoC as a measure.
      • paskozdilar 4y ago
        > Where's the one liner for that in python? O wait, there isn't one. Here it is: >>> import bisect >>> sorted_fruits = ['apple', 'banana', 'orange', 'plum'] >>> bisect.bisect_left(sorted_fruits, 'banana') 1
• nurettin 4y ago
  If it wasn't for the typing module, I would just use the superior alternative which is ruby.
  • sinsterizme 4y ago
    Yep! Ruby’s typing is wayyy more cumbersome than Python’s unfortunately
  • NonNefarious 4y ago
    if it weren't
• zarzavat 4y ago
  Since you mention Go it seems like you’re mostly using Python for webdev. Webdev has always sucked in Python, unless you just want to make a CRUD app in Django. The GIL, the lack of static typing make it painful. Python is also not particularly efficient. These days Python is targeted towards general scripting, data processing, scientific computation, etc. It’s really good as a glue language or for anything involving numpy. I use Python every day but I would not use it to build applications.
  • achillean 4y ago
    Web development in Python is a lot of fun nowadays and has scaled just fine (we serve a few billion requests/ month). FastAPI makes writing APIs easy as well (it powers https://internetdb.shodan.io https://internetdb.shodan.io) and for deployment check out uWSGI or uvicorn.
    • literallyWTF 4y ago
      FastAPI will always be relegated to the backwater of Python frameworks for as long as Tiangolo doesn’t bother allowing the community to improve it.
      • davidatbu 4y ago
        I'm curious, how is FastAPI "relegated to the backwater of Python frameworks" when it is the fastest growing (by popularity) Python web framework[0], and it has the endorsement of the folks behind some of the most used Python frameworks, as well as adoption by everyone ranging from small startups to the largest corporations[1]? [0] https://star-history.com/#tiangolo/fastapi&django/django&pallets/flask&Date https://star-history.com/#tiangolo/fastapi&django/django&pal... [1] https://github.com/tiangolo/fastapi#opinions https://github.com/tiangolo/fastapi#opinions
      • pid-1 4y ago
        My perception is that FastAPI is one of the most celebrated Python libs that gained traction in recent years. Could you please elaborate?
• pjmlp 4y ago
  Python was already huge in the 2.x days. Most people thought otherwise, because they don't bother to read the reference manuals.
  • Daishiman 4y ago
    What modern mainstream language is smaller than Python? Ruby? Javascript? Go is surely smaller but then your library surface area as well as code since increase correspondingly.
    • rtpg 4y ago
      JS's standard library is smaller than Python's for sure. I... want to say Rust's standard library is as well, but the traits that are present tend to have a looooooot of methods (check out all the methods on Result!). Python has a lot of things in the standard library, though I think the tendancy has been to stop adding things (case in point: I believe there is very little argument against putting requests into the standard library. I get why they don't but I disagree with the reasoning)
      • smcl 4y ago
        > though I think the tendancy has been to stop adding things Yep you're right, there's even an official effort to clear some of these out: https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/
    • Semiapies 4y ago
      Lua?
      • Daishiman 4y ago
        Lua's use is probably an order of magnitude less than Python or smaller.
        • Semiapies 4y ago
• jasfi 4y ago
  I go to Nim, although Go has a bigger ecosystem.
• jgb1984 4y ago
  I never understood how people consider go an alternative to python. I tried it myself for a while, and I couldn't stand the verbosity. So much code needed to do simple things, it almost felt like C again. And the error handling... Shudder. I'm very happy python survived the 2-to-3 migration and is now thriving more than ever! Looking forward to the 3.11 speed improvements.
  • enriquto 4y ago
    > And the error handling... Shudder. As an anecdotal data point... I like Python and prefer it to Go for the most part. However, in the case of error handling, Go seems to get it right and Python does it very wrong. Exceptions are extremely confusing, I just can't wrap my head around them. I don't even accept, philosophically speaking, the concept of exception: there are no "exceptions" when running a program, only conditions that you dislike.
    • scaredginger 4y ago
      Strongly disagree with your conclusions. There are definitely arguments against exceptions in cases where you always want to understand and handle failure conditions, but Go has not got it right. The need to manually handle returned errors adds too much noise to the code, and in my subjective opinion, the code looks far cleaner when you skip the error checking. Additionally, if the manual error handling code isn't written, failures will generally be silent. My example of error handling done right would be Rust's `Result<T, E>`. There's the ? operator for syntactic sugar to propagate errors upwards. Otherwise, to skip error handling, you're generally forced to unwrap() the result, which is a noticeable smell, and it will crash your program if the operation failed (as opposed to continuing despite the error). Finally, it maintains the error code advantage of keeping the control flow explicit and visible. We've had decades of erroneous error handling from C codebases to learn from. Frankly, it's insane that we have a modern language that still uses error codes in essentially the same way.
      • grawp 4y ago
        This!
• nxpnsv 4y ago
  But why do you think you HAVE to use every new bell and whistle that comes with a new release? It seems like a stressful way to live
  • shabble 4y ago
    even if I don't, I probably need to be able to understand and recognise them when other people do, in libraries/snippets etc that I depend on. Not specifically a new feature, but I remember wasting a good bit of time when coming across a line that was essentially: return headers.get('x-foo') == settings.FOO_KEY is not None and being extremely confused until discovering it was a use of comparison chaining[1] and was actually doing the right thing. [1] https://docs.python.org/3.10/reference/expressions.html#comparisons https://docs.python.org/3.10/reference/expressions.html#comp...
    • Sohcahtoa82 4y ago
      > return headers.get('x-foo') == settings.FOO_KEY is not None I'm a huge Python fanboy and this line is absolutely awful. Comparison chains are great for stuff like "x < y < z" or "x == y == z", but the operators should never be mixed. "Readability counts" is, IMO, the most important line in the Zen of Python, and that line is unreadable. I imagine it's equivalent to: return headers.get('x-foo') == settings.FOO_KEY and settings.FOO_KEY is not None Which, admittedly, feels like a clumsy line of code, but it's at least readable.
    • nxpnsv 4y ago
      Fair point, but then again, confusing code is everywhere :)
• nyuszika7h 4y ago
  Typing is good, but when you have long function signatures with types and they're not wrapped to one parameter per line, it does become painful to read.
  • kortex 4y ago
    Sounds like you need type aliases, or simpler abstractions.
• rawbot 4y ago
  You can always roll out your favorite Python version and just use that. No need to use the latest unless you have security sensitive requirements.
  • salmo 4y ago
    This is my problem. I’ve gotten to where the extra work to use a language that generates a binary is lower than the distribution problem with Python. I’ve rewritten 3 CLIs because it’s too much of a pain for people to get them set up. I still use it for myself to whip through a CSV, collate data from APIs. Sometimes a tiny API or web app (I really don’t like webdev) where I can deploy a container or pipeline deployment. And I don’t have to use all the new bells and whistles. But so many do. The type hinting system in particular is so much more painful to read (to me) than in a language with actual types.
    • rawbot 4y ago
      You can generate a binary of your script (and all dependencies) with pyinstaller[1], and then your users don't have to worry about anything other than running the binary. > PyInstaller bundles a Python application and all its dependencies into a single package. The user can run the packaged app without installing a Python interpreter or any modules. PyInstaller supports Python 3.7 and newer, and correctly bundles many major Python packages such as numpy, matplotlib, PyQt, wxPython, and others. [1] https://pyinstaller.org/en/stable/ https://pyinstaller.org/en/stable/
      • salmo 4y ago
        Oh that’s cool. I’d tried some of these years ago, but they were painful, didn’t support Python 3.x, etc. I’ll have to check it out.
• gigatexal 4y ago
  Initially I wanted to counter all your points but then I realized if this is how you feel then who am I to say otherwise. Personally I don't find all the feature creep/additional features bad per se but it sure has grown and evolved as a language when I first started getting serious about Python in the early 3.x days. What I did want to mention was the improvements to the errors where you can see exactly what line, function call, etc., is causing the error will be a huge game changer in my opinion for the language and for adoption. It's ergonomic changes like that that make me bullish on the language going forward.
• viraptor 4y ago
  > Asyncio has its place but is waaay overused. I'm not sure I get this. Asyncio is a serious commitment. You don't really want it unless you really want it. And even then in the libraries you may want both the sync and async path. I feel like most asyncio libraries would just not exist without it - so if you're not interested in that area, can't you ignore them?
• softwaredoug 4y ago
  Keep in mind for a long time many people just used 2.7, so they'd never see feature changes. I'd argue that Python has always had a stead drumbeat of features
• tus666 4y ago
  how is asyncio overused? Its barely supported by popular libraries.
• timcavel 4y ago