Live data from Hacker News

“Python's batteries are leaking”

pyfound.blogspot.com

41–50 of 420 posts

Re: “Python's batteries are leaking”

#41
It's funny to me that they're making a point that PyPI is better than core, because actually I think PyPI has created a rather crap ecosystem. The non-hierarchial organization of packages, the lack of curation, lack of inheriting past functionality and extending it as more standard functionality, etc has resulted in a confusing sprawl of packages with duplicate, incompatible, buggy functionality. It's a bit like Linux internals; it's grown haggard over time, isn't organized well, is badly documented, and so it's difficult to pick it up and use it without stumbling over a decade or more of stale documentation and obsolete software.

Perl has a much better set of modules that extend standard functionality, which considering how much flack Perl gets for being hard to read, is rather funny. Rather than every new feature being its own independent project, most of the useful modules inherit a parent and follow the same convention, leading to very simple and easy to use extensions. And Perl Core isn't all that great, but it does have some batteries included, and everything else is extended easily and in a more standard manner by CPAN.

Re: “Python's batteries are leaking”

#42
post #8
post #2

Why, time and time again, does Guido seem incapable of reasonable debate, or ideas that challenge his own? It's completely rude to interrupt a presenter with 'what is your point?' Years ago I was in contact with the author of Nuitka, who was very excited to share his work thus far. During his presentation, Guido kept huffing and making snide comments under his breath. All because he disagrees with the premise behind…

Maybe he’s simply burnt out? The pressure of being in charge of something as big as Python must be intense. People make demands on his time and expect the “benevolent dictator” to cunningly solve everything like a modern day Salomon. I know he gave up the title, but as he personifies Python, I imagine the influx of requests for his attention may not have subsided much.

Has DHH, Matz, Ryan Dahl, the Allaires, Larry Wall, or anyone else who founded a language or related-project been known for behaving like this?

Re: “Python's batteries are leaking”

#43

When I first used python like 20 years ago I was blown away by how much functionality was blown in, and it can be annoying using languages where even the most basic functionality involves downloading 50 packages from the internet, but on the other hand the standard library does seem to be a mess now.

Yea. I'm using Rust at the moment for fun and the amount of things not in the standard library is crazy to me. What? There is no built-in dictionary? What do I use instead and where is it? Edit: based off of all the replies below, everyone understands the validity of what I'm trying to say, but also have fortunately pointed out my admittedly grevious error of not knowing you can just import hashmap from stdlib. The e…

I know it's not the whole point, but there is a hash map and sorted (btree) map in the std collections.

That being said the point still stands, I remember specifically feeling it at the lack of included regex. I overall prefer the slim std lib of rust over the massive python though. Especially with the community being pretty good about nominating de facto standard packages like for regex.

Re: “Python's batteries are leaking”

#44

When I first used python like 20 years ago I was blown away by how much functionality was blown in, and it can be annoying using languages where even the most basic functionality involves downloading 50 packages from the internet, but on the other hand the standard library does seem to be a mess now.

I found that attractive when I first learned Python, but when I (much more recently) started picking up Rust, I was blown away by how easy and normal it is to use external packages: the build tool and package manager are the same thing and shipped with the language, the hello-world-equivalent docs assume you're using it, and even the Rust compiler and standard library themselves can (carefully) depend on external packages. Having run up against limits of the Python standard library several times in years of writing production software in it and not just learning it, I find the batteries-not-includes-but-easy-to-install approach better on the whole. (Rust is not the only language that does this - my impression is Node/NPM and Swift, at least, are similar - but it's the one I happen to be familiar with.)

In Python's defense, this was not obvious at the time; my understanding is Rust came to this approach by looking at the experience of Python and other languages. When Python's standard library was first being written, there were no easy package managers for any language, and the normal thing to do for installing dependencies in e.g. C was to grab random tarballs and figure out how to build and deploy them yourself. So avoiding that process made perfect sense.

Re: “Python's batteries are leaking”

#45
She seems to be advocating that Python do pretty much what Perl has ended up doing, which is "we have some batteries, but we haven't been adding new ones for a decade or more".

