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
On Mon, Dec 14, 2009 at 11:39:02PM -0500, David Lyon wrote:
On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond
mhamm...@skippinet.com.au
wrote:
But under windows, an application developer might (as in probably
would) like to install an application in \Program Files\someapp
rather than
Steven Bethard steven.bethard at 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
On Tue, Dec 15, 2009 at 1:00 AM, Dino Viehland di...@microsoft.com 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
On Tue, Dec 15, 2009 at 5:12 AM, Ben Finney ben+pyt...@benfinney.id.au 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
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
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
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
Ian Bicking wrote:
On Mon, Dec 14, 2009 at 6:34 PM, sstein...@gmail.com
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
/me starting a new thread because this goes beyond argparse itself
On Tue, Dec 15, 2009 at 4:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
Steven Bethard steven.bethard at gmail.com writes:
Because people are continuing this discussion, I'll say again that
argparse already supports this:
On Tue, Dec 15, 2009 at 4:33 AM, Neal Becker ndbeck...@gmail.com 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:
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
Tarek Ziadé wrote:
On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg m...@egenix.com 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
On Tue, 15 Dec 2009 09:32:55 +, Floris Bruynooghe
floris.bruynoo...@gmail.com 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
14 matches
Mail list logo
