Live data from Hacker News

Python Is Eating the World

zdnet.com

771–780 of 993 posts

Re: Python Is Eating the World

#771
post #42

Earlier quoted context omitted.

>Most people just cross their fingers and hope dependencies don't change Is there anything wrong with pip freeze > requirements.txt and then pip install -r requirements.txt ? This would install the exact versions

I've had a good experience with pip-tools ( https://github.com/jazzband/pip-tools/ ) which takes a requirements.in with loosely-pinned dependencies and writes your requirements.txt with the exact versions including transitive dependencies.

Same here, in my team we had immediate dependencies defined in setup.cfg when PR was merged, a pip-compile was run and generated requirements.txt and store it in central database (in our case it was consul because that was easiest to get without involving ops).

pip-sync was then called to install it in given environment, any promotion from devint -> qa -> staging -> prod, was just copying the requirements.txt from environment earlier and calling pip-sync.

Re: Python Is Eating the World

#772

And that's a sad thing to hear. Before my death by thousand downvotes, I'd like to tell you why do I feel that way. Back in the day when I was way more inexperienced than I'm now, I was a die-hard Python fanboy. To me, it seemed like a best option available due to it being way more concise and readable than JS/PHP, not to mention that it was way more powerful and dense. I didn't really bother with type safety at the…

> sound and flexible type systems

Python has a more powerful type system than any mainstream language except for C++ (templates). No other mainstream language has support for explicit marking of variance of arguments, nor does any other language support literal (dependent) types, except for typescript.

Re: Python Is Eating the World

#773

Holy Crap! What a lot of irrational, hyperbolic hate for Python. I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the config…

Here's some rational "hate" for Python then. I just returned to Python for the first time in a little while to collaborate on a side project and ran into a few tricky-to-debug errors that caused a fair bit of lost time. Know what the errors were? In one case, I was iterating over the contents of what was supposed to be a list, but in some rare circumstances could instead be a string. Instead of throwing a type error,…

Here is the counter-argument to everybody who thinks there is too much python in the world:

It could be javascript.

Re: Python Is Eating the World

#774

Earlier quoted context omitted.

> No big system has ever been built in an untyped or weakly typed language. Well, except just about every bit of software we all use everyday. But it does seem like some small startups can't get by without it. Many have built models of the Eiffel tower with toothpicks too, so? You can still built things with inadequate tools: inadequate != prohibitive. You just have more problems going forward. Which is exactly the l…

Python is not weakly typed. It is strongly typed in that it forbids operations that are not well-defined. For example, adding a number to a string) rather than silently attempting to make sense of them. I agree wholeheartedly about weakly typed languages, though.

I believe that marketing Python as "strongly typed" has the potential to confuse rather than educate. Python still crashes at runtime with these errors. It has nice error messages, but it still crashes, potentially in production. If you want to create your own "types", you'll have to add your own runtime checks. It's much more sane than JavaScript, but it's not strongly typed like Haskell. Python does not automatically coerce some built-in runtime values, that's it.

Re: Python Is Eating the World

#775

Earlier quoted context omitted.

The bugs you describe should both be easy to catch with unit tests. It sounds like the problem is not that you're using Python, it's that your project lacks tests. Sure, you can typo this sort of thing; but it should be apparent within seconds when your tests go red. (And nowadays, you can also use type hints to give you a warning for this kind of thing, e.g. your IDE/mypy will complain about passing a string where t…

Serious question: If you are writting unit tests to check types, why not just use a language that has a compiler that does that for you? And if you are writing python with type hints, why not just use a language that uses the types you spend time adding to make your program faster. Python is great for sharing ideas / concepts, but under some circumstances it seems irresponsible to choose it over other viable options…

Just because you have a Python function that has strict requirements for input doesn't mean every function you're writing has strict requirements.

Moreover, using a strongly typed language doesn't magically make you invulnerable to invalid input. Unit tests are useful in every language.

Re: Python Is Eating the World

#776

Holy Crap! What a lot of irrational, hyperbolic hate for Python. I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the config…

Why do you think that Python should be compared to Fortran? Why not Rust or Julia? If we compared everything to worse humanity would not progress at all. I have spent 10 years on Python and I sympathize with some of the criticism below here pretty much. I wish Rust or Julia will replace it for data crunching soon.

Re: Python Is Eating the World

#777
post #672

Earlier quoted context omitted.

I think you don't get the point. Most people don't create such interfaces, but the libraries/systems they work with use them a lot, at least in other languages. This is for example the reason why there won't be a large mathy/scientific ecosystem in golang.

Python needs FFI, because its native performance is fairly poor [1]. In general, Go gets away with less FFI because it's fast enough that it doesn't need things to be implemented in C to run quickly. This is especially true if you consider "Go" as "Go + its ASM", which is probably what you'd want if you think of it in terms of science programming. For another example of a similar effect, Rust has great FFI. Yet I wou…

It's not just about speed. Great mature libraries have been written in C over the decades. Rewriting them in a new language is a herculean effort. Writing bindings to them lets you use the fruit of all that labor.

Re: Python Is Eating the World

#778
post #728

Earlier quoted context omitted.

Here's some rational "hate" for Python then. I just returned to Python for the first time in a little while to collaborate on a side project and ran into a few tricky-to-debug errors that caused a fair bit of lost time. Know what the errors were? In one case, I was iterating over the contents of what was supposed to be a list, but in some rare circumstances could instead be a string. Instead of throwing a type error,…

Python is a dynamic language, that's what dynamic languages do, you don't have a type checker but have greater flexibility, but you don't have to settle on that, you can actually use mypy and annotate types and get best out of both worlds. > And another one, I typoed a variable name as groups_keys instead of group_keys (or vice-versa, I don't remember). Instead of just throwing an error, Python happily went along wit…

mypy is a great effort, but very experimental. Try using it on any real-world large enough project and it loses most of its value as there are still a lot of unimplemented things, or because you'll depend on a third party module that hasn't support for it yet.

Re: Python Is Eating the World

#779

Earlier quoted context omitted.

> and multiprocessing is a dead end. Why is multiprocessing a dead end?

Huge overhead for process communication, weird interface, weird semantics, etc.

Is that still true with processpoolexecutor?

The overhead obviously is still there, but the interface is a drop in replacement for threadpoolexecutor, which looks basically just like a multithreaded/async/future-based collect.

Re: Python Is Eating the World

#780
It's easy to get going on it, it's productive for writing scripts and experiments. It's dreadful for programming in the large, but only in comparison to languages designed to take account of the lessons learned about large code bases and team working. Most programmers have never encountered these and have very little idea of what they are missing.
Post reply on HN