The reasons are similar, it's a constant drag on core compiler development to need to support various batteries included that most core contributors aren't going to care about, so it's easier to tell people "use CPAN".

There was even talk of "distros" for the interpreter. Where the core bits would be similar to what Linux is, and all the batteries would be provide as collections of add-on packages.

Strangely enough these efforts seem to stop at OS distributors. They really seem to like to install just the one "compiler", and wouldn't stand for a project like Perl or Python telling them "we mean for you to distribute the core compiler plus these 100 packages, because that's what forms our 'language'". "Strangely" because you'd think they'd be the best positioned to make easy work of packaging up such a thing, and it shouldn't in principle make a difference if you need to install 100 RPMs / APTs by default.

Re: “Python's batteries are leaking”

#46
post #38

Why is it so difficult to admit Node.js did the package thing right, by keeping a local folder just for the app, isolation from other apps with zero effort?

It's worth noting that npm was developed independently of node

https://groups.google.com/forum/?hl=en#!topic/nodejs/erDWyS4...

Re: “Python's batteries are leaking”

#47
post #18
post #15

I was rather shocked to find that python didn’t have a full-featured crypto library included in its standard lib. The alternatives all ended up being unmaintained or maintained by small groups (which makes trust in the soundness difficult). I tapped our security team, who were in disbelief, but ultimately they gave up to and I wrote the software in go instead.

You want pyca/cryptography. The last thing in the world you want is a standard crypto library that no experts are enthusiastic about maintaining. Golang had an unfair advantage here, because the language team included cryptography engineers. It would be weird if most languages had the same kind of crypto in their stdlibs. I think there is in general nothing wrong with a language ecosystem where key parts of the whole…

Also I expect that a) pyca/cryptography is maintained by as many people as Go's cryptography libraries are, so the worry about maintenance by small groups doesn't argue in favor of Go here b) the number of people maintaining any particular module in the Python standard library is very small (e.g., IIRC there's one maintainer for `ssl`).

I would be surprised if either 'kentm or their security team wanted the rest of the Python standard library developers (or the Go ones, for that matter) to mess with cryptography modules when it's not their area of expertise.

Re: “Python's batteries are leaking”

#48
post #34

> six is non-optional for writing code for Python 2 and 3 I maintain a Python 2 & 3 compatible project that has no external dependencies.

have you written your own 2/3 compatibility layer? I can't imagine writing anything large without six... fwiw, six can easily be vendored into a project to avoid the technical external dependency. that is how we manage it for kafka-python.

No compatibility layer. Its really not bad.

there are a few modules that are simply at different locations but have the same API

  if PY3:
    from http import client as httplib
  else:
    import httplib
constants

  PY3 = sys.version_info >= (3, 0)
  PY2 = sys.version_info = (2, 6) and sys.version_info 
is string

  isinstance(, basestring if PY2 else str)
using different classes

  # Python 2.6 doesn't properly UTF-8 encode syslog messages, so it needs
  # to be performed in a custom formatter.
  formatter_class = UnicodeLoggingFormatter if PY26 else logging.Formatter

Re: “Python's batteries are leaking”

#49

Earlier quoted context omitted.

It seems that those programming language communities which have a more "social" aspect also tends to lead to more associated drama like this.

It's one of the things I really like about the R community. It's incredibly friendly and without egos, and has lots of people who actively work to make the community as safe and welcoming for everybody. I can't say I've ever heard about drama like this from there.

R is one of the few languages that I actually use a little bit, yet know absolutely nothing of the community and history. I mean I could tell you all about a dozen niche languages from Lisp to Haskell, but nothing of this masterpiece. Time to go read up on R :).

Any chance you could give a short little blurb for how the community is organized and works? I'm curious how different it is to Python. I also sometimes worry about the future of R where you have Python-Pandas coupled with Spyder IDE and Julia-DataFrame library with Atom-Juno as IDE as well as JuliaDB. It seems like a lot of communities are moving in on what R does best.

Re: “Python's batteries are leaking”

#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 needing that first third-party dependency.

This is particularly good if you're using Python as a piece of glue inside something that isn't principally a Python project. It's easy to imagine a Python script doing a little bit of code generation in the build system of some larger project that wants to parse an XML file.

Post reply on HN