[Python-ideas] PEP 426, YAML in the stdlib and implementation discovery

[Nick Coghlan]

On Tue, Jun 4, 2013 at 11:14 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> Agreed, but adoption of an existing library (presumably PyYAML as it's the
> only mature one I'm aware of) is the only sensible option, surely? Writing
> something brand new for the stdlib - or worse still, writing something
> *partial* and brand new - can't be a sensible option. (And I'd consider a
> pure-python implementation "partial" in that sense, I see no reason to have
> a version that is deliberately slower than the competition in the stdlib).

Technically two of the recent additions (ipaddress and enum) were at
least redesigns and arguably fairly substantial rewrites of their PyPI
inspirations (ipaddr and flufl.enum respectively).

This "like that existing library, but..." model can be useful at
times, as the standard library often needs to take into consideration
things that third party library developers don't need to worry about.
In particular, third party library authors can usually assume that
their users are already familiar with the domain that the library
covers. By contrast, for the standard library we typically have to
assume that our APIs will be used by people that need to *learn* the
domain specific concepts.

This was fairly stark with the ipaddr->ipaddress changes, where ipaddr
played fast and loose with networking terminology in a way that anyone
familiar with IP based networking could deal with easily, but was an
absolute nightmare if you were trying to use the API to learn IP
addressing concepts in the first place. So we ended up keeping the
algorithmic guts of ipaddr (all the stuff related to RFC compliance)
and changing the API around to more accurately reflect the formal
terminology, as well as greatly improving the error messages produced
for the inevitable mistakes that users will make (especially when
entering IPv6 addresses).

With YAML, we *may* end up with a similar situation where an existing
library is *almost* suitable, but needs some API tweaks to be suitable
for standard library inclusion, while preserving the core parsing and
generation engine.

Cheers,
Nick.


--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia