Re: [Python-Dev] First draft of "sysconfig"
Tarek Ziadé wrote: > == code, status, next steps == > > The code of the module can be viewed here, it's a revamp of > distutils.sysconfig: > > http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain > > I've refactored distutils/ and site.py so they work with this new > module, and added deprecation warnings in distutils.sysconfig. I think we really need to do something about these kinds of deprecations. IMHO, there is no need to deprecate an entry point if the code has just moved to some other location in the stdlib. A simple note in the documentation and the NEWS file should be enough to get programmers to use the new location for code that doesn't have to work with older Python versions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 14 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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
[Python-Dev] Pronouncement on PEP 389: argparse?
So there wasn't really any more feedback on the last post of the argparse PEP other than a typo fix and another +1. http://www.python.org/dev/peps/pep-0389/ Can I get a pronouncement? Here's a summary of the responses. (Please correct me if I misinterpreted anyone.) * Floris Bruynooghe +1 * Brett Cannon +1 * Nick Coghlan +1 * Michael Foord +1 * Yuval Greenfield +1 * Doug Hellmann +1 * Kevin Jacobs +1 * Paul Moore +1 * Jesse Noller +1 * Fernando Perez +1 * Jon Ribbens +1 * Vinay Sajip +1 * Barry Warsaw +1 * Antoine Pitrou -0 * Martin v. Löwis -0 * M.-A. Lemburg -1 Note that I've interpreted those who were opposed to the deprecation of getopt as -0 since the PEP no longer proposes that, only the deprecation of optparse. (People who opposed optparse's deprecation are still -1.) If there's any other information that would be helpful for a pronouncement, please let me know. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] First draft of "sysconfig"
Tarek wrote: > == Installation schemes == > > First, the module contains the installation schemes for each platform > CPython uses. > An install scheme is a mapping where the key is the "code" name for a > directory, and > the value the path of that directory, with some $variable that can be > expanded. > > Install schemes are stored in a private mapping, where the keys are > usually the value of os.name, > and the value, the mapping I've mentionned earlier. > > So, for example, the paths for win32 are: > > _INSTALL_SCHEMES = { > ... > 'nt': { > 'stdlib': '$base/Lib', > 'platstdlib': '$base/Lib', > 'purelib': '$base/Lib/site-packages', > 'platlib': '$base/Lib/site-packages', > 'include': '$base/include', > 'platinclude': '$base/include', > 'scripts': '$base/Scripts', > 'data' : '$base', > }, > ... > } Not mentioned here are the user schemes. Looking at the code it seems that _getuserbase is adding "Python" to the path on nt. Isn't that redundant? The paths in _INSTALL_SCHEMES already include "Python". Also w/ user dirs in general - I think there should be some implementation specific portion of the path as well. Right now I think IronPython and CPython will end up with the same user paths for the same versions which could cause problems if someone releases separate modules for IronPython and CPython for some reason (or if users just want different sets of things installed for different interpreters). > * get_platform(): Return a string that identifies the current > platform. (this one is used by site.py for example) I wonder if this would make more sense a built-in. Ultimately it seems like the interpreter implementation knows best about what aspects of it's underlying platform would require different libraries. With the existing code I think IronPython would return "cli" everywhere (because os.name == 'nt' on Windows but posix on Linux & Mac OS/X but we still don't have uname). I think Jython will return something like java1.6.0_17 because it's os.name is java - which might be more specific than is necessary. Also if the purpose of this is for platform specific build directories it might be interesting to have multiple return values. For example in IronPython the minimal thing we'd want I think is a "cli" directory for .NET assemblies. But there could also be native extensions which are platform specific so we'd want "cli-x86" and "cli-x64" depending upon the platform. Jython might want the same thing as they add ctypes support. ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard wrote: > So there wasn't really any more feedback on the last post of the > argparse PEP other than a typo fix and another +1. I just converted a script over to argparse. It seems nice enough, I was doing a two-level command, and it was quite handy for that. One concern I had is that the naming seems at times trivially different than optparse, just because "opt" or "option" is replaced by "arg" or "argument". So .add_option becomes .add_argument, and OptionParser becomes ArgumentParser. This seems unnecessary to me, and it make converting the application harder than it had to be. It wasn't hard, but it could have been really easy. There are a couple other details like this that I think are worth resolving if argparse really is supposed to replace optparse. I'd change this language: "The optparse module is deprecated, and has been replaced by the argparse module." To: "The optparse module is deprecated and will not be developed further; development will continue with the argparse module" There's a lot of scripts using optparse, and if they are successfully using it there's no reason to stop using it. The proposed language seems to imply it is wrong to keep using optparse, which I don't think is the case. And people can pick up on this kind of language and get all excitable about it. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: > On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard > wrote: >> So there wasn't really any more feedback on the last post of the >> argparse PEP other than a typo fix and another +1. > > I just converted a script over to argparse. It seems nice enough, I > was doing a two-level command, and it was quite handy for that. > > One concern I had is that the naming seems at times trivially > different than optparse, just because "opt" or "option" is replaced by > "arg" or "argument". So .add_option becomes .add_argument, and > OptionParser becomes ArgumentParser. This seems unnecessary to me, > and it make converting the application harder than it had to be. It > wasn't hard, but it could have been really easy. There are a couple > other details like this that I think are worth resolving if argparse > really is supposed to replace optparse. Thanks for the feedback. Could you comment further on exactly what would be sufficient? It would be easy, for example, to add a subclass of ArgumentParser called OptionParser that has an add_option method. Do you also need the following things to work? * options, args = parser.parse_args() # options and args aren't separate in argparse * type='int', etc. # string type names aren't used in argparse * action='store_false' default value is None # it's True in argparse These latter kind of changes seem sketchier to me - they would make the initial conversion easier, but would make using argparse normally harder. > I'd change this language: > "The optparse module is deprecated, and has been replaced by the > argparse module." > To: > "The optparse module is deprecated and will not be developed further; > development will continue with the argparse module" Done. Thanks! Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 12:43 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: >> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard >> wrote: >>> So there wasn't really any more feedback on the last post of the >>> argparse PEP other than a typo fix and another +1. >> >> I just converted a script over to argparse. It seems nice enough, I >> was doing a two-level command, and it was quite handy for that. >> >> One concern I had is that the naming seems at times trivially >> different than optparse, just because "opt" or "option" is replaced by >> "arg" or "argument". So .add_option becomes .add_argument, and >> OptionParser becomes ArgumentParser. This seems unnecessary to me, >> and it make converting the application harder than it had to be. It >> wasn't hard, but it could have been really easy. There are a couple >> other details like this that I think are worth resolving if argparse >> really is supposed to replace optparse. > > Thanks for the feedback. Could you comment further on exactly what > would be sufficient? It would be easy, for example, to add a subclass > of ArgumentParser called OptionParser that has an add_option method. > Do you also need the following things to work? Well, to argue against myself: having another class like OptionParser also feels like backward compatibility cruft. argparse is close enough to optparse (which is good) that I just wish it was a bit closer. > * options, args = parser.parse_args() # options and args aren't > separate in argparse This is a substantive enough difference that I don't really mind it, though if OptionParser really was a different class then maybe parse_args should act the same as optparse.OptionParser. What happens if you have positional arguments, but haven't declared any such arguments with .add_argument? Does it just result in an error? I suppose it must. > * type='int', etc. # string type names aren't used in argparse This seems simple to support and unambiguous, so yeah. > * action='store_false' default value is None # it's True in argparse I don't personally care about this; I agree the None default in optparse is sometimes peculiar (also for action='count' and action='append', where 0 and [] are the sensible defaults). Also I'd like %prog and %default supported, which should be fairly simple; heck, you could just do something like usage.replace('%prog', '%(prog)s') before substitution. Since %prog isn't otherwise valid (unless it was %%prog, which seems unlikely?) this seems easy. Ideally I really wish ArgumentParser was just named OptionParser, and that .add_argument was .add_option, and that argparse's current parse_args was named something different, so both the optparse parse_args (which returns (options, args)) and argparse's different parse_args return value could coexist. Also generally if the common small bits of optparse (like type='int' and %prog) just worked, even if they weren't really extensible in the same manner as optparse. Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question for argparse, but just generally I think that doing things the same way as optparse should be preferred when at all reasonable. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ 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] Pronouncement on PEP 389: argparse?
On 14/12/2009 19:04, Ian Bicking wrote: [snip...] Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question for argparse, but just generally I think that doing things the same way as optparse should be preferred when at all reasonable. I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example). All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 1:43 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: >> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard >> wrote: >>> So there wasn't really any more feedback on the last post of the >>> argparse PEP other than a typo fix and another +1. >> >> I just converted a script over to argparse. It seems nice enough, I >> was doing a two-level command, and it was quite handy for that. >> >> One concern I had is that the naming seems at times trivially >> different than optparse, just because "opt" or "option" is replaced by >> "arg" or "argument". So .add_option becomes .add_argument, and >> OptionParser becomes ArgumentParser. This seems unnecessary to me, >> and it make converting the application harder than it had to be. It >> wasn't hard, but it could have been really easy. There are a couple >> other details like this that I think are worth resolving if argparse >> really is supposed to replace optparse. > > Thanks for the feedback. Could you comment further on exactly what > would be sufficient? It would be easy, for example, to add a subclass > of ArgumentParser called OptionParser that has an add_option method. > Do you also need the following things to work? > > * options, args = parser.parse_args() # options and args aren't > separate in argparse > * type='int', etc. # string type names aren't used in argparse > * action='store_false' default value is None # it's True in argparse > > These latter kind of changes seem sketchier to me - they would make > the initial conversion easier, but would make using argparse normally > harder. > I thought that one of the following approaches would be considered : - let optparse remain in stdlib (as is or not ...) - re-implement optparse (i.e. a module having the same name ;o) using argparse isn't it ? -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Free jacknife 1.3.4 v2 Download - mac software - http://feedproxy.google.com/~r/TracGViz-full/~3/q0HBIH_50wQ/ ___ 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] Pronouncement on PEP 389: argparse?
2009/12/14 Ian Bicking : > Another thing I just noticed is that argparse using -v for version > where optparse does not (it only adds --version); most of my scripts > that use -v to mean --verbose, causing problems. Oh, me too. -- Cheers, Simon B. ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord wrote: > On 14/12/2009 19:04, Ian Bicking wrote: >> >> [snip...] >> Another thing I just noticed is that argparse using -v for version >> where optparse does not (it only adds --version); most of my scripts >> that use -v to mean --verbose, causing problems. Since this is a poll >> question on the argparse site I assume this is an outstanding question >> for argparse, but just generally I think that doing things the same >> way as optparse should be preferred when at all reasonable. >> > > I also use -v for verbose in a few scripts (including options to unittest > when run with python -m). I've seen -V as a common abbreviation for > --version (I've just used this with Mono for example). > Many Unix commands accept these switches too . AFAICR there was an standard (well ...) set of command line options for Unix systems (can't find a link :-/ ) .. [1] Command-Line Options (http://www.faqs.org/docs/artu/ch10s05.html) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Automated init. - http://bitbucket.org/osimons/trac-rpc-mq/changeset/e122336d1eb2/ ___ 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] Pronouncement on PEP 389: argparse?
Michael Foord voidspace.org.uk> writes: > > I also use -v for verbose in a few scripts (including options to > unittest when run with python -m). I've seen -V as a common abbreviation > for --version (I've just used this with Mono for example). +1 for letting -v mean "--verbose". This is a really common wish. ___ 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
[Python-Dev] Request commit privileges for Stefan Krah
I'd like to request that Stefan Krah be granted commit privileges to the Python svn repository, for the sole purpose of working on a (yet to be created) py3k-decimal-in-c branch. Stefan has produced a C library 'libmpdec' implementing (fast!) arbitrary precision decimal arithmetic, together with a Python extension module 'Cdecimal' that provides full compatibility with Python's decimal module. The current version of the code can be found at: http://www.bytereef.org/libmpdec-download.html It's currently licensed under the GNU Affero General Public License, but Stefan has indicated that he's willing to relicense it to the PSF under a contributor agreement. We'd like to start work on a branch that integrates Stefan's work into the Python source tree, with the hope that this work could be considered for inclusion in py3k when it's completed. While I haven't yet done anything resembling a thorough code review of Stefan's code, the code I have looked at has seemed very high quality, and gives me a high degree of confidence in its correctness. Stefan's also done a truly ridiculous amount of correctness and compatibility testing of this code, and in the process discovered several corner case bugs in Python's decimal module. (I'm not yet asking for a decision on *whether* the decimal module should be replaced with a C version; that decision should be easier to make once Stefan's code is fully integrated into the branch, and we have some timings and benchmarks to show the performance benefit. There are also various other questions about a C version of decimal that will eventually need to addressed, but I don't want to distract from the main point of this message.) 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] Pronouncement on PEP 389: argparse?
On 12/14/2009 1:43 PM, Steven Bethard wrote: On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard wrote: So there wasn't really any more feedback on the last post of the argparse PEP other than a typo fix and another +1. I just converted a script over to argparse. It seems nice enough, I was doing a two-level command, and it was quite handy for that. One concern I had is that the naming seems at times trivially different than optparse, just because "opt" or "option" is replaced by "arg" or "argument". So .add_option becomes .add_argument, and OptionParser becomes ArgumentParser. This seems unnecessary to me, and it make converting the application harder than it had to be. It wasn't hard, but it could have been really easy. There are a couple other details like this that I think are worth resolving if argparse really is supposed to replace optparse. Thanks for the feedback. Could you comment further on exactly what would be sufficient? It would be easy, for example, to add a subclass of ArgumentParser called OptionParser that has an add_option method. Do you also need the following things to work? [snip] I have not ever used optparse. So if I were to use argparse in the future, I would strongly prefer that it be free of back-compatibility cruft. Would it be possible to use the 2to3 machinery to write an opt_to_arg conversion tool? This could easily take care of the naming differences. Terry Jan Reedy ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang wrote: > On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord >> On 14/12/2009 19:04, Ian Bicking wrote: >>> Another thing I just noticed is that argparse using -v for version >>> where optparse does not (it only adds --version); most of my scripts >>> that use -v to mean --verbose, causing problems. Since this is a poll >>> question on the argparse site I assume this is an outstanding question >> >> I also use -v for verbose in a few scripts (including options to unittest >> when run with python -m). I've seen -V as a common abbreviation for >> --version (I've just used this with Mono for example). > > Many Unix commands accept these switches too . AFAICR there was an > standard (well ...) set of command line options for Unix systems > (can't find a link :-/ ) Just to be clear, argparse doesn't force you to use -v/--version. That's just the default if you specify the version= argument to the ArgumentParser constructor. You can configure version flags much more flexibly using add_argument(..., action='version'). But yes, it's a poll right now on the argparse website (http://code.google.com/p/argparse/) and if you feel strongly about it, please add your vote there (rather than here). Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang wrote: > I thought that one of the following approaches would be considered : > > - let optparse remain in stdlib (as is or not ...) > - re-implement optparse (i.e. a module having the same name ;o) using > argparse > > isn't it ? Please read the PEP if you haven't, particularly the "Why isn't the functionality just being added to optparse?" section. I don't believe it is sensible to re-implement all of optparse. What Ian Bicking is proposing, I believe, is simpler -- adding a few aliases here and there so that you don't have to rename so many things when you're upgrading from optparse to argparse. For what it's worth, I'm still not sure it's a good idea, for exactly the reason Ian points out - "having another class like OptionParser also feels like backward compatibility cruft". Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] Request commit privileges for Stefan Krah
[Mark Dickinson] > I'd like to request that Stefan Krah be granted commit privileges to the > Python > svn repository, for the sole purpose of working on a (yet to be created) > py3k-decimal-in-c branch. +1. I haven't commented on any of this, but I've watched it, and Stefan appears easy enough to work with and does very high-quality work. > ... > (I'm not yet asking for a decision on *whether* the decimal module should > be replaced with a C version; that decision should be easier to make once > Stefan's code is fully integrated into the branch, and we have some timings > and benchmarks to show the performance benefit. There are also various > other questions about a C version of decimal that will eventually need to > addressed, but I don't want to distract from the main point of this message.) Me neither, which is why I repeated that part ;-) A development branch is exactly the right thing to do at this point, and Stefan needs commit privs to work on that. ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 3:00 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang wrote: >> I thought that one of the following approaches would be considered : >> >> - let optparse remain in stdlib (as is or not ...) >> - re-implement optparse (i.e. a module having the same name ;o) using >> argparse >> >> isn't it ? > > Please read the PEP if you haven't, particularly the "Why isn't the > functionality just being added to optparse?" section. I don't believe > it is sensible to re-implement all of optparse. What Ian Bicking is > proposing, I believe, is simpler -- adding a few aliases here and > there so that you don't have to rename so many things when you're > upgrading from optparse to argparse. > Well, I was actually thinking about adding such aliases in that module and leave argparse just like it is today (and make the aliases as compatible with optparse as possible ;o). So probably we're talking about very similar things that will be placed in different places in stdlib . > For what it's worth, I'm still not sure it's a good idea, ... at least that way changes to have optparse-like interface will be in a separate module. Or otherwise implement optparse like shown below {{{ #!python from argparse.optparse import * }}} and do the rest in argparse (it's the same anyway ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Initial version of protocol-provider patch. Patch does not currently apply cleanly - it hasn'... - http://bitbucket.org/osimons/trac-rpc-mq/changeset/b302540a1608/ ___ 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] Pronouncement on PEP 389: argparse?
Antoine Pitrou wrote: > Michael Foord voidspace.org.uk> writes: >> I also use -v for verbose in a few scripts (including options to >> unittest when run with python -m). I've seen -V as a common abbreviation >> for --version (I've just used this with Mono for example). > > +1 for letting -v mean "--verbose". This is a really common wish. Agreed, all my scripts do that. -V is the short form I expect for --version. 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] Request commit privileges for Stefan Krah
Hello, Mark Dickinson gmail.com> writes: > > I'd like to request that Stefan Krah be granted commit privileges to the > Python > svn repository, for the sole purpose of working on a (yet to be created) > py3k-decimal-in-c branch. Regardless of whether the commit rights are granted (I am not against it), isn't it sufficient to clone one of the Mercurial branches at http://code.python.org/hg and maintain a public py3k-decimal-in-c branch somewhere (e.g. bitbucket)? Or would hosting the branch in the SVN give it the required visibility? 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] Pronouncement on PEP 389: argparse?
Steven Bethard gmail.com> writes: > > Please read the PEP if you haven't, particularly the "Why isn't the > functionality just being added to optparse?" section. I don't believe > it is sensible to re-implement all of optparse. What Ian Bicking is > proposing, I believe, is simpler -- adding a few aliases here and > there so that you don't have to rename so many things when you're > upgrading from optparse to argparse. Although I am of the people who think working modules shouldn't be deprecated, I also don't think adding compatibility aliases is a good idea. They only make the APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of any unnecessary baggage. 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] Pronouncement on PEP 389: argparse?
Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang wrote: >> I thought that one of the following approaches would be considered : >> >> - let optparse remain in stdlib (as is or not ...) >> - re-implement optparse (i.e. a module having the same name ;o) using >>argparse >> >> isn't it ? > > Please read the PEP if you haven't, particularly the "Why isn't the > functionality just being added to optparse?" section. I don't believe > it is sensible to re-implement all of optparse. What Ian Bicking is > proposing, I believe, is simpler -- adding a few aliases here and > there so that you don't have to rename so many things when you're > upgrading from optparse to argparse. > > For what it's worth, I'm still not sure it's a good idea, for exactly > the reason Ian points out - "having another class like OptionParser > also feels like backward compatibility cruft". People also need to remember the very conservative deprecation path for optparse proposed in the PEP - never deprecated in 2.x, and only a PendingDeprecationWarning in 3.x up until 3.4 (likely to happen some time in 2013). With that kind of slow deprecation path, adding further backwards compatibility cruft to argparse itself seems redundant - the name changes from option to argument were instituted for a reason (since the scope of argparse really is wider than that of optparse). 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] Splitting something into two steps produces different behavior from doing it in one fell swoop in Python 2.6.2
On Fri, Dec 11, 2009 at 7:59 PM, Nick Coghlan wrote: > It follows the standard left-to-right evaluation order within an expression: > > () > > (i.e. a function call always determines which function is going to be > called before determining any arguments to be passed) > > Splitting it into two lines then clearly changes the evaluation order: > > temp = > (temp) > > I'm not sure what behaviour could be suggested as being more intuitive - > the problem in this case arose due to both referencing and mutating the > same object in a single statement, which is always going to be > problematic from an ordering point of view, since it depends on subtle > details of statement definitions that people often won't know. Better to > split the mutation and the reference into separate statements so the > intended order is clear regardless of how well the reader knows the > subtleties of Python's evaluation order. > > Cheers, > Nick. > Thanks for the explanation, Nick. I understand what is happening now. y[1].update resolves to the update() method of the old set referenced by y[1], but this set is then popped so that the update() manages to change the old set, but not the new one that is returned by any subsequent reference to y[1]. I suppose I will have to keep this in two statements. A similar thing happened with the SWIG extensions for GDAL, in which one had to separate statements so that SWIG objects were not destroyed prematurely, i.e. no more one-liners. ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan wrote: > Steven Bethard wrote: >> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang wrote: >>> I thought that one of the following approaches would be considered : >>> >>> 1 - let optparse remain in stdlib (as is or not ...) >>> 2 - re-implement optparse (i.e. a module having the same name ;o) using >>> argparse >>> >>> isn't it ? >> >> Please read the PEP if you haven't, particularly the "Why isn't the >> functionality just being added to optparse?" section. I don't believe >> it is sensible to re-implement all of optparse. >> [...] >> >> For what it's worth, I'm still not sure it's a good idea, for exactly >> the reason Ian points out - "having another class like OptionParser >> also feels like backward compatibility cruft". > > People also need to remember the very conservative deprecation path for > optparse proposed in the PEP - never deprecated in 2.x, So, I don't get it . What's the difference between this and the first option I mentioned above ? I am probably missing the obvious but if optparse will be «never deprecated in 2.x» then what's gonna happen ? The only options I see are mentioned above (and I thought it was the first one ;o) : - If (1) is the right one then -0 for considering backwards compatibility - If (2) is the right one then IMO, +1 for adding «further backwards compatibility cruft» in a separate module and remove it in Python 3.5 -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Looking for a technique to create flexible, graphical dashboards ... - http://feedproxy.google.com/~r/TracGViz-full/~3/r7Zcyrg1n3U/019aa74e7095d047 ___ 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] Request commit privileges for Stefan Krah
On Mon, Dec 14, 2009 at 8:20 PM, Antoine Pitrou wrote: > Mark Dickinson gmail.com> writes: >> I'd like to request that Stefan Krah be granted commit privileges to the >> Python >> svn repository, for the sole purpose of working on a (yet to be created) >> py3k-decimal-in-c branch. > > Regardless of whether the commit rights are granted (I am not against it), > isn't > it sufficient to clone one of the Mercurial branches at > http://code.python.org/hg and maintain a public py3k-decimal-in-c branch > somewhere (e.g. bitbucket)? Sure; I guess that would work too, especially if there's a preference for hg over svn. It might be nice to have the commit history in the official repository, though. 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
[Python-Dev] Microsoft contributor agreement received?
I'm not sure the best place to verify this so I'm starting here. I'm told we finally faxed in our contributor agreement (to the number listed at http://www.python.org/psf/contrib/) about a week and a half ago. I'd just like to make sure that someone has received it. Is anyone here able to confirm that it went through fine? ___ 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] First draft of "sysconfig"
On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg wrote: [..] >> I've refactored distutils/ and site.py so they work with this new >> module, and added deprecation warnings in distutils.sysconfig. > > I think we really need to do something about these kinds of > deprecations. > > IMHO, there is no need to deprecate an entry point if the code > has just moved to some other location in the stdlib. > > A simple note in the documentation and the NEWS file should be > enough to get programmers to use the new location for code that > doesn't have to work with older Python versions. There are both cases in fact: some APIs have just moved, and some have changed. So I guess I could keep a deprecation warning only for the latter. Regards Tarek ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang wrote: > On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan wrote: >>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang wrote: I thought that one of the following approaches would be considered : 1 - let optparse remain in stdlib (as is or not ...) 2 - re-implement optparse (i.e. a module having the same name ;o) using argparse >> >> People also need to remember the very conservative deprecation path for >> optparse proposed in the PEP - never deprecated in 2.x, > > So, I don't get it . What's the difference between this and the first > option I mentioned above ? I am probably missing the obvious but if > optparse will be «never deprecated in 2.x» then what's gonna happen ? > The only options I see are mentioned above (and I thought it was the > first one ;o) : > > - If (1) is the right one then -0 for considering backwards compatibility > - If (2) is the right one then IMO, +1 for adding «further backwards > compatibility cruft» in a separate module and remove it in Python 3.5 If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the "Deprecation of optparse" section of the PEP: http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] Pronouncement on PEP 389: argparse?
Ian Bicking writes: > Ideally I really wish ArgumentParser was just named OptionParser, and > that .add_argument was .add_option, and that argparse's current > parse_args was named something different, so both the optparse > parse_args (which returns (options, args)) and argparse's different > parse_args return value could coexist. -1 for pretending that “option” and “argument” mean the same thing. They really don't (the former is a strict subset of the latter), and it would be confusing legacy cruft if argparse had names that imply it. The names chosen in the argparse library are good. > if OptionParser really was a different class then maybe parse_args > should act the same as optparse.OptionParser. +1 for “optparse API and external behaviour re-implemented as an ‘optparse’ module using argparse as the underlying implementation”, to allow exactly the sort of ease of transition you're describing. Of course, that +1 is only support for “someone else does the work”. I don't need optparse to remain if I have argparse in the standard library. +0 for deprecating optparse. -- \“… it's best to confuse only one issue at a time.” —Brian W. | `\Kernighan and Dennis M. Ritchie, _The C programming language_, | _o__) 1988 | Ben Finney ___ 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] First draft of "sysconfig"
2009/12/14 Dino Viehland : [..] > Not mentioned here are the user schemes. Looking at the code it seems that > _getuserbase is adding "Python" to the path on nt. Isn't that redundant? > The paths in _INSTALL_SCHEMES already include "Python". > Right that's a small bug in the refactoring (there's an extra /) but there will be a bit of redundancy on "Python", at the end nevertheless: The base directory in win32 for the user scheme in is : APPDATA *or* ~/Python (under linux it's ~/.local) then various subdirectories are added in that directory, and some of them starts with "PythonXY", like: ~/Python/Python26/.. See http://www.python.org/dev/peps/pep-0370/#specification > Also w/ user dirs in general - I think there should be some implementation > specific portion of the path as well. Right now I think IronPython and > CPython will end up with the same user paths for the same versions which > could cause problems if someone releases separate modules for IronPython > and CPython for some reason (or if users just want different sets of > things installed for different interpreters). Yes that's one point someone raised (can't recall who) and the idea was to have a separate top directory for user dirs, that would start with the name of the implementation: so for Windows: ~/Python/Python26/.. ~/IronPython/../ ~/Jython/../ and for Linux and al, I am not sure but maybe a prefix for Jython/etc.. could be used for all paths. ~/.locale/lib/python/2.6/site-packages/... ~/.locale/jython/lib/python/2.6/site-packages/... (I didn't digg on how Jython organizes things yet, any hint would be appreciated) > >> * get_platform(): Return a string that identifies the current >> platform. (this one is used by site.py for example) > > I wonder if this would make more sense a built-in. Ultimately it seems > like the interpreter implementation knows best about what aspects of > it's underlying platform would require different libraries. > > With the existing code I think IronPython would return "cli" everywhere > (because os.name == 'nt' on Windows but posix on Linux & Mac OS/X but > we still don't have uname). I think Jython will return something like > java1.6.0_17 because it's os.name is java - which might be more specific > than is necessary. Ok so it sounds like it would be easier to cook that value in a built-in in each implementation, > > Also if the purpose of this is for platform specific build directories > it might be interesting to have multiple return values. For example in > IronPython the minimal thing we'd want I think is a "cli" directory for > .NET assemblies. But there could also be native extensions which are > platform specific so we'd want "cli-x86" and "cli-x64" depending upon > the platform. Jython might want the same thing as they add ctypes > support. So like, having an architecture marker, that defaults to the current ? get_platform(architecture=platform.architecture) 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] First draft of "sysconfig"
Dino Viehland microsoft.com> writes: > > > * get_platform(): Return a string that identifies the current > > platform. (this one is used by site.py for example) > > I wonder if this would make more sense a built-in. Ultimately it seems > like the interpreter implementation knows best about what aspects of > it's underlying platform would require different libraries. I don't think it makes sense to make a builtin of such a little used, non-performance critical API. If we want to factor out all implementation-specific things, we could add a module dedicated to that (e.g. "_interpreter") and have other modules (os, platform, sysconfig...) draw from that. 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] First draft of "sysconfig"
Tarek wrote: > > (I didn't digg on how Jython organizes things yet, any hint would be > appreciated) The installation directory looks like it's organized just like CPython but I have no clue how user directories would/should be arranged. > > > > > Also if the purpose of this is for platform specific build directories > > it might be interesting to have multiple return values. For example in > > IronPython the minimal thing we'd want I think is a "cli" directory for > > .NET assemblies. But there could also be native extensions which are > > platform specific so we'd want "cli-x86" and "cli-x64" depending upon > > the platform. Jython might want the same thing as they add ctypes > > support. > > So like, having an architecture marker, that defaults to the current ? > >get_platform(architecture=platform.architecture) > How would you know what other architectures would be valid to pass in here? Returning a list would let the implementation say that it knows a certain set of architectural binaries are valid. ___ 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] First draft of "sysconfig"
Antoine wrote: > Dino Viehland microsoft.com> writes: > > > > > * get_platform(): Return a string that identifies the current > > > platform. (this one is used by site.py for example) > > > > I wonder if this would make more sense a built-in. Ultimately it seems > > like the interpreter implementation knows best about what aspects of > > it's underlying platform would require different libraries. > > I don't think it makes sense to make a builtin of such a little used, > non-performance critical API. > If we want to factor out all implementation-specific things, we could add a > module dedicated to that (e.g. "_interpreter") and have other modules (os, > platform, sysconfig...) draw from that. Putting this in an _interpreter module is fine with me (or even putting it somewhere in sys works - e.g. there was a sys.implementation discussion not too long ago). The important thing is that the interpreter implementation really is the one that understands what binaries they would be compatible with it regardless of how often it gets used and how it performs. If it's not a built-in then I think we'd be in a world where either every implementation needs to patch this file in their distribution or contribute a change back to support their implementation and that just seems ugly. And it's already a very large function even w/o IronPython, Jython, PyPy and Unladen Swallow support. ___ 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] Pronouncement on PEP 389: argparse?
On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote: > Michael Foord voidspace.org.uk> writes: >> >> I also use -v for verbose in a few scripts (including options to >> unittest when run with python -m). I've seen -V as a common abbreviation >> for --version (I've just used this with Mono for example). > > +1 for letting -v mean "--verbose". This is a really common wish. +1, -v == --verbose S ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 12:35, Antoine Pitrou wrote: > Steven Bethard gmail.com> writes: > > > > Please read the PEP if you haven't, particularly the "Why isn't the > > functionality just being added to optparse?" section. I don't believe > > it is sensible to re-implement all of optparse. What Ian Bicking is > > proposing, I believe, is simpler -- adding a few aliases here and > > there so that you don't have to rename so many things when you're > > upgrading from optparse to argparse. > > Although I am of the people who think working modules shouldn't be > deprecated, I > also don't think adding compatibility aliases is a good idea. They only > make the > APIs more bloated and maintenance more tedious. Let's keep the new APIs > clean of > any unnecessary baggage. > Ditto from me. If people want a compatible module it can be made available on PyPI for those who want it. -Brett ___ 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] Microsoft contributor agreement received?
2009/12/14 Dino Viehland : > I’m not sure the best place to verify this so I’m starting here. p...@python.org is better. -- Regards, Benjamin ___ 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] Pronouncement on PEP 389: argparse?
On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang wrote: >> On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord >>> On 14/12/2009 19:04, Ian Bicking wrote: Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question >>> >>> I also use -v for verbose in a few scripts (including options to unittest >>> when run with python -m). I've seen -V as a common abbreviation for >>> --version (I've just used this with Mono for example). >> >> Many Unix commands accept these switches too . AFAICR there was an >> standard (well ...) set of command line options for Unix systems >> (can't find a link :-/ ) How about this one: http://www.shelldorado.com/goodcoding/cmdargs.html#flagnames S ___ 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] Pronouncement on PEP 389: argparse?
On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote: > But yes, it's a poll right now on the argparse website > (http://code.google.com/p/argparse/) and if you feel strongly about > it, please add your vote there (rather than here). I don't even understand what the poll question is asking. S ___ 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
[Python-Dev] Issue 3745 backwards incompatibility
In testing some existing code with the 2.7 alpha release, I've run into: TypeError: Unicode-objects must be encoded before hashing when the existing code tries to pass unicode objects to hashlib.sha1 and hashlib.md5. This is, I believe, due to changes made for issue 3745: http://bugs.python.org/issue3745 The issue states the need to reject unencoded strings based on the fact that one backend implementation (openssl) refused to accept them while another (_sha256) assumed a utf-8 encoding. The thing is, I cannot observe any such difference using Python 2.5 or 2.6. Instead of what is shown in the ticket (which was done on a Python 3, I believe) I see, when I adjust the demo test to use Python 2 syntax for "unencoded strings": Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import _hashlib >>> _hashlib.openssl_sha256(u"\xff") Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in position 0: ordinal not in range(128) >>> import _sha256 >>> _sha256.sha256(u'\xff') Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in position 0: ordinal not in range(128) >>> (Sample from Windows because that's the only place I can get import _sha256 to work. The Ubuntu Linux I tried behaves the same way as above for the _hashlib version, while it doesn't appear to have _sha256 as an option.) So from what I can see the behavior wasn't inconsistent from backend-to-backend in Python 2 but rather fell in line with what I'm familiar with: if you pass unicode to some code that only wants bytes, the unicode object will get encoded to a bytestring using the system default encoding. No problems if the data can in fact always be encoded using that encoding, the error above if the data can't be encoded. Changing these functions to now require the caller to do the encoding explicitly ahead of time strikes me as introducing an inconsistency. Plus it introduces a backwards incompatibility in Python 2.7. Is this really necessary? Karen ___ 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] Pronouncement on PEP 389: argparse?
On Dec 14, 2009, at 3:35 PM, Antoine Pitrou wrote: > Steven Bethard gmail.com> writes: >> >> Please read the PEP if you haven't, particularly the "Why isn't the >> functionality just being added to optparse?" section. I don't believe >> it is sensible to re-implement all of optparse. What Ian Bicking is >> proposing, I believe, is simpler -- adding a few aliases here and >> there so that you don't have to rename so many things when you're >> upgrading from optparse to argparse. > > Although I am of the people who think working modules shouldn't be > deprecated, I > also don't think adding compatibility aliases is a good idea. They only make > the > APIs more bloated and maintenance more tedious. Let's keep the new APIs clean > of > any unnecessary baggage. Agreed. If you want to make an "adapter" to do things like convert 'int' to int, then call the new API then fine, but don't start crufting up a new API to make it 'easier' to convert. All crufting it up does is make it _less_ clear how to use the new API by bring along things that don't belong in it. S ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 6:34 PM, sstein...@gmail.com wrote: >> Although I am of the people who think working modules shouldn't be >> deprecated, I >> also don't think adding compatibility aliases is a good idea. They only make >> the >> APIs more bloated and maintenance more tedious. Let's keep the new APIs >> clean of >> any unnecessary baggage. > > Agreed. If you want to make an "adapter" to do things like convert 'int' to > int, then call the new API then fine, but don't start crufting up a new API > to make it 'easier' to convert. > > All crufting it up does is make it _less_ clear how to use the new API by > bring along things that don't belong in it. The "new" API is almost exactly like the old optparse API. It's not like it's some shining jewel of perfection that would be tainted by somehow being similar to optparse when it's almost exactly like optparse already. If it wasn't like optparse, then fine, whatever; but it *is* like optparse, so these differences feel unnecessary. Converting 'int' to int internally in argparse is hardly difficult or unclear. If argparse doesn't do this, then I think at least it should give good error messages for all cases where these optparse-isms remain. For instance, now if you include %prog in your usage you get: ValueError: unsupported format character 'p' (0x70) at index 1 -- that's simply a bad error message. Giving a proper error message takes about as much code as making %prog work. I don't feel strongly that one is better than the other, but at least one of those should be done. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 4:16 PM, sstein...@gmail.com wrote: > > On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote: > >> Michael Foord voidspace.org.uk> writes: >>> >>> I also use -v for verbose in a few scripts (including options to >>> unittest when run with python -m). I've seen -V as a common abbreviation >>> for --version (I've just used this with Mono for example). >> >> +1 for letting -v mean "--verbose". This is a really common wish. > > +1, -v == --verbose Because people are continuing this discussion, I'll say again that argparse already supports this: >>> parser = argparse.ArgumentParser() >>> parser.add_argument('-v', '--verbose', action='store_true') >>> parser.parse_args(['-v']) Namespace(verbose=True) If you want to also have a -V/--version argument, you can do that too: >>> parser.add_argument('-V', '--version', action='version', version='3.5') >>> parser.parse_args(['-V']) 3.5 And now back to our regularly scheduled discussion of actual PEP issues. ;-) Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] Microsoft contributor agreement received?
On Mon, Dec 14, 2009 at 16:21, Benjamin Peterson wrote: > 2009/12/14 Dino Viehland : > > I’m not sure the best place to verify this so I’m starting here. > > p...@python.org is better. > > The board has confirmed with Dino that we got the agreement. -Brett > > -- > Regards, > Benjamin > ___ > 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/brett%40python.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] First draft of "sysconfig"
Hi Tarek, Is there anything in this proposal for windows developers ? Just that I can't see anything that would help us... For me, the terminology isn't anything a windows developer could really understand. It presumes that the developer understands the python implementation. A developer might not understand all those details and might not be interested to learn. I accept that the terminology is good on linux.. but it's near meaningless on windows - for me - anyway. David On Sat, 12 Dec 2009 21:02:13 +0100, Tarek Ziadé wrote: > Hello, > > A while ago I've proposed to refactor the APIs that provides access to > the installation paths and configuration variables at runtime into a > single module called "sysconfig", and make it easier for all > implementations to work with them. > > I've started a branch and worked on it, and I'd like to ask here for > some feedback. And in particular from Jython and IronPython people > because they would probably need to work in that file for their > implementation and/or propose things to add. My understanding is that > we have people like Phillip (Jenvey), Michael F., Frank W. in this > list so they can comment directly and I don't need to cross-post this > mail elsewhere. > > == Installation schemes == > > First, the module contains the installation schemes for each platform > CPython uses. > An install scheme is a mapping where the key is the "code" name for a > directory, and > the value the path of that directory, with some $variable that can be > expanded. > > Install schemes are stored in a private mapping, where the keys are > usually the value of os.name, > and the value, the mapping I've mentionned earlier. > > So, for example, the paths for win32 are: > > _INSTALL_SCHEMES = { > ... > 'nt': { > 'stdlib': '$base/Lib', > 'platstdlib': '$base/Lib', > 'purelib': '$base/Lib/site-packages', > 'platlib': '$base/Lib/site-packages', > 'include': '$base/include', > 'platinclude': '$base/include', > 'scripts': '$base/Scripts', > 'data' : '$base', > }, > ... > } > > where each key corresponds to a directory that contains some Python files: > > - stdlib : root of the standard library > - platstdlib: root of platform-specific elements of the standard library > - purelib: the site-packages directory for pure python modules > - platlib: the site-packages directory for platform-specific modules > - include: the include dir > - platinclude: the include dir for platform-specific files > - scripts: the directory where scripts are added > - data: the directory where data file are added > > All these directory are read and used by: > - distutils when a package is installed, so the install command can > dispatch files in the right place > - site.py, when Python is initialized > > IOW, any part of the stdlib can use these paths to locate and work > with Python files. > > The public APIs are: > > * get_path_names() : returns a list of the path names ("stdlib", > "platstdlib", etc.) > > * get_paths(scheme, vars) : Returns a mapping containing an install > scheme. >- "scheme" is the name of the scheme, if not provided will get the > default scheme of the current platform >- vars is an optonal mapping that can provide values for the > various $variables. Notice that they all have > default values, for example $base == sys.prefix. > > for example: get_paths('nt') > > * get_path(name, scheme, vars): Returns one path corresponding to the > scheme. > > for example : get_paths('stdlib', 'nt') > > Those API are generic, but maybe we could add specific APIs like: > > * get_stdlib_path('nt') > > These API are basically a refactoring of what already exist in > distutils/command/install.py > > == Configuration variables == > > distutils.sysconfig currently provides some APIs to read values from > files like Makefile and pyconfig.h. > > These API have been placed in the global sysconfig module: > > * get_config_vars(): return a dictionary of all configuration > variables relevant for the current platform. > > * get_config_var(name): Return the value of a single variable > > * get_platform(): Return a string that identifies the current > platform. (this one is used by site.py for example) > > * get_python_version() : return the short python version > (sys.version[:3]) -- this one could probably go away but is useful > because that's the marker used by Python in some paths. > > == code, status, next steps == > > The code of the module can be viewed here, it's a revamp of > distutils.sysconfig: > > http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain > > I've refactored distutils/ and site.py so they work with this new > module, and added deprecation warnings in distutils.sysconfig. > > All tests pass in the branch, but note that the code is still using > the .h and Makefile files. This will probably be rem
Re: [Python-Dev] First draft of "sysconfig"
On 15/12/2009 2:07 PM, David Lyon wrote: Hi Tarek, Is there anything in this proposal for windows developers ? Just that I can't see anything that would help us... So I understand - help doing what? For me, the terminology isn't anything a windows developer could really understand. It presumes that the developer understands the python implementation. A developer might not understand all those details and might not be interested to learn. That seems true for all operating systems, not just Windows. The vast majority of Python programmers will probably never need to use this feature, but those who do will need to understand enough of the python implementation to make sense of the values returned regardless of the OS. I accept that the terminology is good on linux.. but it's near meaningless on windows - for me - anyway. I think it is fine. If you are really looking for properties specific to the operating system (eg, the location of the start menu, desktop, appdata folders etc) I don't think they belong in this PEP; they are a property of the OS install/version, not of the specific Python install/version. Cheers, 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] First draft of "sysconfig"
On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond wrote: > I think it is fine. If you are really looking for properties specific > to the operating system (eg, the location of the start menu, desktop, > appdata folders etc) But under windows, an application developer might (as in probably would) like to install an application in \Program Files\someapp rather than hidden in the bowels of the python interpretor. They might like their data in "Application Data", which is where support people get trained to look for application data. Not down in \pythonX.Y\ ... > I don't think they belong in this PEP; they are a > property of the OS install/version, not of the specific Python > install/version. Yes - exactly. My point. The operating system says that programs should be installed into "Program Files" and data into "Application Data". Why can not python respect the operating system directions for well behaved apps? 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] First draft of "sysconfig"
On Mon, 14 Dec 2009 23:58:08 +0100, Tarek Ziadé wrote: > Yes that's one point someone raised (can't recall who) and the idea was to > have a separate top directory for user dirs, that would start with the name > of the implementation: > > so for Windows: > > ~/Python/Python26/.. > ~/IronPython/../ > ~/Jython/../ I follow your reasoning. But application developers (and traditional windows developers) have an upside-down view of that. They might think that python is just the language interpreter, and that it should just stay 'out-of-the-way'. For example, mercurial and many python based apps include the python as a sub-app to their own. Just neccessary to run the application. That is the way it is for commercial windows apps. We want the python interpretor installed, and then we want our apps (that we get paid money for) to sit at the top. Not the other way round, sitting beneath the language interpreter. This is pretty much the way it has been for windows for close on 15 years now. Regards 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] First draft of "sysconfig"
On 15/12/2009 2:42 PM, David Lyon wrote: On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond wrote: I think it is fine. If you are really looking for properties specific to the operating system (eg, the location of the start menu, desktop, appdata folders etc) But under windows, an application developer might (as in probably would) like to install an application in \Program Files\someapp rather than hidden in the bowels of the python interpretor. I agree - but in that case you are talking about an application built with Python - that is a different set of requirements. But regardless of where Python itself lives the returned values will be correct; they will not reflect the operating system preference for various other folders, but will correctly return the paths they are documented as returning. IOW, this isn't designed for applications which happen to be written in Python. There might be a case for such a module to be created, but this PEP doesn't attempt to solve that particular problem. They might like their data in "Application Data", which is where support people get trained to look for application data. Not down in \pythonX.Y\ ... Nothing is stopping them from doing that - but this PEP isn't intended to provide that information. I don't think they belong in this PEP; they are a property of the OS install/version, not of the specific Python install/version. Yes - exactly. My point. The operating system says that programs should be installed into "Program Files" and data into "Application Data". Why can not python respect the operating system directions for well behaved apps? It does - many applications written in Python exist which do exactly that. If a user really wants to install Python itself under "\Program Files", sysconfig should correctly reflect that. Python doesn't care where it is installed, or even when it is (sensibly) bundled with an app which is designed to be "stand-alone". You are after operating system properties - I understand your need to know those paths (and there are already reasonable Windows specific ways to get them), but sysconfig isn't trying to solve that for you and I agree it should not attempt to. 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] First draft of "sysconfig"
David Lyon writes: > On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond > wrote: > > > I think it is fine. If you are really looking for properties > > specific to the operating system (eg, the location of the start > > menu, desktop, appdata folders etc) > > But under windows, an application developer might (as in probably > would) like to install an application in \Program Files\someapp rather > than hidden in the bowels of the python interpretor. > > They might like their data in "Application Data", which is where > support people get trained to look for application data. Not down in > \pythonX.Y\ ... Similarly, GNU operating system distributions usually have documentation separate from programs, separate from configuration files, separate from static data, separate from mutable data. > > I don't think they belong in this PEP; they are a property of the OS > > install/version, not of the specific Python install/version. I think the “sysconfig” specification should allow for *extension*, without needing a modified specification each time a new distinct location is requested. That is, those developers and packagers who don't need a gamut of system locations can stick to a minimal set, while those who need many can use them, and those who need many can extend the set compatibly. -- \ “If you make people think they're thinking, they'll love you; | `\ but if you really make them think, they'll hate you.” —Donald | _o__) Robert Perry Marquis | Ben Finney ___ 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] First draft of "sysconfig"
On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond wrote: >> But under windows, an application developer might (as in probably >> would) like to install an application in \Program Files\someapp >> rather than hidden in the bowels of the python interpretor. > > I agree - but in that case you are talking about an application built > with Python - that is a different set of requirements. Building an application with python.. that's right. Of course. Why not? > IOW, this isn't designed for applications which happen to be written in > Python. There might be a case for such a module to be created, but this > PEP doesn't attempt to solve that particular problem. But programmers might want to write an application with python. It doesn't seem like such an edge-case thing to do. >> They might like their data in "Application Data", which is where >> support people get trained to look for application data. Not down >> in \pythonX.Y\ ... > > Nothing is stopping them from doing that - but this PEP isn't intended > to provide that information. Distutils is stopping them. > It does - many applications written in Python exist which do exactly > that. Yes. And they don't use any of the built in facilities, under windows. > If a user really wants to install Python itself under "\Program > Files", sysconfig should correctly reflect that. Python doesn't care > where it is installed, or even when it is (sensibly) bundled with an app > which is designed to be "stand-alone". No debate about that. > You are after operating system properties - I understand your need to > know those paths (and there are already reasonable Windows specific ways > to get them), but sysconfig isn't trying to solve that for you and I > agree it should not attempt to. So under windows, then, what is it trying to solve? Thats what I am asking. 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] First draft of "sysconfig"
On 15/12/2009 3:09 PM, David Lyon wrote: On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond wrote: But under windows, an application developer might (as in probably would) like to install an application in \Program Files\someapp rather than hidden in the bowels of the python interpretor. I agree - but in that case you are talking about an application built with Python - that is a different set of requirements. Building an application with python.. that's right. Of course. Why not? I'm missing your point - many applications exist written in Python. IOW, this isn't designed for applications which happen to be written in Python. There might be a case for such a module to be created, but this PEP doesn't attempt to solve that particular problem. But programmers might want to write an application with python. It doesn't seem like such an edge-case thing to do. They can, and they have. So again your point is lost on me. They might like their data in "Application Data", which is where support people get trained to look for application data. Not down in \pythonX.Y\ ... Nothing is stopping them from doing that - but this PEP isn't intended to provide that information. Distutils is stopping them. I don't agree with that and I can present many applications as evidence. You yourself mentioned mercurial and it looks for mercurial.ini in the user's appdata directory. Regardless, this discussion isn't about distutils. It does - many applications written in Python exist which do exactly that. Yes. And they don't use any of the built in facilities, under windows. To continue the mercurial example - mercurial will not use sysconfig to determine where to look for mercurial.ini on *any* operating system. sysconfig is not about solving that particular problem. So under windows, then, what is it trying to solve? Thats what I am asking. The same thing it is trying to solve for non-Windows users - various threads here have articulated this well. You needn't feel bad about not having such use-cases yourself - that simply means sysconfig isn't targetted at you - it isn't targetted at application developers on any operating system. Cheers, 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] First draft of "sysconfig"
On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond wrote: But under windows, an application developer might (as in probably would) like to install an application in \Program Files\someapp rather than hidden in the bowels of the python interpretor. > ... > I'm missing your point The point is that if somebody writes an application in C, they will generally speaking not want (under say linux) for that application to live in the C compiler directory. Same goes for many other languages. The point is not controversial in other languages. And it shouldn't be here either. >> Distutils is stopping them. > > I don't agree with that and I can present many applications as evidence. Please do - if you wish. > You yourself mentioned mercurial and it looks for mercurial.ini in the > user's appdata directory. Sure. There's growing support within the python interpretor for things like that. But Mercurial uses an external installer. Like NSIS, to overcome the deficiencies that I am pointing out. > .. it isn't targetted at application developers on any operating system. I see. I get it now. Thanks. 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