Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Is Eating the World

zdnet.com

Post reply on HN
Print view View original

751–760 of 993 posts

Re: Python Is Eating the World

#751

Post by srean »

CydeWeys wrote: post #685
Ensorceled wrote: post #436

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,…

Well this is anything but a new complaint. I would assume a user who has worked in Python for some modest amount of time to have made peace with this. One works in Python knowing that this can and will happen (well one does have linter on steroid like mypy now to counter these).

Python code needs more testing, more run time type checking of function arguments than a statically typed language. If that's a deal-breaker then one shouldn't be using Python in the first place. What you gain though is some instant gratification, and the ability to get something off the ground quickly without spending time placating the type checker. Its great where your workflow involves lot of prototyping, exploration of the solution space and interactive use (ML comes to mind, but even there int32 vs int64 can byte, correction, bite). I see it as a trade off -- deferring one kind of work (ensuring type safety) over another. Hopefully that deferral is not forever. I like my type safety but sometimes I want that later.

What I typically do is once I am happy with a module and I do not need the extreme form of dynamism that Python offers (something that's frequently true) I take away that dynamism by compiling those parts with Cython.

Re: Python Is Eating the World

#752

Post by theptip »

CydeWeys wrote: post #685
Ensorceled wrote: post #436

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,…

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 the function signature specified a List.)

Re: Python Is Eating the World

#753

Post by joshuamorton »

CydeWeys wrote: post #701
_coveredInBees wrote: post #695

Earlier quoted context omitted.

Your 2nd error isn't possible in Python, so I'm not sure what you did there. Regarding the first, sure, it is a bug that was annoying to catch. But, having an `Iterable` interface in Python is also really neat and useful if used responsibly. If you're programming regularly in Python, you are accustomed to the tradeoffs that come with a dynamic programming language and no static types, and you can still avoid issues l…

I didn't explain the second one well. Here's some exact code. group_keys = ... if not isinstance(group_keys, list): groups_keys = [ group_keys ] So rather than listifying the non-list variable, it was creating a new variable. The cause of this bug is that Python doesn't distinguish between declaring new variables and overwriting existing ones.

FYI, the google style guide (or maybe the internal only version) suggests to avoid initialize-then-assign in favor of single assignment form:

    unclear_type_thing = ...
    if isinstance(unclear_type_thing, list):
      group_keys = unclear_type_thing
    else:
      group_keys = [unclear_type_thing]
statically avoids this problem. In general, prefer immutable variables where possible. Single-assignment form is nice for a lot of reasons, not the least of which is that it avoids this particular gotcha.

And I should add that the "right" way to do this would be to factor this out to a function:

    group_keys = coerce_to_list(...)
is much clearer than either block, and avoids the possibility of the issue.

Re: Python Is Eating the World

#754

Post by jbverschoor »

majewsky wrote: post #428
mooreds wrote: post #422

Earlier quoted context omitted.

I think ruby is alive and well for a lot of startups. I do think it is being squeezed on three sides though. * From javascript. If you have a app like front end, you are going to use js. Why not have the whole stack be js and have your developers use only one language. * From python for anything web + data science. Again, why not have your whole stack be in one language? * From lack of hype. Rails is still evolving,…

"From JavaScript" also includes another side: When your frontend is in JS, your backend can be a simple REST API. And building a REST API requires much less framework than building a server-side-rendering webapp does, so it's tempting to use Go or Rust or whatever you like.

You’ll need (probably) at least: -Database connection -An ORM -Middleware against attacks / rate limiting -Caching -Jobs / workers -A rendering engine for email and maybe pdf -Some sort of admin/backend -Logging -Validation

I’ve written an API once from scratch. Actually twice. First time in Modena, because it was all the hype, but it was arcane. Then Sinatra, where I ended up creating all of the above. Rails is excellent for APIs.

Rust is nice, but I’m not sure if I’d like it for all of an API. I don’t like go. Crystal seems great, because it’s typed and it’s also super fast.

Re: Python Is Eating the World

#755

Post by kamyarg »

If you hate python, just write whatever your hearts desires. There is no use in saying "oh python does not let me know when a variable I expect to be list is string", well yes, it is a dynamically typed language, please learn the difference between dynamically and statically typed languages before hating on any language. As a bonus, you can check if a value is list or string and throw your own error, python is versatile, although it probably would be an antipattern and you should go back to writing C. If you love the good old days of Fortran, then I am sure many Financial Institutions and Aerospace industry or old school mathematicians would love to have you.

Re: Python Is Eating the World

#756

Post by jbverschoor »

jhbadger wrote: post #634
fellellor wrote: post #507

Earlier quoted context omitted.

