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

“Python's batteries are leaking”

pyfound.blogspot.com

Post reply on HN
Print view View original

361–370 of 420 posts

Re: “Python's batteries are leaking”

#361

Post by sametmax »

SlowRobotAhead wrote: post #343
sametmax wrote: post #282

Hawk Owl is a _fantastic_ dev. She was the main force behind the twisted 2->3 transition. But because she is, she is missing the point of batteries included. Asyncio is in the stdlib so that we have an official lib and API. The main benefit is that most people now, when looking for async, are not wondering about twisted or gevent or tornado. Most just go asyncio. Most dev efforts go to asyncio. It's the end of the gr…

>She was the main force behind the twisted 2->3 transition. Explain? I’ve hated the slow adoption of 3.x from 2.x, and generally how terrible it is to have apps that are 2.x on your 3.x system, and would like to know more about how that happened.

Twisted is a lib, she happened to have contributed a lot to the migration effort for it.

Re: “Python's batteries are leaking”

#362

Post by tjalfi »

hn_throwaway_99 wrote: post #211
bsder wrote: post #207

Earlier quoted context omitted.

Python cannot be atomized effectively, and the issue is political. The problem is that I cannot count on being able to install new software in many environments. If I fight the battle to get centralized IT to install Python, I now have a guaranteed set of standard libraries as well. I'm never going to get permission to install anything other than default. Ever. Consequently, the standard libraries need to be very com…

> If I fight the battle to get centralized IT to install Python, I now have a guaranteed set of standard libraries as well. I'm never going to get permission to install anything other than default. Ever. Can you explain this more? What kind of place do you work? I've had some experience with large, bureaucratic companies, but nothing ever so far as "you can't install any other libraries."

Last June I opened a ticket for our procurement department to have an open source license reviewed. It is still open. Our purchasing process is similar to [0].

[0] https://training.kalzumeus.com/newsletters/archive/enterpris...

Re: “Python's batteries are leaking”

#363

Post by DougBTX »

icxa wrote: post #339
rbanffy wrote: post #336

Earlier quoted context omitted.

This approach is useful for a while, but once something is in a stdlib, its interface is frozen forever.

(I am trying to tie the two concepts together from your reply, so I am not saying this to come off as combative but understand your objection) - What would you define as a while? I think Go has done well with it, given that it is almost 10 years old now at this point, and in reality, was in development internally at Google years before that. - Do you feel like an interface being frozen forever is particularly a bad t…

The way to answer your two questions is to combine them, the definition of “a while” depends on how good a job the interface does. If the interface is really good, then it can last a really long time (perhaps as long as the language lasts).

I read some discussion the other day about some ways in which the Any type in Rust isn’t as flexible as it could be, since it is frozen the only way to improve it would be to introduce a new name, such as Unknown. Similarly in C# along with adding async support, the standard library added async versions of many methods, eg Read now also has a ReadAsync partner.

It does seem that having multiple names for basically the same thing adds a small but tolerable level of overhead to a language. At least if as much as possible is moved out, then projects can choose to only use the latest versions, and live in a world as if past versions never existed.

Re: “Python's batteries are leaking”

#364

Post by civility »

scottLobster wrote: post #345
hn_throwaway_99 wrote: post #211

Earlier quoted context omitted.

> If I fight the battle to get centralized IT to install Python, I now have a guaranteed set of standard libraries as well. I'm never going to get permission to install anything other than default. Ever. Can you explain this more? What kind of place do you work? I've had some experience with large, bureaucratic companies, but nothing ever so far as "you can't install any other libraries."

I work for a major defense contractor, and while we have vanilla python we are categorically not allowed to download software off the internet and install it without authorization, even on the unclassified internet-connected corporate network. Theoretically there's a process for requesting new software and getting it approved, but actually pushing it through requires getting one of my program architects to care enoug…

> Theoretically there's a process for requesting new software and getting it approved, but actually pushing it through requires getting one of my program architects to care enough to file the request

I worked for a much smaller government contractor, but before I left they were moving to a system where you needed approval from the customer in order to get new packages. (For those who don't work in this field, that means you are actually making a request to the contracting representative from the particular government agency for each package you want.) So it wasn't just in-house bureaucracy in the way of progress, and I generally just went without or wrote my own instead of trying to deal with it.

Re: “Python's batteries are leaking”

#365

Post by throwaway2048 »

mycall wrote: post #268
halter73 wrote: post #253

Earlier quoted context omitted.

I've found the built-in Windows 10 ssh client has trouble with tunneling, so I still use the ssh client included with git.

netsh interface portproxy add v4tov4 listenport=8001 connectport=80 connectaddress=1.1.1.1

this isn't useful for tunneling through a remote machine (which is what ssh does)

Re: “Python's batteries are leaking”

#366

Post by rmtech »

There's an important tradeoff going on between library code that is (in theory) trusted and library code that is less trusted but has other advantages like solving a problem better or being a solution to problems that the most trust code can't solve.

Right now the equilibrium in this tug-of-war is that a certain set of functionality comes by default in the python standard library and everything else is just a package that you can install.

Obviously from a dev point of view it's a hassle to have to decide which of two or more packages for X is best, the pythonic way would be that there should be one and only one package for X. Of course at the cutting edge there have to be competing packages because there needs to be room for innovation.

But obviously not everything can be in the python standard library.

Not really sure what the solution is, but maybe there should be tiers of packages, with "Tier 1" being standard library, "Tier 2" having some kind of official stamp that it has been security audited to a certain standard, that Python has some control over who gets to modify it and why etc. Then maybe "Tier 3" could cover everything else, i.e. any bob random can go make a package on PyPi and it's Tier 3.

In addition, the process of going from Tier 3 to Tier 2 would give people a chance to winnow libraries down to one way of doing each thing at the Tier 2 level.

This might not be realistic but it's what my gut is telling me. C&C welcome.

Re: “Python's batteries are leaking”

#367

Post by theossuary »

vlovich123 wrote: post #348
lalaland1125 wrote: post #274

Earlier quoted context omitted.

Modern python tooling like pipenv pins the dependencies of your dependencies as well. This is no longer an issue

I used a requirements.in file to list out all the top-level direct dependencies & then used pip-compile from piptools to convert that into a frozen list of versioned dependencies. pip-compile is also nice because it doesn't upgrade unless explicitly asked to which makes collaboration really nice. I then used the requirements.txt & various supporting tooling to auto-create & keep updated a virtualenv (so that my peers…

I don't know if it'd work the same way, but I've had a lot of success with Twitter's Pex files. They package an entire Python project into an archive with autorun functionality. You distribute a Pex file and users run it just like a Python file and it'll build/install dependencies, etc. before running the main script in the package.

I used it to distribute dependencies to Yarn workers for PySpark applications and it worked flawlessly, even with crazy dependencies like tensorflow. I'm a really big fan of the project, it's well done.

https://github.com/pantsbuild/pex

Re: “Python's batteries are leaking”

#368

Post by rmtech »

pornel wrote: post #323
dragonwriter wrote: post #106

Note that similar issues were raised with Ruby stdlib, which is being addressed in part with “Gemification” of stdlib, so that all of stdlib (targeted for 3.0, though it's been going on since 2.4)[0] is being moved out to externally-updatable packages that are included by default (default and bundled gems), so that it is still “batteries included” but the batteries are at least replaceable. Amber's suggestion seems t…

This is close to what Rust is doing, and it's working pretty well, apart from shocking newcomers who expect libstd to be useful on its own. In Rust, libstd is mainly for interfacing with the compiler and providing interoperability between packages (crates). The wider crate ecosystem is the real standard library, since external crates are as easy to use as the standard library. For example, the libstd doesn't even hav…

I've never coded Rust - is there any distinction between a really important crate used by millions of people and something really obscure with 3 users? Are all the crates subject to security audit?

Re: “Python's batteries are leaking”

#369

Post by mruts »

sametmax wrote: post #304
i386 wrote: post #302

> The debate at this point became personal for Van Rossum, and he left angrily. Guido should stop acting like a child. Listening to people, hearing them out - even when it’s uncomfortable - is the mark of a good leader. I tell new PMs “this is the best job in the world 90% of the time but the other 10% is eating shit with a smile”

He is not. He has been working on it for 25 years and he is just fed up to having to explain again and again the same things. He doesn't want to see the careful and long work he did being dragged to a standard he considers lower. There is always a new person coming with a new idea. It's exhausting, because it's required to make the language evolve, but it's also a new opportunity to screw things up evertime. And if h…

I dunno, Python is the epitome of a "meh" language. Guido has help Python back with his antiquated "get off my lawn" attitude since he created it.

The language itself is inferior in expressiveness and performance to almost any other modern language. The only reason anyone uses it anymore is the network effects of the library are very strong, especially is fields relating to ML and data science.

Re: “Python's batteries are leaking”

#370

Post by mruts »

banachtarski wrote: post #247

I had to code in Python recently and had PTSD over all the syntactically significant whitespace. I have no idea how I ever found productivity in the language coming back to it now with fresher eyes. Refactoring, editing, and writing new code feels like such a drag.

I don't think Python is worth using for most new non-data science projects nowadays. The language is ugly and hard to work with. Also the performance is terrible.
Post reply on HN