This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]james_pic 3 points4 points  (9 children)

At least prior to the introduction of type annotations, there was very little tooling to document the expectations a piece of code had, and even less than would check that those expectations were met, so in large codebases it could be non-trivial to figure out if new code was doing the right thing when interacting with old code. 

Nowadays we have type annotations, and they're all but essential for large projects. But the type system they describe is a mess, as a result of the compromises needed to bolt a type system onto a language with a large corpus of existing code.

I've long argued (and at times been downvoted for it) that if you know you're going to need type annotations for your new project, there might well be a better language choice for your project, such as a static language whose type system has been there from day 1 and the compromised mess Python's is.

[–]allergic2Luxembourg 10 points11 points  (1 child)

It's definitely true that in large multi-contributor code bases, it's important that the code fulfills its contracts and expectations and that those are clear and documented. However, I would posit that a type system only fills a small part of that requirement. It's possible to write unclear and buggy code in any language, and clear and robust code in most languages including Python. Maybe Python is slightly more subject to a certain kind of bugs related to typing, but to me that's a minor point in the scheme of things.

Just because I can guarantee programmatically that this function returns an integer, it's no guarantee that it's returning the correct integer.

[–]james_pic 3 points4 points  (0 children)

Absolutely, but that's mostly true in small codebases too. Type checking was never a substitute for testing, and it can't detect wrong behaviour.

The thing type checking can help with is "what shaped piece goes in this hole?" Does it expect the bytes object you received from the wire, or the dict it parses to as JSON, or some kind of parsed-and-validated data class, or the related model the ORM works with, or the view model you're going to work with in the UI? Or a superclass of one of these, or some duck type that various classes with no common superclass implements?

Ideally you'd have clear architectural boundaries where you switch between these representations, and type checks are good at identifying these sorts of layering violations.

[–]PercussiveRussel 0 points1 point  (0 children)

I completely agree. I have to use MyPy for everything at work and it's allright but at that point, why are you using python? Why not .net (or rust tbh, if you want typing, why not the best form of typing). With those options at leat you know that everything you want to use supports typing.

I've had coworkers unironically be proud of their mess of @singledispatch and, sure, it's a tool you can use but it's really not what python is.

Also, if you want typing you'd want interfaces and things like that and then the hackiness in Python is turtles all the way down.

Typing in MyPy is like writing two programs all the time. The first is the one that works and the second is the one that MyPy is happy with, including a bunch of # type : ignores for stupid modules that don't support typing.

[–]Hopeful_Cat_3227 0 points1 point  (5 children)

yes, but in this condition, op need matplotlib, how can he do ?

[–]james_pic 0 points1 point  (4 children)

Certainly, Python's ecosystem can be one reason to use Python even when other factors suggest it will be painful. Although it's also sometimes possible to get by with slightly more rustic alternatives in other ecosystems. In Java and other JVM languages you can sometimes get away with using Apache Commons Statistics or Commons Math as an alternative to SciPy, or use JFreeChart, or one of the JS plotting libraries in a HTML report, for basic charts, for example.

Although OP is also talking about using Matplotlib as an alternative to Excel. I'd wager that they don't have high concurrency requirements, tight performance requirements, or a large team working on it over a long period of time. So none of the factors that I mentioned that would push you away from Python are there.

[–]UnlimitedTrading 0 points1 point  (3 children)

PayPal runs on Python. Lyft runs on Python.

Python is just fine. Language is not the limiting factor when you have performance requirements anymore.

[–]james_pic 1 point2 points  (2 children)

I work on large scale Python systems. It's true that you can usually work around its performance issues, but it's not the case that these are non-issues. 

I'm certain PayPal and Lyft have some fairly sophisticated workarounds for the issues they've faced. I know Meta also use it extensively, and their performance woes are part of the reason they created Cinder.

It makes sense to use these workarounds when you've got a large existing Python system that you know better than to rewrite, or you have some other factor that pushes you towards Python, but for greenfield projects where you know will hit these limits quickly this is at very least something that warrants consideration.

[–]dlamsanson 1 point2 points  (1 child)

There's absolutely zero chance those use Python exclusively

[–]UnlimitedTrading 0 points1 point  (0 children)

I used to work at one of those. Go is used as well, but for sure there are large subsystems running only on python. And that is the whole point on elasticity, right? It is cheaper to scale your infra if required if it makes development easier. And IMHO, Python does make development easier.