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

321–330 of 420 posts

Re: “Python's batteries are leaking”

#321

Post by coldtea »

jMyles wrote: post #21

Guido is a good dude, through-and-through, despite his perhaps bad behavior here. Amber is nothing short of an open source hero, having brought Twisted, one of the best open source projects in the world, to new heights. Her insights are as important as anyone in the python community, and after six consecutive PyCons sprinting at the Twisted table (including literally in a chair with Amber to my left and Glyph to my r…

>Amber and Guido are both beautiful human beings.

Perhaps, but Guido's response was shitty here (and purposefully refusing to get the point), whether one think Amber was right or not.

I deal constantly with the shitshot that is Python packaging (and lack-luster default packages) and I happen to think she is 100% on the spot.

Re: “Python's batteries are leaking”

#322

Post by dataflow »

maxnoe wrote: post #319
dataflow wrote: post #306

Earlier quoted context omitted.

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

> It makes absolutely no sense to have escaped unicode characters as actual unicode string.

Absolutely no sense? So is a basic Python expression evaluator like this complete nonsense to you? #!/usr/bin/env python3

  try:  # Python 2
   from Tkinter import Tk, Entry, END
   import tkMessageBox as messagebox
  except ImportError:  # Python 3
   from tkinter import Tk, Entry, END, messagebox

  import ast
  def my_eval(s):
   # assume I've implemented this functionality manually...
   return ast.literal_eval(s)

  root = Tk()
  e = Entry(root)
  e.insert(END, '"Hell\\xc3\\xb6"')  # Assume the user typed has typed in a Python expression, not me
  e.pack()
  root.bind('', lambda evt: messagebox.showinfo("Result", repr(my_eval(e.get()))))
  root.mainloop()
I get an escaped string... because that's quite literally what Entry.get() gives me from the text box the user typed into. The simple fact that I got a string containing Python source code with escape characters makes "absolutely no sense" to you?

Note that that wasn't even my choice! That was the choice of the built-in Python GUI toolkit... distributed by the same folks who decided this string/bytes overhaul was a brilliant idea...

Re: “Python's batteries are leaking”

#323

Post by pornel »

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 have support for random number generation. There's a rand crate, which is now on 6th major breaking version. That's perfectly fine, because multiple versions can coexist in one program, and every user can upgrade (or not) at their own pace. And the crate was able to refine its interface six times, instead of being stuck with the first try forever.

Re: “Python's batteries are leaking”

#324

Post by dtech »

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.

The argument is not that this module should be removed, it's that it too niche to be included in every python installation by default and should be installed through a package manager or similar.

Re: “Python's batteries are leaking”

#325

Post by gautamdivgi »

sametmax wrote: post #285
loeg wrote: post #278

Earlier quoted context omitted.

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.

Yes but it won't get it. And at the end if the day, people need to be able to get work done. The corporate world is full of stupid things that will never not change, or take years to change.

Where I work the solution was to use a proxy to pypi. Basically an internal pip repo (and docker, npm, maven, everything else...). All internal apps go through the internal repository that creates a local version of the package from pypi. That gives the security / compliance folks a way to block packages with security issues, etc. and at the same time provide the developers flexibility to get most of what is needed.

In a large company this gives the compliance folks a central place to blacklist packages - along with a trail of what systems have downloaded the package to target for upgrades.

Re: “Python's batteries are leaking”

#326

Post by gigatexal »

postgeographic wrote: post #314
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."

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 an…

Hierarchies and the systems or checks that they serve at places like this exist only to keep some people employed. That has got to suck! For anyone who has a rogue or novel idea will get shot down because it’s too much of a burden in terms of overhead to get any decision made.

Re: “Python's batteries are leaking”

#327

Post by [deleted] »

gigatexal wrote: post #326
postgeographic wrote: post #314

Earlier quoted context omitted.

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 an…

Hierarchies and the systems or checks that they serve at places like this exist only to keep some people employed. That has got to suck! For anyone who has a rogue or novel idea will get shot down because it’s too much of a burden in terms of overhead to get any decision made.

[deleted]

Re: “Python's batteries are leaking”

#328

Post by DonHopkins »

petre wrote: post #251
aasasd wrote: post #169

Earlier quoted context omitted.

> Does anyone have a curated version of PyPI? Pypi have thrown out the downloads counter—a huge misservice to coders. Like I got all day to figure out the best libs for ten different features which I only need in passing, so my primary concern is to not pick complete garbage. So, my solution to that now is to look up Github pages for the libs and choose the one with most stars. As much as I dislike Github for its occ…

Perl has stars on MetaCPAN and every version has a test counter. Download counter is unreliable.

Especially download counters for libraries that make http requests!

Re: “Python's batteries are leaking”

#330

Post by DonHopkins »

alexdong wrote: post #109
tptacek wrote: post #88

Earlier quoted context omitted.

Is "embrace PyPI and move things like asyncio there" not a constructive suggestion, or is she sort of being penalized because the most reasonable solution to the problem can be described in less than half a sentence so it's seems like there's more complaint than solution?

Yup. Totally agree with you on that. And yes this one is a constructive proposal. My problem is on the like part. Where shall we draw the line and how do we decide? To me this is a far more interesting discussion. (Maybe it has happened. I don’t go to many conferences these days so I might be missing something here. ) She mentioned http.client vs requests, datetime vs. moments etc, which are also quite correct to me.…

Maybe Python should upgrade from toxic leaking alkaline batteries to explosive overheating lithium batteries!
Post reply on HN