[Python-Dev] proto-pep: plugin proposal (for unittest)

Michael Foord fuzzyman at voidspace.org.uk
Mon Aug 2 16:37:08 CEST 2010


On 02/08/2010 15:24, R. David Murray wrote:
> (Ronald, the text version of your message was very difficult to sort
> through and read, because all of the quoting information was lost.
> Just thought you'd want to know.)
>
> What I hear Glyph saying is that we should support looking in *both*
> locations for configuration info on OSX, and I don't see a downside to
> that.  Most unix applications look in multiple places for configuration
> info.
>    

That adds extra complexity to the implementation of the configuration 
system. If it uses the first one it finds which order does it look in, 
if we have tools that create the file which location does it create it 
in and so on.

> Michael seems to be arguing for not using the standard OSX locations
> because the Finder can't edit them anyway.  Is that true?
>    
I am saying that Ronald's suggestion is *not* a natural location for 
user editable configuration files - as far as I can tell I have no user 
editable files there and plenty in ~/.something. Ronald himself said 
that the location he is specifying is the standard location for 
configuration / preference files created and used by *gui* tools, and 
files in that location are not usually intended to be user editable.

I don't believe a Mac user basically competent at the command line is 
*likely* to go looking in the gui preferences location for these config 
files and I think they would easily find them in ~. This is backed up 
the number of existing programs that use this convention on Mac OS X. It 
*is* a widely used convention on Mac OS X to use ~/.appname for 
configuration files. Applications like mercurial use this location on 
the Mac for example.

Ronald was wrong when he said that the only configuration file in ~ used 
by the Mac itself is .CFUserTextEncoding. Terminal (the Mac OS X command 
line) has a user editable config file which it stores in ~.

The issue with the finder is that by default . files and directories 
aren't shown and so they wouldn't be editable from the finder. As basic 
willingness to use the command line is a prerequisite for *wanting* to 
edit these files I don't see this as an issue. A user unfamiliar with 
the command line is not likely to guess the correct location for these 
files if we put them elsewhere, so they are going to have to refer to 
some documentation anyway.

Michael


> --
> R. David Murray                                      www.bitdance.com
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.




More information about the Python-Dev mailing list