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

921–930 of 993 posts

Re: Python Is Eating the World

#921

Post by tekknik »

acdha wrote: post #902
MiroF wrote: post #809

Earlier quoted context omitted.

it's pretty easy to detect only when you are being piped and then only include malicious code then

Do you believe GitHub has that infrastructure deployed? If not, this is a blind alley to worry about. If so, what other precautions have you taken to avoid compromised tarballs, unauthorized pushes to repos with auto-deployment pipelines, etc.? The point is that in reality you’re orders of magnitude more likely to be compromised by ads in your browser, an undetected flaw in legitimate code, or a compromised maintaine…

So because ads can compromise us we should ignore the security of package managers?

How about this for a reason, where are the checksums when I’m curling and piping? How do I validate in an automated fashion the validity of this file I’m piping into an interpreter? When installing a package it’s quite easy to have redundant copies of an index with checksums pointing to a repository hosting the actual code. The attack surface is much smaller vs a curl | python

This is bad practice, stop promoting it or downplaying it’s security issues.

Edit: smaller instead of larger

Re: Python Is Eating the World

#922

Post by geofft »

marmaduke wrote: post #870
geofft wrote: post #490

Earlier quoted context omitted.

It would change the semantics of the language. You could also write a sys.path hook to interpret the remainder of the file as Ruby and not Python, were pip so inclined.... (Also it's not clear what those changed semantics would be.)

Import system is pluggable, so the semantics are there to be customized. Sure, it could be abused (as many things in Python), but an import hook that checks for a vendored dependency with specific version, seems like a reasonable way to resolve the problem above. > remainder of the file as Ruby and not Python That's a little excessive

But it changes the semantics of the rest of the language, e.g., if two modules interoperate by passing a type of a third module between themselves, and now there are two copies of that third module, they can't communicate any more.

Getting this right and reliable would be a) a considerable language design project in its own right and b) confusing to users of Python as it is documented, and in particular to people testing their modules locally without pip. It wouldn't be as drastically different a language as Ruby, but it would certainly be a different language.

Re: Python Is Eating the World

#923

Post by jacobsenscott »

coldtea wrote: post #663
jacobsenscott wrote: post #584

Earlier quoted context omitted.

> Programming in the large without type safety is a fool’s errand. Lol. Right. 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.

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

C's typing is so week it might as well be an untyped language - not even a dynamically typed langue. And that's what most of the software you run every day runs on.

Static typing was all the rage 20 years ago. C++ and Java were going to save us from the chaos of C. What people found was the vast bulk of software defects are not problems that can be detected by static typing.

Static typing just created a constraining, inflexible code base, that was no more reliable than C or smalltalk or lisp. Once your beautifully conceived collection of types were demolished by the cold hard reality of changing business requirements the type system actively worked against you.

Python and ruby and javascript started gaining traction, and at first it seemed crazy to use a language that didn't have a static type checker. But after people started using them they realized they just didn't have the kinds of bugs that a static type checker would catch anyway - because those types of bugs are caught by the dynamic type checker (something C doesn't have, and C++ only sort of kind of has) at run time when you write tests. And writing tests also caught all kinds of other logic bugs that didn't have anything to do with types. They were writing software faster and more reliably in dynamically typed langues than they ever could in the old statically typed languages.

Of course no language is a silver bullet, and writing software is still hard. Combine that with the fact that our industry has no sense of history, and a fair number of programmers today have only used dynamically typed languages, and you can see why the static typing fad is coming back around.

It seems intuitive that caching these type errors at compile time rather than run time will make for a more reliable system. But history tells us otherwise. Unless you just don't run your code before pushing it to production the dynamic type checker will catch it just as well when you run tests. And your types will drift away from the reality of the business requirements grinding development to a halt.

The static typing fad has a 5 year shelf life. Just enough time for managers to force a new generation of programmers to re-write all their code in typescript or whatever and learn it is just as unreliable, and much harder to work with.

Re: Python Is Eating the World

#924

Post by jpalomaki »

ChrisRackauckas wrote: post #80
blaisio wrote: post #33

Python has a lot of problems that really slow down development, but they are all fixable. The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom. Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell? Why do I need to manually add version numbers to a file? Why isn't there any builtin way…

Python's dependency hell is what made me first look at Julia. I develop on Windows (someone has to :) ), and it was just impossible to get all of the numerical libraries like pydstool, scipy, FEniCS, Daedalus, etc. playing nicely together... so I gave Julia a try. And now the only time I have issues getting a package to run are Julia packages which have a Python dependency. Python is a good language, but having every…

Visual Studio Code brings some tooling to make it easier to work with code running in Docker container.

Re: Python Is Eating the World

#925

Post by grumpyprole »

kbp wrote: post #897
grumpyprole wrote: post #888

Earlier quoted context omitted.

"Dynamic typing" is really just case analysis at runtime. Every static language is capable of dynamic typing, it's not some feature that statically typed languages lack. A dynamic language is really just a static language with one type.

Why aren't statically typed programs really just dynamically typed programs where all the types happen to be statically inferable?

Because most statically typed languages allow us to define our own types, add type signatures to constrain etc. Dependently typed languages also allow types to depend on values. Inference is useful, but only one aspect of static typing.

Re: Python Is Eating the World

#926

Post by tome »

jerf wrote: post #855
6gvONxR4sf7o wrote: post #807

Earlier quoted context omitted.

The effort I'm familiar with is the many attempts to make a decent linear algebra library in haskell. There are a number of libraries with huge work put in, but none has reached blas/lapack parity. Nothing's remotely comparable to numpy in ease of use yet. It picks up more libraries as time goes on, and the existing ones mature, but it's so slow that I'm skeptical they'll ever match numpy's usefulness a decade ago.

I think it's really easy to focus on the big hitters and forget they are the exceptions. Yes, matching lapack, any GUI toolkit, a browser engine, and a handful of other things is a big challenge that takes its own community to overcome, not something any language community can do with an incidental fraction of the community's available firepower. But those are the exceptions, and often you don't need a best-of-breed…

> if Rust's community isn't already several times larger and growing faster, I'd be stunned

I'd love to see the numbers on that if you know where to find them.

Re: Python Is Eating the World

#927

Post by j88439h84 »

trogdc wrote: post #889
curryst wrote: post #877

Earlier quoted context omitted.

I'm not an expert on the internals, but virtualenv interactions feel more seamless. When you run poetry, it activates the virtualenv before it runs whatever you wanted. So `poetry add` (it's version of pip install) doesn't require you to have the virtualenv active. It will activate it, run the install, and update your dependency specifications in pyproject.toml. You can also do `poetry run` and it will activate the v…

