Re: [Python-Dev] Request commit privileges for Stefan Krah
Mark Dickinson wrote: > 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. Using an SVN branch also means the checkins can be reviewed as they go by on python-checkins. I'll at least keep a casual eye on this branch if that happens, but I wouldn't go out of my way to follow it on a hg branch. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] 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 11:39:02PM -0500, David Lyon wrote: > 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. If I write a shared library under C I am expected to install it under one of the default locations if I don't want to require people to have to tweak things before they can use it. I see no difference with python modules or packages. Any private modules or packages used by an application built using python don't have to be on the sys.path by default (in fact I would encourage them not to be). > >> Distutils is stopping them. Distutils isn't perfect but solves the need of installing public modules and packages quite well. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ Python-Dev mailing list [email protected] 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: > > Because people are continuing this discussion, I'll say again that > argparse already supports this: Well I think the point is that if there is a default, the default should be sensible and not run against expectations. It would probably be fine not to have a default at all, too. Regards Antoine. ___ Python-Dev mailing list [email protected] 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, Dec 15, 2009 at 1:00 AM, Dino Viehland wrote: [..] > 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. How would you use it when a list is returned ? Can you provide a few examples where the code wants to know the default architecture for the current platform ? etc. Tarek ___ Python-Dev mailing list [email protected] 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, Dec 15, 2009 at 5:12 AM, Ben Finney wrote: [..] > >> > 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. That's part of the idea, get_path() is a generic API that would allow any implementation to add extra paths if needed. The keys I have provided are the existing keys we have in distutils and some extra keys that removes all the custo code that was building paths using os.path.join here and there in the stdlib. Now I didn't add an API to allow dynamic insertion of new paths because I don't see a use case for that : if a packager wants to work with an extra path, she can work at the project level by providing custom distutils commands to do the job. Unless you have another use case in mind ? Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 3745 backwards incompatibility
Karen Tracey wrote: > 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": I think this was a misunderstanding during the issue 3745 processing: the patch should not have been backported to trunk at all. For Python 3.x, the change was correct. For 2.x, a -3 warning would have been a better fit. Note that the non-OpenSSL SHA et al. modules have never defaulted to encoding to UTF-8 in Python 2.x. Python 2.x uses ASCII as default encoding. Only Python 3.x uses UTF-8 as default encoding. I've added a note to the issue and reopened it. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 15 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 3745 backwards incompatibility
On 15/12/2009 11:23, M.-A. Lemburg wrote: Karen Tracey wrote: 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": I think this was a misunderstanding during the issue 3745 processing: the patch should not have been backported to trunk at all. For Python 3.x, the change was correct. For 2.x, a -3 warning would have been a better fit. Note that the non-OpenSSL SHA et al. modules have never defaulted to encoding to UTF-8 in Python 2.x. Python 2.x uses ASCII as default encoding. Only Python 3.x uses UTF-8 as default encoding. Doesn't Python 3 use the *platform* encoding as the default (which happens to be UTF-8 on sensible systems but is something truly horrible like CP1250 on Windows)? (So *assuming* a default encoding of UTF-8 is still incorrect on Python 3 if we are being consistent with other IO behaviour.) All the best, Michael I've added a note to the issue and reopened it. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 3745 backwards incompatibility
Michael Foord wrote: > On 15/12/2009 11:23, M.-A. Lemburg wrote: >> Karen Tracey wrote: >> >>> 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": >>> >> I think this was a misunderstanding during the issue 3745 processing: >> the patch should not have been backported to trunk at all. >> >> For Python 3.x, the change was correct. For 2.x, a -3 warning >> would have been a better fit. >> >> Note that the non-OpenSSL SHA et al. modules have never defaulted to >> encoding to UTF-8 in Python 2.x. Python 2.x uses ASCII as default >> encoding. Only Python 3.x uses UTF-8 as default encoding. >> > > Doesn't Python 3 use the *platform* encoding as the default (which > happens to be UTF-8 on sensible systems but is something truly horrible > like CP1250 on Windows)? (So *assuming* a default encoding of UTF-8 is > still incorrect on Python 3 if we are being consistent with other IO > behaviour.) Internally, it uses UTF-8 as default encoding, ie. when implicitly converting unicode to bytes, e.g. as a result of using "s#" parser markers. Externally, Python tries to find the right encoding(s) for the given platform and then uses these in the IO layer (e.g. sys.stdin.encoding) and for OS interfacing (sys.getfilesystemencoding()). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 15 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 [email protected] 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 wrote: > On Mon, Dec 14, 2009 at 6:34 PM, [email protected] > 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. > > I agree (and I've used both for quite a long time). argparse has an api that is almost compatible with optparse in many common cases, but just renamed some things. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Command line options for features in stdlib WAS: Pronouncement on PEP 389: argparse?
/me starting a new thread because this goes beyond argparse itself
On Tue, Dec 15, 2009 at 4:34 AM, Antoine Pitrou wrote:
> Steven Bethard gmail.com> writes:
>>
>> Because people are continuing this discussion, I'll say again that
>> argparse already supports this:
>
> Well I think the point is that if there is a default, the default should be
> sensible and not run against expectations.
+1
> It would probably be fine not to have a default at all, too.
-1
I really think that it's good to expect the same (similar) behavior
when the same options is accepted by multiple commands. In the end
that's a decision of the people implementing the concrete command line
tool, but it is nice to rely on something like : «if you forgot, or
don't remember or don't know about it then the std decision is
performed»
Now that you mention all this , I follow up with a comment that is
more about -v switch . Most of the time I realize that command line
apps have logging capabilities and should also allow different
verbosity levels (e.g. -q, -s, -v, --noisy) . The good thing is that
this always can be done the same way (i.e. using log levels defined in
logging module ) . The not so good news is that (in practice) coders
have to do it over and over every time they create a new command line
app, and users might need to remember those switches if the author
used different names . My suggestion is that it would be nice to
identify std switches and add support for configuring the cmd-line
parser and logger instance OOTB
{{{
#!python
import argparse
import logging
if __name__ == ’__main__’:
# create the parser
parser = argparse.ArgumentParser(description=’XXX’)
# add the arguments
...
# add args for verbosity level
logging.add_args(parser)
# parse the command line
args = parser.parse_args()
# configure logging --
# probably omitted if an option handles this
logging.fileConfig(*cfg_args)
# setup the logger instance
logging.argparseConfig(getLogger('xxx'), args)
}}}
The same reasoning could probably be extended to other modules in
stdlib (e.g. default encoding, testing, ...). It's probably a good
idea to define a set of (std) command line args for std features
(preferently without conflicting with existing standards ;o) and
provide shortcuts to ease configuration process when building command
line tools
PS: This thread might also be related to the previous one about
logging configuration using dicts
--
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
[email protected]
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 Tue, Dec 15, 2009 at 4:33 AM, Neal Becker wrote: > Ian Bicking wrote: >> 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. > > I agree (and I've used both for quite a long time). argparse has an api > that is almost compatible with optparse in many common cases, but just > renamed some things. I can definitely improve some of the error messages for people coming from optparse. I've created an issue for this, with the ``type='int'`` and "%prog" problems in there: http://code.google.com/p/argparse/issues/detail?id=51 If you have other things that you know you'd like better exceptions for, please add to that issue and I'll take care of it. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ Python-Dev mailing list [email protected] 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: > How would you use it when a list is returned ? Can you provide a few > examples where > the code wants to know the default architecture for the current platform ? > etc. The consumer could enumerate over it and then do whatever they were doing w/ the platform multiple times. If an earlier one succeeds at what they're attempting to do then they're done. If there's no "success", lets say they're appending something to sys.path, then they'd do it for all elements in the sequence. It's not an absolute requirement or anything like that - it just jumped out at me because IronPython and Jython do have multiple platforms which could be relevant at one time. ___ Python-Dev mailing list [email protected] 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 Ziadé wrote: > 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. Sounds like a plan. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 15 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 [email protected] 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 09:32:55 +, Floris Bruynooghe wrote: > If I write a shared library under C I am expected to install it under > one of the default locations if I don't want to require people to have > to tweak things before they can use it. I see no difference with > python modules or packages. Any private modules or packages used by > an application built using python don't have to be on the sys.path by > default (in fact I would encourage them not to be). Hi Floris. Well Mark Hammond summed up for me - I'm satisfied with his answer. You're talking about modules and packages and I agree with you. I guess I was asking about was extending the set to of things that could easily be dealt with by python from just modules/packages to modules/packages + applications. What do I mean by an application?, well it's one or two steps up from the simple as 'helloworld.py'. There's lots of machines in the company, and lots of different apps. Not unlike a scientific area where there is lots of specialised equipment and each machine has slightly different requirements as to its function. Installing python is painless. That's all good. Installing all the python-packages has a learning curve and isn't very streamlined. In the end, it can be made to work. Installing the application (helloworld.py for the want of a better name), well, there isn't much in python to help there. I was thinking that perphaps sysconfig could help me get my helloworld.py application into a \Program Files\hello world directory and everything would be rosy. But not yet. So I will wait. > Distutils isn't perfect but solves the need of installing public > modules and packages quite well. If you say so - but compared to what ? CPAN? :-) Have a nice day David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
