[Python-ideas] Add appdirs module to stdlib

Philipp A. flying-sheep at web.de
Wed Sep 2 10:10:29 CEST 2015

OK, original poster here.

thanks for the positive reception!

so there are some issues which i’ll address


   *appdirs doesn’t get everything right*
   → in order not to have inconsistencies, we could abandon the “appdirs as
   a fallback” approach and create our own API which returns more correct
   results. this also frees us to make other changes where we see fit, e.g.
   see next point

   *there is a search path instead of a single directory sometimes*
   → appdirs provides a multipath keyword argument which returns a
   (colon-delimited) “list” of paths. we should provide sth. similar, only
   with python lists. maybe also convenience functions for getting a list of
   all files matching some subpath similar to [d / subpath for d in
   site_data_dir(appname, appauthor, all=True) if (d / subpath).exists()]

   *some platforms don’t have some specific subset of the functionality
   (e.g. no config dir on OSX)*
   → provide a warning in the stdlib docs about that and refer to another
   settings API. unfortunately i can’t find a good NSDefaults library in
   python right now. i think the API should still return some directory that
   works for storing settings on OSX in case people want to use
   platform-independent config files.

   *it’s hard to tell newbies where their files are*
   → unfortunately that’s how things are. the existing standards are
   confusing, but should be honored nonetheless. we can provide an api
like python
   -m stddirs [--config|--data|...] <companyname> <appname> which prints a
   selection of standard directories.

did i miss anything?

and yeah: i also think that something that’s a little opinionated in case
of ambiguities is vastly better than everyone hacking their own impromptu
platform-dependent alternative.

~/.appname stopped being right on linux long ago and never was right on
other platforms, which we should teach people.

best, phil

Nick Coghlan <ncoghlan at gmail.com> schrieb am Mi., 2. Sep. 2015 um 07:57 Uhr:

> 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.
> Regards,
> Nick.
> 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
> essentials.
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150902/58967a51/attachment-0001.html>

More information about the Python-ideas mailing list