Why Python keeps growing, explained • Hacker News Board

Re: Why Python keeps growing, explained

#411

Post by Yoric » Fri, Mar 03, 2023, 11:18 PM UTC

KyeRussell wrote: post #247

Yoric wrote: post #238

Earlier quoted context omitted.

That is true. However, I hope that these C applications are written by people who are really good at C. I know that some of these Python applications are written by people who discovered the language as they deployed into production.

That’s a measure of programming prowess, not the actual security concern at hand. If the masterful C developer still insists on using a language that has so many footguns and a weird culture of developers pretending that they’re more capable than they are, then their C mastery could very well’ve not been worth much against someone throwing something together in Python, which will at the very least immediately bypass…

That's entirely possible.

How could we check?

Re: Why Python keeps growing, explained

#412

Post by Yoric » Fri, Mar 03, 2023, 11:21 PM UTC

stevofolife wrote: post #309

Yoric wrote: post #214

Earlier quoted context omitted.

I fully agree with the description. What worries me, though, is that the features that make Python quite good at prototyping make it rather bad at auditing for safety and security. And we live in a world in which production code is prototyping code, which means that Python code that should have remained a quick experiment – and more often than not, written by people who are not that good at Python or don't care about…

Python code can be production code. There are many people and companies shipping Python production code and generating substantial value.

You are correct, there are absolutely huge companies shipping Python production code and generating substantial value.

Do we agree that this somewhat orthogonal to what I'm writing, though?

Re: Why Python keeps growing, explained

#413

Post by blensor » Fri, Mar 03, 2023, 11:42 PM UTC

influx wrote: post #348

blensor wrote: post #173

Earlier quoted context omitted.

I hate to admit that I very often start the python repl to just do some simple calculations. I always have multiple terminals open so instead of opening a calculator I just use python in one of the terminals.

Have you tried ipython? Python repl on steriods!

from time to time yes. Ideally I would also have a jupyter notebook running at all times, but in the end it mostly comes down to vanilla python because that's installed on everything I am using

Re: Why Python keeps growing, explained

#414

Post by henry700 » Fri, Mar 03, 2023, 11:46 PM UTC

cjalmeida wrote: post #380

brundolf wrote: post #364

Earlier quoted context omitted.

Dependency management/tooling. Python (philosophically) treats the whole system as a dependency by default, in contrast with other modern languages that operate at the project/workspace level. This means it's very hard to isolate separate projects under the same system, or to reproducibly get a project running on a different system (even the same OS, because the system-wide state of one machine vs the next matters so…

No. Virtualenvs, and requirements are a thing in Python for ages. I’ve used tons of languages and while not the best, Python dependency management and project isolation is decent. IMO certainly better than JavaScript.

It's decent if you've been in the loop enough to use it. It's not built-in. It's a good practice, for sure, but it not being built-in at the language level makes it insanely easy for a newcomer to just... Not use virtualenvs at all.

In contrast to Javascript/Node.js/NPM/Yarn/whatever-you-want-to-call-server-js, which maintains a local folder with dependencies for your project, instead of installing everything globally by default.

Heck, a virtual env is literally a bundled python version with the path variables overriden so that the global folder is actually a project folder, basically tricking Python into doing things The Correct Way.

Re: Why Python keeps growing, explained

#415

Post by _aavaa_ » Fri, Mar 03, 2023, 11:53 PM UTC

jononomo wrote: post #399

_aavaa_ wrote: post #393

Earlier quoted context omitted.

2-5x IS a lot. It's the speed difference between the current iPhone 14 and an iPhone XS-iPhone 6. That's 4-8 years of hardware improvements. And the parent was talking about numpy code which is better than stock python, who knows how far back normal python would send you.

I'm in the camp that 2-5x performance improvement is not really worth re-writing Python code in C for.

Guess that'll depend on how much you need the performance and how much code it is.

They're comparing numpy (SIMD plus parallelism) with straightforward C code and getting a 2-5x improvement.

Re: Why Python keeps growing, explained

#416

Post by Daishiman » Sat, Mar 04, 2023, 12:13 AM UTC

cornholio wrote: post #350

dkarl wrote: post #270

Earlier quoted context omitted.

I sometimes think about what Python would be like if it were written today, with the hindsight of the last thirty years. Immutability would be the default, but mutability would be allowed, marked in some concise way so that it was easy to calculate things using imperative-style loops. Pervasive use of immutable instances would make it impossible for libraries to rely on mutating objects a la SQLAlchemy. The language…

