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

291–300 of 420 posts

Re: “Python's batteries are leaking”

#291

Post by [deleted] »

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

[deleted]

Re: “Python's batteries are leaking”

#292

Post by [deleted] »

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

[deleted]

Re: “Python's batteries are leaking”

#293

Post by rcfox »

bsder wrote: post #207
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…

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.

Re: “Python's batteries are leaking”

#294

Post by agumonkey »

sph wrote: post #283
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…

Having a huge standard library also kills analysis paralysis and lets people be more productive. If you're in the flow and trying to hack together something, the last thing you need is to lose all momentum to pick a date time library. I've had this issue tons of times with Node and Rust, where I'm not up to date with the current meta and my 30 minute hack job is interrupted 5 minutes in by having to google which libr…

I think go did this well, they provide a very solid toolset that is nothing fancy but you can forget about it right away and start producing solutions.

Re: “Python's batteries are leaking”

#295

Post by llukas »

nnq wrote: post #128
notatoad wrote: post #120

Earlier quoted context omitted.

This isn't a paradox. once it's released it's not a bug anymore, it's just behaviour. document the behaviour, but breaking compatibility with previous versions is a bug. it doesn't matter how obviously wrong the previous behaviour is.

> but breaking compatibility with previous versions is a bug That's how you get an inconsistent mess that never evolves. There's something called semver , increase the version number and do the fix / refactors / radical redesign / whatever. People will see that you've went from version 1.0 to 87.3 in one year and they may choose not to use your thing because you're moving too fast for them, but that's life...

1.0 to 87.3 in one year? More realistic would be python 2->3 in 10 years or so and still too fast...

Re: “Python's batteries are leaking”

#296

Post by maxnoe »

dataflow wrote: post #290
maxnoe wrote: post #289

Earlier quoted context omitted.

Everytime I hear somebody claim python 3 broke strings I just cringe. No. No on just so many levels. It finally fixed it by introducing two (or three if you count bytearray) types for completely different semantics of data. Python 2 was just a mess whenever you left ascii.

Meanwhile I cringe every time I see people say "No" while ignoring the issues people like me point out.

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 flawed, boundryless view of unicode vs bytes and python 3 fixed that.

Re: “Python's batteries are leaking”

#297

Post by Kwpolska »

sph wrote: post #283
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…

Having a huge standard library also kills analysis paralysis and lets people be more productive. If you're in the flow and trying to hack together something, the last thing you need is to lose all momentum to pick a date time library. I've had this issue tons of times with Node and Rust, where I'm not up to date with the current meta and my 30 minute hack job is interrupted 5 minutes in by having to google which libr…

You still need to learn to use the library you picked, even if it’s part of stdlib. Python has two HTTP libraries in stdlib, http.client and urllib.request. The former is low-level, and the latter has a fairly complicated API. Learning to use them will take much longer than just giving in and picking Requests. The stdlib docs will tell you to use Requests. Everyone on the Internet will tell you to use Requests. Any questions you might have for http.client/urllib.request will be answered by “use Requests”.

Re: “Python's batteries are leaking”

#298

Post by dataflow »

maxnoe wrote: post #296
dataflow wrote: post #290

Earlier quoted context omitted.

Meanwhile I cringe every time I see people say "No" while ignoring the issues people like me point out.

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's behavior of returning a string to be somehow deeply flawed but Python 3's returning of bytes to be sensible? Really? What problem are they solving here?

Re: “Python's batteries are leaking”

#299

Post by llukas »

pfranz wrote: post #155
will4274 wrote: post #121

What's the point of saying that a standard library feature was not added soon enough? Nobody can go back in time and add it earlier. I can complain to death about features missing from C++11 or I can start using C++14.

I think the point is that if those things in stdlib were external packages then older versions of the language would be easier to support because you could just update the package. I think the way it was phrased made it really easy to misunderstand. I think this goes to her point of Twisted wanting to support really old versions of Python and they would be a lot more comfortable not supporting really old versions of…

So they can keep python 2 on life support longer? That is not a good idea.

Re: “Python's batteries are leaking”

#300

Post by sametmax »

agumonkey wrote: post #294
sph wrote: post #283

Earlier quoted context omitted.

Having a huge standard library also kills analysis paralysis and lets people be more productive. If you're in the flow and trying to hack together something, the last thing you need is to lose all momentum to pick a date time library. I've had this issue tons of times with Node and Rust, where I'm not up to date with the current meta and my 30 minute hack job is interrupted 5 minutes in by having to google which libr…

I think go did this well, they provide a very solid toolset that is nothing fancy but you can forget about it right away and start producing solutions.

Give it 25 years.
Post reply on HN