Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Thu, Aug 12, 2010 at 7:00 AM, Russell E. Owen ro...@uw.edu wrote: ... If the files are shared among all users then /usr/local/something seems more reasonable. I also think whatever you choose for linux is also the best choice for Mac OS X (my preferred platform). While there are other possible directories, such as ~/Library/Application Support/something, all tools derived from unix that I know about use the unix convention (ssh, X11, bash...) and I would argue that Python is close enough to count even though it is a framework build. Put another way, copying the unix convention is simple, is exactly what power users would expect and I don't see it would do any harm. Choosing an arbitrary location we think is good on every system is fine and non risky I think, as long as Python let the various distribution change those paths though configuration. In fact, that's one of the future goal of the sysconfig module I had in mind. Instead of having it reading paths from python variables, I would like to introduce a configuration file global to Python containing all the installation paths, and the paths we are currently discussing. That file could then be changed by distributions depending on their layouts. It will avoid distributions to hack Python to change those paths. For instance, Ubuntu currently patches distutils to change the installation paths. So let's: - define all the default locations for each system - define a sysconfig.cfg file that contains all installation paths, for each target system - change sysconfig.py so it uses it, instead of the global dicts it currently has Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden stu...@molden.no wrote: David Cournapeau: Autotools only help for posix-like platforms. They are certainly a big hindrance on windows platform in general, That is why mingw has MSYS. I know of MSYS, but it is not very pleasant to use, if only because it is extremely slow. When I need to build things for windows, I much prefer cross compiling to using MSYS. I also think that cross compilation is more useful than native mingw build alone - there are patches for cross compilation, but I don't know their current status, cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 11/08/2010 16:22, Éric Araujo wrote: It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesn’t clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) The canonical place on Windows (per Microsoft [1]) is: for roaming data: the Application Data folder (exposed as the APPDATA env var and as CSIDL_APPDATA pre-Vista and the FOLDERID_RoamingAppData Known Folder on Vista+). for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA or FOLDERID_LocalAppData) The obvious difference is whether a user expects the data to be available for the same account on a different computer. At present, the user site packages are held under %APPDATA%\Python\Pythonxx, ie are considered roaming. Unfortunately, the canonical place is not always the place most used. Especially since the convention under *nix is to place dotfile or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so various locations are considered $HOME, including (but not limited to): * the directory pointed to by %HOME% * the directory pointed to by %USERPROFILE% * the My Documents shell folder (often, but not always, %USERPROFILE%\My Documents) * c:\ (no: really) * the NT profile home directory (typically a mapped share) Dotfiles are possible on Windows; the issue is that they can't be created within the shell (ie within Windows Explorer). They can be renamed, edited, etc without issue, so it's not much of a problem. They can be created by any program which can call CreateFile -- including Python, obviously. TJG [1] http://support.microsoft.com/kb/310294 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 8/12/2010 5:50 AM, Tim Golden wrote: On 11/08/2010 16:22, Éric Araujo wrote: It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesn’t clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) The canonical place on Windows (per Microsoft [1]) is: for roaming data: the Application Data folder (exposed as the APPDATA env var and as CSIDL_APPDATA pre-Vista and the FOLDERID_RoamingAppData Known Folder on Vista+). for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA or FOLDERID_LocalAppData) The obvious difference is whether a user expects the data to be available for the same account on a different computer. At present, the user site packages are held under %APPDATA%\Python\Pythonxx, ie are considered roaming. Unfortunately, the canonical place is not always the place most used. Especially since the convention under *nix is to place dotfile or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so various locations are considered $HOME, including (but not limited to): * the directory pointed to by %HOME% * the directory pointed to by %USERPROFILE% * the My Documents shell folder (often, but not always, %USERPROFILE%\My Documents) * c:\ (no: really) * the NT profile home directory (typically a mapped share) Dotfiles are possible on Windows; the issue is that they can't be created within the shell (ie within Windows Explorer). They can be renamed, edited, etc without issue, so it's not much of a problem. They can be created by any program which can call CreateFile -- including Python, obviously. TJG [1] http://support.microsoft.com/kb/310294 Didn't we have this discussion when per-user libraries came up? Shouldn't we be using a subdirectory of that location? We ruin the risk of Python becoming distributed so finely it becomes impossible to change things, what with per-user libraries, per-version shared binaries, per-user-per-version library configuration files and the rest. One might make a case that all configuration data should be stored in a single SQLite database (with a suitable API to hide the relational nature of the store). Then at least there would only be one file no matter how many versions of Python were installed. Seriously. We are already spending enough time doing stat calls on non-existent directories. regards Steve PS: Then we can start putting the libraries themselves in the database. That works really well. -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 11:18, Steve Holden wrote: On 8/12/2010 5:50 AM, Tim Golden wrote: [... snip explanation of standard non-standard locations ...] Didn't we have this discussion when per-user libraries came up? Shouldn't we be using a subdirectory of that location? Yes we should. My explanation above was really just painting the picture. It should have been an Appendix for the Truly Interested. One might make a case that all configuration data should be stored in a single SQLite database (with a suitable API to hide the relational nature of the store). Then at least there would only be one file no matter how many versions of Python were installed. Seriously. We are already spending enough time doing stat calls on non-existent directories. -1 on this. I don't care how many stats we're doing; I want to be able to see my configuration / libraries etc without firing up a sqlite session. TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 10:50, Tim Golden wrote: Unfortunately, the canonical place is not always the place most used. Especially since the convention under *nix is to place dotfile or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so various locations are considered $HOME, including (but not limited to): * the directory pointed to by %HOME% * the directory pointed to by %USERPROFILE% * the My Documents shell folder (often, but not always, %USERPROFILE%\My Documents) * c:\ (no: really) * the NT profile home directory (typically a mapped share) Additionally, on Windows Python expands ~ to the first of: %HOME% %USERPROFILE% %HOMEDRIVE%\%HOMEPATH% all of which are perfectly defensible defintions of Home on Windows. But combining that with the Unix-minded concept of create a dotfile called ~/.myapp means you get dotapps in non-standard places on Windows. TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 11:18, Steve Holden wrote: On 8/12/2010 5:50 AM, Tim Golden wrote: On 11/08/2010 16:22, Éric Araujo wrote: It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesn’t clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) The canonical place on Windows (per Microsoft [1]) is: for roaming data: the Application Data folder (exposed as the APPDATA env var and as CSIDL_APPDATA pre-Vista and the FOLDERID_RoamingAppData Known Folder on Vista+). for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA or FOLDERID_LocalAppData) The obvious difference is whether a user expects the data to be available for the same account on a different computer. At present, the user site packages are held under %APPDATA%\Python\Pythonxx, ie are considered roaming. Unfortunately, the canonical place is not always the place most used. Especially since the convention under *nix is to place dotfile or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so various locations are considered $HOME, including (but not limited to): * the directory pointed to by %HOME% * the directory pointed to by %USERPROFILE% * the My Documents shell folder (often, but not always, %USERPROFILE%\My Documents) * c:\ (no: really) * the NT profile home directory (typically a mapped share) Dotfiles are possible on Windows; the issue is that they can't be created within the shell (ie within Windows Explorer). They can be renamed, edited, etc without issue, so it's not much of a problem. They can be created by any program which can call CreateFile -- including Python, obviously. TJG [1] http://support.microsoft.com/kb/310294 Didn't we have this discussion when per-user libraries came up? Shouldn't we be using a subdirectory of that location? We ruin the risk of Python becoming distributed so finely it becomes impossible to change things, what with per-user libraries, per-version shared binaries, per-user-per-version library configuration files and the rest. User editable configuration files are very different from libraries. The per user site-packages folder *should* be hidden somewhere out of the way where you can get at them if you want them but won't stumble across them all the time. e.g. AppData on Windows. For files we expect the user to be able to edit we shouldn't go out of our way to make them hard or inconvenient to find. One might make a case that all configuration data should be stored in a single SQLite database (with a suitable API to hide the relational nature of the store). Yay - let's recreate the Windows registry! A binary blob only editable with special tools, we know how much users love that. Michael Then at least there would only be one file no matter how many versions of Python were installed. Seriously. We are already spending enough time doing stat calls on non-existent directories. regards Steve PS: Then we can start putting the libraries themselves in the database. That works really well. -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 11:40, Michael Foord wrote: User editable configuration files are very different from libraries. The per user site-packages folder *should* be hidden somewhere out of the way where you can get at them if you want them but won't stumble across them all the time. e.g. AppData on Windows. For files we expect the user to be able to edit we shouldn't go out of our way to make them hard or inconvenient to find. This really comes down -- as with the Mac discussion last week, I think -- to the tension between standard file locations and easy-to-get-to. The difference on Windows, though, is that while on Mac it's either: Apple standard /This/That/TheOther vs Unix standard $HOME/.something on Windows it's %APPDATA%\myprog vs whatever-I-thought-of-at-the-time. APPDATA isn't actually that hard to get to on any version of Windows post 2000. (Just stick %APPDATA% into any Explorer window -- even IE, for goodness sake). Even from the command line it's not hard: notepad %APPDATA%\python\python26\idle.ini Ultimately, as a Windows user/developer, I'd vote for a memorable consistency, which for me would be %APPDATA%\python\... If everything's in one place, I'll just create a shortcut / hardlink / whatever to get me there when I want to change things. TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 11:54, Tim Golden wrote: On 12/08/2010 11:40, Michael Foord wrote: User editable configuration files are very different from libraries. The per user site-packages folder *should* be hidden somewhere out of the way where you can get at them if you want them but won't stumble across them all the time. e.g. AppData on Windows. For files we expect the user to be able to edit we shouldn't go out of our way to make them hard or inconvenient to find. This really comes down -- as with the Mac discussion last week, I think -- to the tension between standard file locations and easy-to-get-to. The difference on Windows, though, is that while on Mac it's either: Apple standard /This/That/TheOther vs Unix standard $HOME/.something on Windows it's %APPDATA%\myprog vs whatever-I-thought-of-at-the-time. APPDATA isn't actually that hard to get to on any version of Windows post 2000. (Just stick %APPDATA% into any Explorer window -- even IE, for goodness sake). Even from the command line it's not hard: notepad %APPDATA%\python\python26\idle.ini Ultimately, as a Windows user/developer, I'd vote for a memorable consistency, which for me would be %APPDATA%\python\... If everything's in one place, I'll just create a shortcut / hardlink / whatever to get me there when I want to change things. How is ~/python not memorable or consistent? (And cross-platform memorability and consistency is valuable too.) Another issue is discoverability. Many users won't know about these config files unless they *see* them. Sure if you *know* where they are then editing them is easy - but how often as a user do you browse your AppData folder? (As a windows user the only times I went delving in this mysterious location was trying to diagnose obscure errors.) I'm not aware of any consistent pattern of putting *user editable* files in AppData, and I doubt this is where most users would look for them. In fact for Windows the *correct* thing to do is probably to use the registry and then provide a graphical tool for editing the values. If you're arguing for consistency why not argue for this? If we were to provide native GUI tools for editing values then the location suggested by Ronald for the Mac (which is the standard location for preferences files maintained by GUI tools) would also be the right location. All the best, Michael TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 12:17, Michael Foord wrote: How is ~/python not memorable or consistent? (And cross-platform memorability and consistency is valuable too.) I was thinking outside Python rather than inside it (where ~ has no meaning on Windows) but you make a good point here. If we were just discussing Python code this would effectively be a winning point IMO. Another issue is discoverability. Many users won't know about these config files unless they *see* them. While I sympathise with this, I'm not sure how much weight one should give it in the context of this discussion. In the Unix world, if I were guessing, I would justifiably look in ~/.myapp followed perhaps by /etc/myapp. On Windows, I might go for the registry, as you mention elsewhere, and look in HKLM\Software\MyApp but for actual files I'm not sure where discoverable would be. re: using the Registry: To be honest, I was answering the literal question posed by Eric: where to put config files? Not the wider question: how should config data be stored? Where the answer to the latter question might be: the Registry -- much as I find it awkward to work with at times. One very definite point in its favour as regards this discussion is that Python on Windows *already* defines a key in the Registry (and has done so since v2.0 at least) and it would make some sense to place things under there. Ultimately, I don't feel very strongly about this subject. I'm more concerned that the chosen location (file or registry or whatever) be documented -- and documented from a Windows perspective as well, so you don't have to guess what HOME means in this context. TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
If the files are shared among all users then /usr/local/something seems more reasonable. Oh, right, I forgot to think about system-wide config files. They have to be supported by another function in site. A lot of programs have similar-looking code to get a list of filenames and then process it with configparser or something else: find_config_files in Distutils, get_standard_config_files in Docutils, rcpath in Mercurial. There are different namings to support (rc, .cfg, .conf, etc.) and also config directories (for Mercurial), but it does not seem impossible to define a standard function that would benefit Python itself and other programs. Choosing an arbitrary location we think is good on every system is fine and non risky I think, as long as Python let the various distribution change those paths though configuration. Don’t you have a bootstrapping problem? How do you know where to look at the sysconfig file that tells where to look at config files? In fact, that's one of the future goal of the sysconfig module I had in mind. Seems great. So let's: - define all the default locations for each system - define a sysconfig.cfg file that contains all installation paths, for each target system - change sysconfig.py so it uses it, instead of the global dicts it currently has I wonder if this is so complex that a wiki page or something else would be better suited than email to iron out the proposal. Or maybe it’s time for that sysconfig.cfg PEP you planned to do. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
Le 12/08/2010 12:18, Steve Holden a écrit : Didn't we have this discussion when per-user libraries came up? Shouldn't we be using a subdirectory of that location? As pointed out by Antoine, Georg, Michael and I, the PEP 370 directory for user site-packages is not the right place to put config files. PS: Then we can start putting the libraries themselves in the database. That works really well. I don’t know you well enough to tell if this is the final hint that you were sarcastic. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12 August 2010 12:59, Tim Golden m...@timgolden.me.uk wrote: re: using the Registry: To be honest, I was answering the literal question posed by Eric: where to put config files? Not the wider question: how should config data be stored? Where the answer to the latter question might be: the Registry -- much as I find it awkward to work with at times. One very definite point in its favour as regards this discussion is that Python on Windows *already* defines a key in the Registry (and has done so since v2.0 at least) and it would make some sense to place things under there. Ultimately, I don't feel very strongly about this subject. I'm more concerned that the chosen location (file or registry or whatever) be documented -- and documented from a Windows perspective as well, so you don't have to guess what HOME means in this context. One potential solution would be to use something like os.path.expanduser(~/.python), where os.path.expanduser has a defined behaviour on Windows (one that could do with a little clarification, yes I know, doc patch welcomed...), but also add an additional option, that os.path.expanduser will first look in the registry for the value HKLM\Software\Python\PythonCore\HOME and use that if present. Then users could set their own interpretation, in a Windows-standard manner. If that would be an acceptable option, I could supply a patch to os.path.expanduser. I will do a clarifying doc patch regardless. Paul. PS We could also support ~user by looking in HKEY_USERS\user SID\Software\Python\... but that's probably YAGNI :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Thu, Aug 12, 2010 at 6:18 AM, Steve Holden st...@holdenweb.com wrote: Didn't we have this discussion when per-user libraries came up? Shouldn't we be using a subdirectory of that location? We ruin the risk of Python becoming distributed so finely it becomes impossible to change things, what with per-user libraries, per-version shared binaries, per-user-per-version library configuration files and the rest. Yes, we did. That was in the context of some people's desire for a per-user site-packages directory, and the result is that we're now saddled with a per-user site-packages directory. The structure determined there was the same sort of half-way version-specific mess as so many others are: libraries are per-python-version, and scripts are installed cowboy-style (whoever got there last, wins). Perhaps user configuration belongs in ~/.local/, or ~/.local/python/ (with attendant Windows Mac OS noises); I don't really care where it lands, because right now we just have a mess. Getting it right with respect to Window's roaming notion and how people expect to work with it is... unlikely. Picking a place is better than not, so we know where to find things. But that's all it buys us. -Fred -- Fred L. Drake, Jr. fdrake at gmail.com A storm broke loose in my mind. --Albert Einstein ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove unit test needed
On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou solip...@pitrou.net wrote: Hello, I would like to see “unit test needed” removed from the workflow menu in the bug tracker. The reason is that we don't do test-driven development (or, at least, most of us don't) and this stage entry is therefore useless and confusing. Saying to someone that an unit test is needed happens during the patch review - it isn't a separate stage in itself. Is that stage supposed to (at least partly) capture the idea 'reproducible test-case needed', or 'verification needed'? That would seem like a more useful notion. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On Thu, Aug 12, 2010 at 05:38:52PM +0900, David Cournapeau wrote: On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden stu...@molden.no wrote: David Cournapeau: Autotools only help for posix-like platforms. They are certainly a big hindrance on windows platform in general, That is why mingw has MSYS. I know of MSYS, but it is not very pleasant to use, if only because it is extremely slow. When I need to build things for windows, I much prefer cross compiling to using MSYS. I also think that cross compilation is more useful than native mingw build alone - there are patches for cross compilation, but I don't know their current status, cheers, David My argument goes that one of the biggest differences between the GNU/Linux and the Windows way of computing is the barrier between user and programmer. In the Windows way, you are either a user or a programmer. On Linux, just by the way you can download software and run ./configure make make install, you are encouraged to look at the source code and by this you might in the not-so-long run start reporting bugs to mailing lists and see that there are actually people who might be able to sort out the bugs and that you might become one of them. The Windows way, you think those bugs are unavoidable and start making jokes out of a feeling of frustration and helplessness. That's where msys/mingw is supposed to come in, if only it was easier to install, so that new Programmers don't get locked in in the Microsoft compiler products and thereby the divide between the software communities gets wider and wider. Don't get me wrong, I think the python project is doing a great job in terms of cross-platform portability, but things would be easier if there was an easy combination of msys, mingw and autotools. And by the way, I think the way the big linux distros like fedora and mandrake distribute software is more similar to the windows way of computing. Gabriel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove unit test needed
On Thu, Aug 12, 2010 at 9:18 AM, Mark Dickinson dicki...@gmail.com wrote: On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou solip...@pitrou.net wrote: .. I would like to see “unit test needed” removed from the workflow menu in the bug tracker. .. Is that stage supposed to (at least partly) capture the idea 'reproducible test-case needed', or 'verification needed'? That would seem like a more useful notion. +1 I have two problems with “unit test needed”: 1. Similar to Antoine, I find it ambiguous whether a bug without a patch is in “unit test needed” or patch needed stage. 2. I much prefer a small script reproducing the bug to a regression suite patch. In most cases unit tests require too much irrelevant scaffolding to be useful in understanding or debugging the issue. I remember there was an idea somewhere to replace patch tag with a check-list with boxes for code, tests, and docs. I think that would be better than unit test needed stage. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
2010/8/12 li...@gabriel-striewe.de On Thu, Aug 12, 2010 at 05:38:52PM +0900, David Cournapeau wrote: On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden stu...@molden.no wrote: David Cournapeau: Autotools only help for posix-like platforms. They are certainly a big hindrance on windows platform in general, That is why mingw has MSYS. I know of MSYS, but it is not very pleasant to use, if only because it is extremely slow. When I need to build things for windows, I much prefer cross compiling to using MSYS. I also think that cross compilation is more useful than native mingw build alone - there are patches for cross compilation, but I don't know their current status, cheers, David My argument goes that one of the biggest differences between the GNU/Linux and the Windows way of computing is the barrier between user and programmer. In the Windows way, you are either a user or a programmer. On Linux, just by the way you can download software and run ./configure make make install, you are encouraged to look at the source code and by this you might in the not-so-long run start reporting bugs to mailing lists and see that there are actually people who might be able to sort out the bugs and that you might become one of them. The Windows way, you think those bugs are unavoidable and start making jokes out of a feeling of frustration and helplessness. That's where msys/mingw is supposed to come in, if only it was easier to install, so that new Programmers don't get locked in in the Microsoft compiler products and thereby the divide between the software communities gets wider and wider. Don't get me wrong, I think the python project is doing a great job in terms of cross-platform portability, but things would be easier if there was an easy combination of msys, mingw and autotools. And by the way, I think the way the big linux distros like fedora and mandrake distribute software is more similar to the windows way of computing. Gabriel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/cesare.di.mauro%40gmail.com Anyway Visual Studio, even with the Express Edition, is simpler and more productive for a Windows programmer. You must suggest at least an equivalent free alternative to make the switch convenient. Otherwise we are talking about philosophy or religion, and nobody will change his ideas. Cesare ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove unit test needed
On Thu, Aug 12, 2010 at 1:31 PM, Fred Drake fdr...@acm.org wrote: On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: I remember there was an idea somewhere to replace patch tag with a check-list with boxes for code, tests, and docs. I think that would be better than unit test needed stage. Are you suggesting check boxes for what's needed, or for what's present? Please see http://wiki.python.org/moin/DesiredTrackerFeatures . Ezio, thanks for the link. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove unit test needed
On Thu, 12 Aug 2010 11:02:29 -0400 Alexander Belopolsky alexander.belopol...@gmail.com wrote: I remember there was an idea somewhere to replace patch tag with a check-list with boxes for code, tests, and docs. I think that would be better than unit test needed stage. To me the simpler the better. If there's a patch then it's the reviewer's task to point out what's missing - and that's context-dependent: some fixes don't need a doc change or a test case (or, at least, they can do without). The rationale is that the more complex a system is, the less likely we are to use it. Our current keywords are severely under-used. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 08:26, Tarek Ziadé wrote: [snip...] Choosing an arbitrary location we think is good on every system is fine and non risky I think, as long as Python let the various distribution change those paths though configuration. In fact, that's one of the future goal of the sysconfig module I had in mind. Instead of having it reading paths from python variables, I would like to introduce a configuration file global to Python containing all the installation paths, and the paths we are currently discussing. That file could then be changed by distributions depending on their layouts. Yes - this sounds good. +1 It also provides a single place for users who are unhappy with the defaults that we choose. Michael It will avoid distributions to hack Python to change those paths. For instance, Ubuntu currently patches distutils to change the installation paths. So let's: - define all the default locations for each system - define a sysconfig.cfg file that contains all installation paths, for each target system - change sysconfig.py so it uses it, instead of the global dicts it currently has Regards Tarek -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove unit test needed
On 12/08/2010 12:56, Antoine Pitrou wrote: Hello, I would like to see “unit test needed” removed from the workflow menu in the bug tracker. The reason is that we don't do test-driven development (or, at least, most of us don't) and this stage entry is therefore useless and confusing. Saying to someone that an unit test is needed happens during the patch review - it isn't a separate stage in itself. The reason I'm asking is that I've seen some triagers bumping a lot of issues to “unit test needed” lately, and I find this annoying. What we need is patches, not unit tests per se. I often see patches without a test, and have assumed this is what this stage is for - where a patch is provided without a corresponding test. On the other hand checkboxes for fix / test / docs sounds fine. Michael Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
2010/8/12 Éric Araujo mer...@netwok.org: Choosing an arbitrary location we think is good on every system is fine and non risky I think, as long as Python let the various distribution change those paths though configuration. Don’t you have a bootstrapping problem? How do you know where to look at the sysconfig file that tells where to look at config files? Personally, I'm not clear on what a separate syconfig.cfg file offers over clearly separating the directory configuration settings and continuing to have distributions patch sysconfig.py directly. The bootstrapping problem (which would encourage classifying synconfig.cfg as source code and placing it alongside syscongig.py) is a major part of that point of view. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
My argument goes that one of the biggest differences between the GNU/Linux and the Windows way of computing is the barrier between user and programmer. In the Windows way, you are either a user or a programmer. Such arguments are off-topic for python-dev; please use one of the Linux advocacy forums. A little bit on-topic, I think that Python actually helps to lower the barrier between users and programmers on Windows. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Aug 12, 2010, at 6:30 AM, Tim Golden wrote: I don't care how many stats we're doing You might not, but I certainly do. And I can guarantee you that the authors of command-line tools that have to start up in under ten seconds, for example 'bzr', care too. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Thu, 12 Aug 2010 18:14:44 -0400 Glyph Lefkowitz gl...@twistedmatrix.com wrote: On Aug 12, 2010, at 6:30 AM, Tim Golden wrote: I don't care how many stats we're doing You might not, but I certainly do. And I can guarantee you that the authors of command-line tools that have to start up in under ten seconds, for example 'bzr', care too. The idea that import time is dominated by stat() calls sounds rather undemonstrated (and unlikely) to me. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.2 alpha 1
... Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * an overhauled GIL implementation that reduces contention * many consistency and behavior fixes for numeric operations * countless fixes regarding string/unicode issues; among them full support for a bytes environment (filenames, environment variables) * a sysconfig module to access configuration information * a pure-Python implementation of the datetime module * additions to the shutil module, among them archive file support * improvements to pdb, the Python debugger Hey, Python 3(.2) becomes more sexy than Python 2(.7)! -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
Cesare Di Mauro wrote: You must suggest at least an equivalent free alternative to make the switch convenient. Otherwise we are talking about philosophy or religion, and nobody will change his ideas. I think the point is that *because* people don't want to change their ideas, it would be good to have a mingw-based alternative. Otherwise everyone is forced to convert to the Windows religion. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On 13/08/2010 00:44, Greg Ewing wrote: Cesare Di Mauro wrote: You must suggest at least an equivalent free alternative to make the switch convenient. Otherwise we are talking about philosophy or religion, and nobody will change his ideas. I think the point is that *because* people don't want to change their ideas, it would be good to have a mingw-based alternative. Otherwise everyone is forced to convert to the Windows religion. You mean people using Windows are forced to use Windows? Michael -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Thu, 12 Aug 2010 08:18:27 pm Steve Holden wrote: One might make a case that all configuration data should be stored in a single SQLite database (with a suitable API to hide the relational nature of the store). -1 Please don't even *consider* such a thing. Haven't we learned from Firefox? I for one am getting heartily sick and tired of having to fix (that is, throw away) corrupted Firefox databases. Please don't go down that path. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Fri, Aug 13, 2010 at 07:48:22AM +1000, Nick Coghlan wrote:
2010/8/12 Éric Araujo mer...@netwok.org:
Choosing an arbitrary location we think is good on every system is fine
and non risky I think, as long as Python let the various distribution
change those paths though configuration.
Don’t you have a bootstrapping problem? How do you know where to look at
the sysconfig file that tells where to look at config files?
I'd hardcode a list of locations.
[os.path.join(os.path.dirname(__file__), 'sysconfig.cfg'),
os.path.join('/etc', 'sysconfig.cfg')]
The distributor has a limited choice of options on where to look.
A good alternative would be to make the config file overridable. That way
you can have sysconfig.cfg next to sysconfig.py or in a known config
directory relative to the python stdlib install but also let the
distributions and individual sites override the defaults by making changes
to /etc/python3/sysconfig.cfg for instance.
Personally, I'm not clear on what a separate syconfig.cfg file offers
over clearly separating the directory configuration settings and
continuing to have distributions patch sysconfig.py directly. The
bootstrapping problem (which would encourage classifying synconfig.cfg
as source code and placing it alongside syscongig.py) is a major part
of that point of view.
Here's some advantages but some of them are of dubious worth:
* Allows users/site-administrators to change paths and not have packaging
systems overwrite the changes.
* Makes it conceptually cleaner to make this overridable via user defined
config files since it's now a matter of parsing several config files
instead of having a hardcoded value in the file and overridable values
outside of it.
* Allows sites to add additional paths to the config file.
* Makes it clear to distributions that the values in the config file are
available for making changes to rather than having to look for it in code
and not know the difference between thaat or say, the encoding parameter
in python2.
* Documents the format to use for overriding the paths if individual sites
can override the defaults that are shipped in the system version of
python.
-Toshio
pgpBEZ2XsDBy9.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
A good alternative would be to make the config file overridable. That way you can have sysconfig.cfg next to sysconfig.py or in a known config directory relative to the python stdlib install but also let the distributions and individual sites override the defaults by making changes to /etc/python3/sysconfig.cfg for instance. Putting configuration files next to source code does not agree with the FHS. Your message gave me an idea though: Some function could be called in sitecustomize (symlinked from /etc on Debian e.g.) to set the path to sysconfig.cfg. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Fri, Aug 13, 2010 at 7:29 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 12 Aug 2010 18:14:44 -0400 Glyph Lefkowitz gl...@twistedmatrix.com wrote: On Aug 12, 2010, at 6:30 AM, Tim Golden wrote: I don't care how many stats we're doing You might not, but I certainly do. And I can guarantee you that the authors of command-line tools that have to start up in under ten seconds, for example 'bzr', care too. The idea that import time is dominated by stat() calls sounds rather undemonstrated (and unlikely) to me. It may be, depending on what you import. I certainly have seen (and profiled) it. In my experience, stat calls and regex compilation often come at the top of the culprits for slow imports. In the case of setuptools namespace package, there was a thread on 23rd april on distutils-sig about this issue: most of the slowdown came from unneeded stat (and symlink translations). cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
Michael Foord writes: I think the point is that *because* people don't want to change their ideas, it would be good to have a mingw-based alternative. Otherwise everyone is forced to convert to the Windows religion. You mean people using Windows are forced to use Windows? By far not all, but some are. Like me, I only use Windows when my boss holds up a pink paper and says shall I sign this? So far I haven't felt a need to build Python on Windows, but if I did I would strongly prefer to use a familiar (to me) build system based on the autotools and GCC. Because I haven't felt that need, I don't think MSYS/mingw support is a big deal. But apparently there are a few people whose Windows use case is characterized both by platform coercion and a desire to build Python themselves. The question is who will support those folks? I don't see any reason why you or Martin should support MSYS/mingw if you don't want to, but please don't put down the folks who ask for it. Just say no, it's not worth it. Or maybe, if you want to do the work, I might contribute some reviews. Or whatever. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
Michael Foord writes: How is ~/python not memorable or consistent? (And cross-platform memorability and consistency is valuable too.) But what does ~ mean on Windows? Inside of Python you can have a consistent definition, but that doesn't help people whose installer gets mixed signals so Python itself is in the wrong place, or who are using external tools (uninstaller, editor, application, etc) that work on or with Python. I'm not arguing for use of AppData, but at least it's easy to explain, and easy to implement, for consistency. Another issue is discoverability. Many users won't know about these config files unless they *see* them. OK, maybe AppData's out. In fact for Windows the *correct* thing to do is probably to use the registry and then provide a graphical tool for editing the values. If you're arguing for consistency why not argue for this? Sounds reasonable to me. Except Python's standard GUI is probably not up to Windows standards of beauty ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
