[Python-ideas] Add appdirs module to stdlib

Nick Coghlan ncoghlan at gmail.com
Wed Sep 2 07:57:18 CEST 2015

On 2 September 2015 at 14:38, Robert Collins <robertc at robertcollins.net> wrote:
> On 2 September 2015 at 11:05, Paul Moore <p.f.moore at gmail.com> wrote:
>> This is a fair point. But it's also worth noting that the current
>> state of affairs for many apps is to just bung stuff in ~/whatever.
>> While appdirs may not get things totally right, at least it improves
>> things. And if it (or something similar) were in the stdlib, it would
>> at least provide a level of uniformity.
> In about 5 years time. Maybe,
> The adoption curve for something that works on all Pythons is able to
> be much much higher than that for something which is only in the
> stdlib 6 months (or more) from now. Unless we do a rolling backport of
> it.
> And if we're going to do that... why? Why not just provide a
> documentation link to the thing and say 'pip install this' and/or
> 'setuptools install_require this'.

My perspective on that has been shifting in recent years, to the point
where I view this kind of standard library modules primarily as a tool
to helps folks learn how the computing ecosystem works in practice.
Consider PEP 3144, for example, and the differences between ipaddress,
and its inspiration, ipaddr. The standard library one is significantly
stricter about correctly using networking terminology, so you can
actually study the ipaddress module as a way of learning how IP
addressing works. The original ipaddr, by contrast, is only easy to
use if you already know all the terms, and can say "Oh, OK, they're
using that term somewhat loosely, but I can see what they mean".

I think this is a case where a similar approach would make sense -
like ipaddr before it, appdirs represents an actual cross-version
production module, put together by a company (in this case ActiveState
rather than Google) for their own use, but made available to the wider
community Python through PyPI. As such, we know it's feature coverage
is likely to be good, but the API design is likely to be optimised for
experienced developers that already understand the concepts, and just
want a library to handle the specific technical details.

A standard library API would shift the emphasis slightly, and take
into account the perspective of the *beginning* programmer, who may
have only first learned about the command line and files and
directories in the course of learning Python, and is now venturing
into the realm of designing full desktop (and mobile?) applications.


P.S. The statistics module is another example of being able to use the
Python standard as a teaching tool to help learn something else: for
many production use cases, you'd reach for something more
sophisticated (like the NumPy stack), but if what you're aiming to do
is to learn (or teach) basic statistical concepts, it covers the

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

More information about the Python-ideas mailing list