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

301–310 of 420 posts

Re: “Python's batteries are leaking”

#301

Post by growse »

rcfox wrote: post #293
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. You could install packages with `pip install --user` to have them install under your home directory.

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

> You could install packages with `pip install --user` to have them install under your home directory.

You might find that the issue isn't necessarily always technical (ie permissions), but policy. A lot of places don't let you arbitrarily download software off the internet onto a system. Pp's point is that having a full feature stdlib let's you only need to crank the policy/approval process once, rather than once for every dependent lib.

Re: “Python's batteries are leaking”

#302

Post by i386 »

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

Re: “Python's batteries are leaking”

#303

Post by lozenge »

deathanatos wrote: post #140
mehrdadn wrote: post #87

Earlier quoted context omitted.

I do similarly as you (maintain 2/3 code without dependencies) but every time I have to do string encoding/decoding it kills me to find a way that half works, and I don't have a ready solution in my mind for these that doesn't break half the time. How do you handle non-ASCII in a compatible manner? Like Unicode stdio? Unicode file paths? Unicode sys.argv? string_escape/unicode_escape? I feel like Python 3 completely…

For the most part, when you do I/O to some external system, if it's text, you encode/decode at the border to that system. Interally, all text data is `str` (or `unicode` in 2) and all binary data is `bytes` (in both). In some cases of common OS-induced pain, I'd say "do whatever 3 does" in 2, since that'll make migration easier in the long run. (But I understand that can be hard, and I think my responses to your exam…

Your suggestion works for stand alone programs, less so for libraries that are expected to keep working in python 2 programs that are not using unicode_literals etc.

Re: “Python's batteries are leaking”

#304

Post by sametmax »

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 he had let most people got their way during the last 2 decades, python would have ended just meh.

Of course, everytime a new debate starts, everybody thinks that this time, just this time, he is wrong and they are right. I did too. We are all part of it.

I get the reaction. There is a limit to what a person can take, and it's why he stepped down as a bdfl.

But seing your baby and your reputation at stake is hard.

Re: “Python's batteries are leaking”

#305

Post by lozenge »

dataflow wrote: post #298
maxnoe wrote: post #296

Earlier quoted context omitted.

I don't say the transition is easy or maintaining a codebase that handles these issues correct that supports python 3 and 2 at the same time. But looking solely at python3 , everything byte and unicode related just got so much easier and better testable and with better error messages at better points in your code than in python 2. So claiming python 3 broke stuff just not what the case is. Python 2 had a deeply flawe…

So for example what is your rebuttal to my actual example pointing out that "a".encode('unicode_escape') returns bytes instead of strings? Why/how the heck is it even encoding anything when it never even asked me for an encoding? If for nonsensical reasons it really wants to encode things, shouldn't it at least be asking me for an encoding if it wants a "clean separation" between strings and bytes? You find Python 2'…

Encode and decode always move between str and bytes. Otherwise you could never write a function that takes an encoding as the argument and uses it in the middle of its code (because the types of your locals would vary at runtime in incompatible ways).

What is your reason for using this obscure encoding anyway?

Re: “Python's batteries are leaking”

#306

Post by dataflow »

lozenge wrote: post #305
dataflow wrote: post #298

Earlier quoted context omitted.

So for example what is your rebuttal to my actual example pointing out that "a".encode('unicode_escape') returns bytes instead of strings? Why/how the heck is it even encoding anything when it never even asked me for an encoding? If for nonsensical reasons it really wants to encode things, shouldn't it at least be asking me for an encoding if it wants a "clean separation" between strings and bytes? You find Python 2'…

Encode and decode always move between str and bytes. Otherwise you could never write a function that takes an encoding as the argument and uses it in the middle of its code (because the types of your locals would vary at runtime in incompatible ways). What is your reason for using this obscure encoding anyway?

> Encode and decode always move between str and bytes.

Yes and my entire point is that this makes zero sense when we're talking about escaping.

> What is your reason for using this obscure encoding anyway?

Seriously?

Re: “Python's batteries are leaking”

#307

Post by dvhh »

_hardwaregeek wrote: post #53

I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib? Presumably you'd have to bump the language version, deploy it out and beg users to upgrade. Except, users don't upgrade stuff. While if you version the standard library, every new project will get the newer version of the standard library. Sure, there's space tradeoffs, though you could offer…

From a different perspective, servers usually have a maintenance cycle to update system package where the standard library could be updated, user package on the other hand have to be updated by the user themselves ( and they could stick with the obsolete version if they want too, and could have a per project package version ) there is no convenient way for the user to update all the versions.

Re: “Python's batteries are leaking”

#308

Post by schlenk »

loeg wrote: post #278
bloaf wrote: post #248

Earlier quoted context omitted.

Where I work, there is currently a push to get python on the computers that manage physical equipment operation. These computers are not allowed to connect to the internet, and have extremely limited connectivity to the rest of the business network. Installing anything new on them requires risk assessments like you wouldn't believe, since the consequences of malicious code could easily hit 10s of millions of dollars…

If your risk assessment says that the exact same tkinter outside of Python stdlib is riskier than in Python stdlib, maybe your risk evaluation process needs reevaluation.

As long as you cannot even prove that due to a lacking python code signing infrastructure for packages (wheels can do it, but it is far from wide spread).

And setup.py is a trainwreck, e.g. some packages compile download and compile huge dependencies (e.g. a full Apache httpd...), the default compiler flags may lack all the mandatory security flags (e.g. for using ASLR on python 2.x), or ship their own copy of openssl statically and break your FIPS-140 certification that way...

Re: “Python's batteries are leaking”

#309

Post by guggle »

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…

> I see the benefit of cleaning the stdlib of old stuff, like the wave module

Wait... what ? No way ! Some of us do you use Python to process wav files. If anything, I'd like this module to be updated, not removed.

Re: “Python's batteries are leaking”

#310

Post by schlenk »

lalaland1125 wrote: post #274
tachyonbeam wrote: post #241

Earlier quoted context omitted.

It's trickier than just pinning dependencies because some libraries also need to build C code, etc. Once you bring in external build tools, you have that many more potential points of failure. It's great. Also, what happens if your dependencies don't pin their dependencies? Possibly, uploading a package to pipy should require freezing dependencies or do it automatically.

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

Unless your dependency is a C-header file updated by your distro as part of a new version.
Post reply on HN