5 ms·
I have to write Python for the job right now and this language has pitfalls everywhere. Glad I avoided this language so far. I don't want to use Python for a s
by ezoe 4y ago
I have to write Python for the job right now and this language has pitfalls everywhere. Glad I avoided this language so far.
I don't want to use Python for a software more than a few dozen lines or involving multiple developers. This language was designed to unintentionally shoot your foot so many times.
- praptak 4y agoMy experience with Python is that a mid sized code base does not survive a full staff turnaround. So somewhere around the time the last original author is gone, the codebase becomes a haunted graveyard - scary to everyone. Also, unit tests are not a substitute for static typing - they obviously help a lot but don't prevent the degradation. This is based on 3 different companies, of which all had decent developers who did follow good practices.
- ngc248 4y ago>>> My experience with Python is that a mid sized code base does not survive a full staff turnaround. So somewhere around the time the last original author is gone, the codebase becomes a haunted graveyard - scary to everyone. This is 100% true for medium to large codebases. Also because of the dynamic typing just looking at the codebase, it is very hard to understand the "shape" of variables and data. Of course this is improving now because of the type hints, but still it is comparatively hard.
- raverbashing 4y ago> it is very hard to understand the "shape" of variables and data And is it in, let's say Java, with several inheritance levels and very opaque types? It's one thing I struggle with Sure you know a TypeA has method do_stuff() and returns a TypeB but what actually is happening, beats me. Then you chase down TypeA and find out the actual implementation is spread across TypeA0, TypeBaseA and you can't make sense of anything
- praptak 4y agoYes, the ecosystem encourages complex hierarchies and abuse of "patterns" but at least the standard tooling has no problems with things like "find me all places this method is called from" or "find me all implementations of this method". YMMV, but my experience with plain Java is better than with Python. That was about plain Java. Where it stops working is some "dependency injection" frameworks which jumped the shark and stopped being about dependency injection (cough Guice cough). A fracking argument to a method comes from god-knows-where because The Framework injects it based on a combination of its class and and annotation? Yes, now it is as bad as Python or maybe even worse :)
- formerly_proven 4y agoFinding references isn't really that much harder in Python, it tends to work almost always with e.g. Pycharm and has for a long time. There's of course always the shotgun approach and just searching for the identifier, which turns up all but the most opaque ways to do things (e.g. concatenating a string together, then doing getattr - which you can also do in Java with reflection). Ye olde metaprogramming tricks in Python would often elide inspectors like that of Pycharm, which is why it had e.g. special support for the Django or SQLalchemy ORMs. Personally, I've never been fond of those, and find the Java-zope-style code borderline unreadable (heavy reliance on magic, non-local effects and "oh that setuptools entry over there refers to this class here and that's how we load it" kind of tricks) and stuff like Django is (or was) not much better in some areas. More modern metaprogramming approaches can often be typed in Python, which resolves a lot of the issues with it. All that being said, the by far most common cause of bugs in Python is None in my experience, not any of the shenanigans the language allows you to do. Mid-sized (5k < loc < 100k?) can absolutely survive a complete "hostile takeover" from new developers, with all the same potential (but not mandatory) issues and pitfalls that pretty much any such codebase invites, in particular in dynamically typed languages.
- paulluuk 4y agoThe problem here seems to me that apparently none of the remaining devs know how to use Python, not that Python itself is hard to read. Or that for some reason the original devs had no style conventions or good practices whatsoever, which you really can't blame on the language.
- eega 4y agoTrue, but that’s where type hints come in - this way you get best of both worlds.
- jka 4y agoOh man, I love Python but what you say does sound truthful to me. Do you think that other programming languages are more resilient to this? (I'm trying to figure out whether there are some intrinsics of Python that make it more susceptible, and if so whether that could be mitigated)
- praptak 4y agoI think Go is currently the best replacement for Python. Static type system seems to help a lot, also Go is slightly boring to write. One would say it's a bad thing but all those "if err != nil {" give something pretty valuable - the visibility of all the error-handling execution paths to the reader of the code. Also, being boring to write means you seek ways not to write so much, which is also good :)
- Nextgrid 4y agoCounterpoint: I've been programming in Python in a web development context for almost a decade now and I don't think I've been bitten by any of these ever (at least not strongly enough to remember), and been involved in many large-scale projects with many developers and we had no issues. The "worst" that I can remember was actually a Django quirk - ORM result sets (or QuerySets as they call them) execute their query at object evaluation time rather than at instantiation, so unless you cast your resultset to a list it won't actually talk to the DB just yet. Now attach a GUI debugger such as PyCharm/IntelliJ - it will internally evaluate every expression immediately (to populate its GUI) and cause the behavior to diverge (it will "fix" the code and behave as you'd expect when ran under the debugger). I guess there could be certain contexts (system programming? low-level libraries? etc) where these are going to be an issue but when it comes to web/API or business logic development I haven't encountered these.
- praptak 4y agoI agree in that it's not these quirks that are the problem with Python. My take on Python is that it has poor support for tools that make it easy(-ier) to reason about code that you don't know very well. "Where is this called from?", "Where is x being set/modified/read?" - such questions are hard to answer with a large Python code base and I'm not even talking of code that abuses the dynamic nature of Python.
- franga2000 4y agoAlthough this didn't used to be the case just a few years ago, with modern tools and a well-type-hinted libraries, most of the browsing and refactoring functions I was used to from the Java world are available in Python. But yes, the moment someone tries to be too clever (metaclasses, dynamic *kwargs parsing...), all of that falls apart and you're back to reading the docs.
- gonzo41 4y agoI don't love python, but I generally think if you color between the lines and don't try to be too clever then you'll usually end up fine and not hit any clangers. However, I do think that the pythonic way leads people to write terse clever code that's needlessly more complex.
- xtracto 4y agoI'm in a similar position. I've worked with several languages during my 20+ year career. Now I am in a position where I need to do Python. Fortunately it is just smallish scripts (Data mangling). I've done some Python in the past and every time I approach it I hate it. It hasn't improved a bit since the last time I touched it (back when the 2.4/6 vs 3.?? was in all the rage). At least now the easy_install vs pip contention is dead.
- chaostheory 4y agoEvery language has quirks. We should have a WTF for all the major programming languages instead new users randomly stumbling upon them in the worst possible way.
- bjoli 4y agoI always thought I was dumb. Everyone I know says "python just clicked for me", and I have been writing python on and off since 2003 and I have hated every moment of it. About 75% of the bugs I write seem to be about mutable state, and python has nothing but mutable state. It doesn't even get scoping right.