I am trying to find a place in the industry - again, starting from RoR. I absolutely love Ruby. And all this talk of "Ruby dying" makes me feel sad. The rational thing to do is to move on, and learn something popular, like node.js but the more I see Ruby in action, I just can't pull myself away from it. I had managed to get a job as a Java developer a long time ago, but at that time all I could do was barely write to…

Ruby's future may actually not be Ruby itself. Probably the major problem with Ruby is its performance, which is slow even compared to other interpreted languages. While I'm not sure it is really production ready yet, Crystal is very interesting -- it's a native compiled statically typed language that nevertheless feels very much like Ruby. Check it out if you haven't.

It’s faster than python. And crystal is often faster than go.

Re: Python Is Eating the World

#757

Post by totalperspectiv »

theptip wrote: post #752
CydeWeys wrote: post #685

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,…

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 like Go (if you use Python because it's easy), or C# (If you use Python because it's a 'safe' enterprise choice). (Ecosystem specific things aside at least)

Re: Python Is Eating the World

#758

Post by totalperspectiv »

batbomb wrote: post #696
CydeWeys wrote: post #685

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,…

okay, so use type annotations and mypy --strict

But at that point why not get something for they time you spend adding types and just use a different language?

Re: Python Is Eating the World

#759

Post by rixed »

klibertp wrote: post #632
rixed wrote: post #586

Earlier quoted context omitted.

Exactly! While tests, on the other hand, totally guarantee correctness. I don't get why people try to use sophisticated types systems to prove software, when writing and maintaining tests is so superior, and funnier too!

Both static type systems and unit testing are just tools which are supposed to help programmers to deliver higher quality software. Both static type systems and unit testing have their disadvantages. For static type systems, you sometimes need to bend backward to make it accept your code and it's not very useful before the code grows large enough. For unit tests, even if you have 100% test coverage, it doesn't mean t…

> For static type systems, you sometimes need to bend backward > to make it accept your code and it's not very useful before > the code grows large enough.

How large need a program to become, before the advantage of being allowed to write fishy code is counter-balanced by the types becoming untractable and the code impossible to refactor in any meaningful way?

This is a serious question. Some years ago, apparently Guido Van Rossum though 200 lines would be already quite an achievement [0]. Based on my own experience, I feel that 99 out of 100 errors thrown at me at compile time are valid and would have caused a crash at runtime (ie. when I do not expect it and have lost all the context of the code change). And I get about 50 such compilation errors in a day of work, so I guess I could write without the compiler safety net for about 10 minutes. That's my limit.

One could object that a 10 minutes program written in python can accomplish much more than a 10 minutes program written in Java. That's much certain! But then we are no longer comparing the merits of compile time vs runtime type checking, but two completely different languages. Of course it is easier to write a powerful/abstract language with runtime type checks, while writing a compiler for a powerful language is much harder. Still, since (and even before) python/perl/php were invented many powerful compiled languages have appeared thanks to PL research, that are almost as expressive as script languages. So it would be unfair to equate runtime type checking with lack of expressive power.

Now of course tests are important too. Compile time type checking does not contradict testing, like you made it sound somewhat in your message. Actually, if anything, it helps to test (because of test case generators based on type knowledge to exercice corner cases).

I'm sorry if all this sounds condescending. I am yet to decide whether I should allow myself to sound condescending as the only benefit of age :) But I'd not want to sound like I'm upset against anyone. Actually, I'm happy people have been using script languages since the 90s, for the same reason I have been happy that many smart people used Windows: my taste for independence gave me by chance a head start that I'm afraid would have been much tougher to get based on my intelligence alone.

And now that static type checking is fashionable again I'm both relieved and worried.

[0]: https://www.artima.com/intv/pyscaleP.html

Re: Python Is Eating the World

#760

Post by joshuamorton »

jldugger wrote: post #726
CydeWeys wrote: post #701

Earlier quoted context omitted.

I didn't explain the second one well. Here's some exact code. group_keys = ... if not isinstance(group_keys, list): groups_keys = [ group_keys ] So rather than listifying the non-list variable, it was creating a new variable. The cause of this bug is that Python doesn't distinguish between declaring new variables and overwriting existing ones.

Well, this should have been caught as an unused assignment in static analysis. A whole ton of languages allow this situation, so I'm not gonna ding Python too hard for that one. However, here's a related but different python gotcha: if foo(a): v = list(bar(a)) for i in v: print i In this example, v is only defined inside the if. Due to python's limited scopes, v is also valid outside the if, but only has an assignmen…

Indeed, as another user mentions, mypy will detect this issue, as will pytype, even without any annotations.
Post reply on HN