Exception error handling - and their extensive use in the standard library -is the fundamental design mistake that prevented Python becoming a substantial programing language. Coupled with the dynamic typing and mutability by default, it guarantees Python programs won't scale, relegating the language to the role of a scratchpad for rough drafts and one off scripts, a toy beginner's language.

I have no idea why you say that it's a scratchpad or a toy language consdering that far more production lines of code are getting written in Python nowadays than practically any other language with the possible exception of Java.

Re: Why Python keeps growing, explained

#417

Post by noirscape » Sat, Mar 04, 2023, 12:40 AM UTC

henry700 wrote: post #414

cjalmeida wrote: post #380

Earlier quoted context omitted.

No. Virtualenvs, and requirements are a thing in Python for ages. I’ve used tons of languages and while not the best, Python dependency management and project isolation is decent. IMO certainly better than JavaScript.

It's decent if you've been in the loop enough to use it. It's not built-in. It's a good practice, for sure, but it not being built-in at the language level makes it insanely easy for a newcomer to just... Not use virtualenvs at all. In contrast to Javascript/Node.js/NPM/Yarn/whatever-you-want-to-call-server-js, which maintains a local folder with dependencies for your project, instead of installing everything globall…

Virtualenvs are a part of the standard library since v3.3[0] and most READMEs do reference them btw.

[0]: https://docs.python.org/3/library/venv.html

Re: Why Python keeps growing, explained

#418

Post by noirscape » Sat, Mar 04, 2023, 12:41 AM UTC

dkarl wrote: post #270

Yoric wrote: post #214

Earlier quoted context omitted.

I fully agree with the description. What worries me, though, is that the features that make Python quite good at prototyping make it rather bad at auditing for safety and security. And we live in a world in which production code is prototyping code, which means that Python code that should have remained a quick experiment – and more often than not, written by people who are not that good at Python or don't care about…

I sometimes think about what Python would be like if it were written today, with the hindsight of the last thirty years. Immutability would be the default, but mutability would be allowed, marked in some concise way so that it was easy to calculate things using imperative-style loops. Pervasive use of immutable instances would make it impossible for libraries to rely on mutating objects a la SQLAlchemy. The language…

This is pretty much what nim is btw. Very fun language in my experience.

Re: Why Python keeps growing, explained

#419

Post by sqlserver2008 » Sat, Mar 04, 2023, 12:44 AM UTC

mixmastamyk wrote: post #326

JohnFen wrote: post #324

Earlier quoted context omitted.

We disagree about whitespace blocks. That's fair. > If you’re having trouble with them, use a programmers editor with indentation guides like notepad++ or geany. Yes, of course. Python makes that pretty much essential, which is one of my complaints about Python. A language that requires a special editor is a language that is deficient, IMO. There are a ton of other, more minor, aspects of Python that makes it unpleas…

It’s not required to use a basic editor from the early 90s, no… but it can help on a big codebase. Why handicap yourself? I make patches once in a while with nano/micro without issue. Maybe your functions are just too long, dunno. A lot of folks can’t survive today without a giant ide awhile you advocate not to use something downright tiny in comparison. Do you hate working with jpeg or blender files because they req…

>Two ways to delimit blocks is redundant.

It isn't redundant though because without delimiting symbols for a code block you lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point:

    def example():
        x = 5
    print("Hello world")

What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline before it. The point is you (and any formatting tool) can't know what the horizontal alignment of this code should be just by examining the vertical line order. You can only determine this by knowing (or reanalyzing) the semantics of the code. During a refactor where you're moving around lots of code, this can be a significant PITA. However, in the JS example,

    function example() {
        let x = 5
    console.log("Hello world")
    }

it's unambiguous what the mistake is because you can determine the correct formatting entirely from the line order, without having to know anything about the code's semantics.

Re: Why Python keeps growing, explained

#420

Post by slt2021 » Sat, Mar 04, 2023, 2:55 AM UTC

_aavaa_ wrote: post #415

jononomo wrote: post #399

Earlier quoted context omitted.

I'm in the camp that 2-5x performance improvement is not really worth re-writing Python code in C for.

Guess that'll depend on how much you need the performance and how much code it is. They're comparing numpy (SIMD plus parallelism) with straightforward C code and getting a 2-5x improvement.

I highly doubt that numpy can ever be a bottleneck. In typical python app - there are other things like I/O that consume resources and become bottleneck, before you run into numpy limits and justify rewrite in C.