[Python-ideas] Python 3.9.9 - The 'I Have A Dream' Version

[Simon Kennedy]

On Wednesday, 15 April 2015 12:44:59 UTC+1, Chris Angelico wrote:
>
> Based on the subject line, I have to first apologize that I may come 
> off as mean and scary, with a sneer that curdles dairy. But here goes. 
> Feel free to hate me for saying this. :) 
>
>
I have no problem with "harsh but fair".
 

> There is a fundamental difficulty with the unification of the 
> disparate, in that you have to start coping with all sorts of 
> differences and try to make sense of them *in code*. When, for 
> instance, you want to unify config handling, what you're saying is 
> either that every config handler has to devolve to the lowest common 
> denominator, or else that your unified config handler has to become 
> the least common multiple.


The stdlib is full of modules which don't attempt everything but instead 
attempt to do a useful subset and everyone seems to be happy they're 
included.

Why not configuration file handling?

I assume we're writing Python code and that eventually all config data 
needs to end up in memory that Python can access.

Pulling numbers out of my posterior, lets say 80% of projects only need 
nothing more than a text file with a set of sections with name/value pairs 
under them. That can be parsed into a dict.
And 5% want to use Python code. That when it gets exec'ed a dict comes out 
the other end
And 5% want to use a database. We can produce an adapter (say sqlite) that 
spits out a dict or they can.
And 5% want to use an etcd store.
That leaves 5% that want to do something funky. They're on their own

There aren't that many configuration storage systems in the world.

Then you define the order which sources (command line / env var / global 
config etc.) are used and merge them into a complete configuration

Why not 'bless' some code which simplifies the 95%

There's a distribution on PyPi called 'layeredconfig' which does much of 
what I think could be done. A few Python projects I've encountered seem to 
follow a similar pattern.

I'm not sure that I see the demons you appear to see in config file 
handling. Perhaps you could give a real world example
 

> The latter may seem tempting ("you can use 
> this module to do ANYTHING!"), but you quickly fall foul of the 
> Inner-Platform Effect. 
>
> http://thedailywtf.com/articles/The_Inner-Platform_Effect 
> https://en.wikipedia.org/wiki/Inner-platform_effect 
>
>
That's not a term I've encountered before. But perhaps it's part of my 
problem but I looked at the Wikipedia page and I'm not sure it makes a case 
that the effect is bad.

For example the first is about Firefox's FTP. I use Sublime Text and some 
of the packages you can install do similar things but I'm not sure I would 
say they were wrong to wrap git for example.

Then it talks about and RDBMS and the entity-attribute-value model 
<https://en.wikipedia.org/wiki/Entity-attribute-value_model> but RDF uses a 
similar structure and is used with RDBMSs so it can't be all bad.

Then XML is mentioned. But I'll not touch that subject.

Then ChromeOS. Which people seem to like. So it's not affected it too much.

The only downside seems to be "they tend to be slower and if poorly coded, 
less reliable as well.[*citation needed 
<https://en.wikipedia.org/wiki/Wikipedia:Citation_needed>*]". But you could 
say that about any code.

If you want something to be truly customizable, the best way is to 
> make it Turing-complete and then let people write code. CPython is an 
> ultimately-customizable application, and we call its config files 
> "Python scripts". There's not a lot of point adding another 
> infinitely-customizable layer on top of that, just for something as 
> simple as configuration files. Better to allow code to be code. 
>
> Several of your proposals have merit, but they should be disentangled 
> from the ones which will just drag them down. 
>
> ChrisA 
>

Simon 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150415/ad26fbdc/attachment.html>