Sounds about the same as pipenv's functionality.

Pipenv still needs setup.py and MANIFEST.in. Poetry replaces both.

Re: Python Is Eating the World

#928

Post by reallydontask »

read_if_gay_ wrote: post #919
reallydontask wrote: post #785

Earlier quoted context omitted.

If I mix and match spaces and tabs, Python will not work and you cannot tell them apart ,it's a bit more subttle than this, but you get the idea (should you wish to). There is no such issue with braces. This is what i meant. As for formatting, you can use ide shorcuts to format your pasted code but it will run fine even if not formatted, not the same for Python, where it will not run.

> There is no such issue with braces That is true, but mixing spaces and tabs is a contrived example. Literally nobody actually does that. Same for the point about formatting, I think. The average python dev probably spends about as much time reformatting pasted code as the average C dev spends typing braces. I guess my point is just I think you subjectively dislike Python’s syntax (which is fine) but are trying to m…

> That is true, but mixing spaces and tabs is a contrived example. Literally nobody actually does that.

Contrived or not this has happened to me when copying and pasting, but I take your point that people won't mix and match.

> I guess my point is just I think you subjectively dislike Python’s syntax (which is fine) but are trying to make objective justifications for that which seem really far fetched. Why not just say you don’t like it?

While the issues I encountered might seem contrived and far fetched to you, they have happened to me, granted I don't do Python professionally.

As I said on first comment, I don't like it because of the reasons I mentioned, some are factual,e.g. indentation when copy and pasting can mean that the script/program won't run, some are opinion-based, e.g. they [braces] are easy to visually parse.

Re: Python Is Eating the World

#929

Post by yetanotherjosh »

brainless wrote: post #68

Remember NOT to jump into Python for your new product if don't know Python. If you are developing for a young startup, have time crunch, then stick to what you know. IF you do not have a language, or know Python a bit, then pick Python. Here are some of the reasons why I stick to Python (young startup/web APIs): - OOPs is not too strict (might give a headache to some folks) - Mixins, lambda, decorators, comprehension…

> Remember NOT to jump into Python for your new product if don't know Python. If you are developing for a young startup, have time crunch, then stick to what you know.

Are you saying this as a general maxim (don't try to learn a new tech under pressure) or because of characteristics specific to Python, that make it worse in such a situation than any other language/ecosystem?

Re: Python Is Eating the World

#930

Post by ernst_klim »

verttii wrote: post #886
ernst_klim wrote: post #856

Earlier quoted context omitted.

> A language by itself is probably not even in the top 3 considerations when choosing new tech. Stuff like runtime, ecosystem and the amount of available developers would probably be more important in most cases. Totally depends on a domain. In serious mission critical software you wont use libraries, but will use the language.

Yeah I don't disagree. But even there you would have similar other considerations besides the language. Like most still end up with C/C++ there even though there are others like Crystal, Nim, but you just don't find developers who know them easily, nor do you have any ecosystem support.

> Like most still end up with C/C++ there even though there are others like Crystal, Nim,

Because C++ and C are significantly better than Nim and Crystal.

There are also Ada and Spark and aerospace and very critical stuff.

> just don't find developers who know them easily

We don't look for OCaml/Ada developers, we hire programmers, and they program OCaml and Ada. It's not a big deal for a good programmer to learn a language, especially while programming side by side with seasoned programmers.

Post reply on HN