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

311–320 of 420 posts

Re: “Python's batteries are leaking”

#311

Post by pas »

guggle wrote: post #309
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.

Non maintained modules should be split off and put on PyPI with a big warning, of course.

Re: “Python's batteries are leaking”

#312

Post by schlenk »

porker wrote: post #288
mjw1007 wrote: post #50

If your project has any third-party dependencies, and so (nowadays) you're going to set up requirements.txt and virtualenv and whatever anyway, I can see that you're going to think things like "this XML parser in the standard library is just getting in the way; I can get a better one from PyPi". But I think a lot of the value of a large standard library is that it makes it possible to write more programs without need…

> and so (nowadays) you're going to set up requirements.txt and virtualenv and whatever anyway If only that were the norm amongst long-tail python users. Heck I don't do it; I have the anaconda distribution installed on Windows and when I need to do a bit of data analysis hope I have the correct version of packages installed. Making this core to the python workflow (bundling virtualenv? updating all docs to say "Set…

I develop in python since 10+ years. And setting up a virtualenv only happens when developing patches for 3rd party packages. (due to the other commercial environment that doesn't work with venvs).

And it is a totally miserable experience on Windows, every single time.

Re: “Python's batteries are leaking”

#313

Post by pas »

porker wrote: post #288
mjw1007 wrote: post #50

If your project has any third-party dependencies, and so (nowadays) you're going to set up requirements.txt and virtualenv and whatever anyway, I can see that you're going to think things like "this XML parser in the standard library is just getting in the way; I can get a better one from PyPi". But I think a lot of the value of a large standard library is that it makes it possible to write more programs without need…

> and so (nowadays) you're going to set up requirements.txt and virtualenv and whatever anyway If only that were the norm amongst long-tail python users. Heck I don't do it; I have the anaconda distribution installed on Windows and when I need to do a bit of data analysis hope I have the correct version of packages installed. Making this core to the python workflow (bundling virtualenv? updating all docs to say "Set…

The stdlib would still ship with Python I presume, it would be simply updatable. But that doesn't mean it wouldn't work without a "requirements.txt" (use Pipenv which is light-years ahead).

Re: “Python's batteries are leaking”

#314

Post by postgeographic »

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

Not who you asked, but I work for a large international company, a big 4 professional services firm. I wanted to install anaconda and Jupyter on my machine (data science is not a part of my 'official' job description, but I wanted to see how much of my data exploration workflow I could speed up or automate). I had to go up three separate hierarchy ladders to get sign off. First, my own team, then IT, then our risk and quality team (thanks to our audit practice and a few historical issues with whistleblowers and leaks, the risk guys are pretty much the final arbiter of... Everything)

After about 9 weeks of emails, meetings, and pitches, I finally got Anaconda up and running. A week later, I tried to upgrade the 3rd party packages.. No dice. Blocked by the corporate VPN. I'd need the sign off every time I wanted to `pip upgrade` anything

Needless to say, I do not bother anymore.

Re: “Python's batteries are leaking”

#315

Post by schlenk »

Groxx wrote: post #202
someguydave wrote: post #199

Earlier quoted context omitted.

Hopefully the “python foundation” will declare python 2 deprecated soon so that it can be handed over to responsible maintainers.

That's happening: https://pythonclock.org/ To ensure things move along: pip has been printing highly-visible "python 2.7 will deprecate soon" warnings for a couple months or so now.

And backing out of it when running on pypy, as that does not deprecate python 2 compatibility...

Re: “Python's batteries are leaking”

#316

Post by aphexairlines »

nullwasamistake wrote: post #263
dehrmann wrote: post #127

Earlier quoted context omitted.

I try to avoid Guava because they have a habit of making incompatible breaking changes, and because so many libraries depend on it, it's likely to cause version conflicts. The way Apache Commons puts the major version in the package is much better in that regard.

I have not experienced this running guava 16-23 in various apps. Maybe incompatible but they're good about security patches for old versions. I have never seen a version conflict between guava releases

Transitive dependencies on Guava 19, 20, 21 can lead to runtime crashes if your dependencies differ in what guava versions they expected when they were compiled:

https://www.google.com/search?q=guava+nosuchmethoderror

Re: “Python's batteries are leaking”

#318

Post by schlenk »

icegreentea2 wrote: post #163
rlayton2 wrote: post #148

Earlier quoted context omitted.

It uses a non trivial amount of resources for (nearly) every python install. Therefore if it isnt of substantial use then it should be removed to free those resources

It does, but it's hardly an egregious amount (my 3.7 install on Win10 has it at 800Kb... though I guess tcl takes up 10MiB =P). For reference, the built in venv module (which I never use cause I'm all about that virtualenv life) is 1MB. The python tests are 20MB, and that ships by default on every python installation. Like if you were in a resource constrained situation, you would be customizing your python install a…

Maybe just use kitdll instead of a full blown Tcl/Tk distro, to provide the dependency, that would shrink the size a lot.

http://kitcreator.rkeene.org/fossil/wiki?name=KitDLL

Re: “Python's batteries are leaking”

#319

Post by maxnoe »

dataflow wrote: post #306
lozenge wrote: post #305

Earlier quoted context omitted.

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?

https://docs.python.org/3/library/codecs.html

The encoding `unicode_escape` is not about escaping unicode characters. It's about python source code. It's defined as:

> Encoding suitable as the contents of a Unicode literal in ASCII-encoded Python source code, except that quotes are not escaped.

It makes absolutely no sense to have escaped unicode characters as actual unicode string. If you really need that, a version that also works in python 2 would be:

     u'hellö'.encode('unicode_escape').decode('ascii')

Re: “Python's batteries are leaking”

#320

Post by cameronbrown »

adontz wrote: post #175
cameronbrown wrote: post #138

Earlier quoted context omitted.

Better than breaking software. Linux is far more important when it comes to ABI stability here than Python though.

Linux has no stable ABI :-)

For driver developers sure, but it's userspace ABI is very stable.
Post reply on HN