Re: [Python-Dev] First draft of "sysconfig"

2009-12-14 Thread M.-A. Lemburg
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?

2009-12-14 Thread Steven Bethard
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"

2009-12-14 Thread Dino Viehland
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?

2009-12-14 Thread Ian Bicking
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?

2009-12-14 Thread Steven Bethard
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?

2009-12-14 Thread Ian Bicking
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?

2009-12-14 Thread Michael Foord

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?

2009-12-14 Thread Olemis Lang
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 Thread Simon Brunning
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?

2009-12-14 Thread Olemis Lang
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?

2009-12-14 Thread Antoine Pitrou
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

2009-12-14 Thread 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.

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?

2009-12-14 Thread Terry Reedy

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?

2009-12-14 Thread Steven Bethard
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?

2009-12-14 Thread Steven Bethard
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

2009-12-14 Thread Tim Peters
[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?

2009-12-14 Thread Olemis Lang
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?

2009-12-14 Thread Nick Coghlan
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

2009-12-14 Thread Antoine Pitrou

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?

2009-12-14 Thread Antoine Pitrou
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?

2009-12-14 Thread Nick Coghlan
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

2009-12-14 Thread Roy Hyunjin Han
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?

2009-12-14 Thread Olemis Lang
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

2009-12-14 Thread Mark Dickinson
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?

2009-12-14 Thread Dino Viehland
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"

2009-12-14 Thread Tarek Ziadé
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?

2009-12-14 Thread Steven Bethard
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?

2009-12-14 Thread Ben Finney
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 Thread Tarek Ziadé
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"

2009-12-14 Thread Antoine Pitrou
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"

2009-12-14 Thread Dino Viehland
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"

2009-12-14 Thread Dino Viehland
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?

2009-12-14 Thread sstein...@gmail.com

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?

2009-12-14 Thread Brett Cannon
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 Thread Benjamin Peterson
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?

2009-12-14 Thread sstein...@gmail.com

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?

2009-12-14 Thread sstein...@gmail.com

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

2009-12-14 Thread Karen Tracey
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?

2009-12-14 Thread sstein...@gmail.com

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?

2009-12-14 Thread Ian Bicking
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?

2009-12-14 Thread Steven Bethard
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?

2009-12-14 Thread Brett Cannon
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"

2009-12-14 Thread David Lyon

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"

2009-12-14 Thread Mark Hammond

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"

2009-12-14 Thread David Lyon
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"

2009-12-14 Thread David Lyon
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"

2009-12-14 Thread Mark Hammond

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"

2009-12-14 Thread Ben Finney
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"

2009-12-14 Thread David Lyon
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"

2009-12-14 Thread Mark Hammond

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"

2009-12-14 Thread David Lyon
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