date:20100221

Re: [Python-Dev] some notes from the first part of the lang summit

2010-02-21 Thread Eric Smith


Steven Bethard wrote:

On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon  wrote:

My notes from the session I led:

+ argparse

   - Same issues brought up.


For those of us not at PyCon, what were the issues?


I think they were all related to deprecation of optparse, not anything 
to do with argparse itself. I don't recall any specific decision on 
deprecation, but my sense was that optparse will be around for a long, 
long time. There was also a quick discussion on maybe implementing 
optparse using argparse, then getting rid of the existing optparse. 
Maybe you can comment on that.


Eric.
___
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] some notes from the first part of the lang summit

2010-02-21 Thread Guido van Rossum

On Sun, Feb 21, 2010 at 4:30 AM, Eric Smith  wrote:
> Steven Bethard wrote:
>>
>> On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon  wrote:
>>>
>>> My notes from the session I led:
>>>
>>> + argparse
>>>
>>>   - Same issues brought up.
>>
>> For those of us not at PyCon, what were the issues?
>
> I think they were all related to deprecation of optparse, not anything to do
> with argparse itself. I don't recall any specific decision on deprecation,
> but my sense was that optparse will be around for a long, long time. There
> was also a quick discussion on maybe implementing optparse using argparse,
> then getting rid of the existing optparse. Maybe you can comment on that.

Maybe the best thing is to make optparse *silently* deprecated, with a
big hint at the top of its documentation telling new users to use
argparse instead, but otherwise leaving it in indefinitely for the
benefit of the many existing users.

-- 
--Guido van Rossum (python.org/~guido)
___
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] some notes from the first part of the lang summit

2010-02-21 Thread Michael Foord


On 21/02/2010 08:45, Guido van Rossum wrote:

On Sun, Feb 21, 2010 at 4:30 AM, Eric Smith  wrote:
   

Steven Bethard wrote:
 

On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon  wrote:
   

My notes from the session I led:

+ argparse

   - Same issues brought up.
 

For those of us not at PyCon, what were the issues?
   

I think they were all related to deprecation of optparse, not anything to do
with argparse itself. I don't recall any specific decision on deprecation,
but my sense was that optparse will be around for a long, long time. There
was also a quick discussion on maybe implementing optparse using argparse,
then getting rid of the existing optparse. Maybe you can comment on that.
 

Maybe the best thing is to make optparse *silently* deprecated, with a
big hint at the top of its documentation telling new users to use
argparse instead, but otherwise leaving it in indefinitely for the
benefit of the many existing users.

   

+1

argparse is a great step forward but there is no need to disrupt 
existing users - just direct new users to the place they should go.


We've done that with a couple of the commonly used but extraneous 
methods in unittest - deprecation via documentation.


Michael

--
http://www.ironpythoninaction.com/

___
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] some notes from the first part of the lang summit

2010-02-21 Thread skip


Guido> Maybe the best thing is to make optparse *silently* deprecated,
Guido> with a big hint at the top of its documentation telling new users
Guido> to use argparse instead, but otherwise leaving it in indefinitely
Guido> for the benefit of the many existing users.

Would a 2to3 fixer be possible?

S
___
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] some notes from the first part of the lang summit

2010-02-21 Thread Benjamin Peterson

2010/2/21  :
>
>    Guido> Maybe the best thing is to make optparse *silently* deprecated,
>    Guido> with a big hint at the top of its documentation telling new users
>    Guido> to use argparse instead, but otherwise leaving it in indefinitely
>    Guido> for the benefit of the many existing users.
>
> Would a 2to3 fixer be possible?

I don't think so. There would be subtle semantic difference 2to3
couldn't detect.


-- 
Regards,
Benjamin
___
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] Proposal for virtualenv functionality in Python

2010-02-21 Thread Larry Hastings




Ian Bicking wrote:
This is a proto-proposal for including some functionality from 
virtualenv in Python itself.  I'm not entirely confident about what 
I'm proposing, so it's not really PEP-ready, but I wanted to get 
feedback...


First, a bit about how virtualenv works (this will use Linux 
conventions; Windows and some Mac installations are slightly different):


* Let's say you are creating an environment in ~/env/
* /usr/bin/python is *copied* to ~/env/bin/python
* This alone sets sys.prefix to ~/env/ (via existing code in Python)
* At this point things are broken because the standard library is not 
available
* virtualenv creates ~/env/lib/pythonX.Y/site.py, which adds the 
system standard library location (/usr/lib/pythonX.Y) to sys.path
* site.py itself requires several modules to work, and each of these 
modules (from a pre-determined list of modules) is symlinked over from 
the standard library into ~/env/lib/pythonX.Y/

* site.py may or may not add /usr/lib/pythonX.Y/site-packages to sys.path
* *Any* time you use ~/env/bin/python you'll get sys.prefix of ~/env/, 
and the appropriate path.  No environmental variable is required.

* No compiler is used; this is a fairly light tool


I have a tool that also creates a virtualized Python environment, but 
doesn't solve the problem as thoroughly as virtualenv.  I limp along by 
tweaking PYTHONUSERBASE and PYTHONPATH.  I'm very interested in seeing 
something like this make it in to Python.


A few inline comments:


* I'd rather ~/env/bin/python be a symlink instead of copying it.


The thread discussing Windows suggests that we shouldn't use symlinks 
there.  I'd say either copying or symlinking pythonv should be 
supported, and on Windows we recommend copying pythonv.exe.



* Compiling extensions can be tricky because code may not find headers 
(because they are installed in /usr, not ~/env/).  I think this can be 
handled better if virtualenv is slightly less intrusive, or distutils 
is patched, or generally tools are more aware of this layout.


Conversely, headers may be installed in ~/env and not /usr.  The 
compiler should probably look in both places.  But IIUC telling the 
compiler how to do that is only vaguely standardized--Microsoft's CL.EXE 
doesn't seem to support any environment variable containing an include 
/path/.


I suspect solving this in a general way is out-of-band for pythonv, but 
I'm willing to have my mind changed.  Certainly pythonv should add its 
prefix directory to LD_LIBRARY_PATH on Linux.


Additionally, the binary will look for a configuration file.  I'm not 
sure where this file should go; perhaps directly alongside the binary, 
or in some location based on sys.prefix.


The configuration file would be a simple set of assignments; some I 
might imagine:


* Maybe override sys.prefix
* Control if the global site-packages is placed on sys.path
* On some operating systems there are other locations for packages 
installed with the system packager; probably these should be possible 
to enable or disable

* Maybe control installations or point to a file like distutils.cfg


I'm unexcited by this; I think simpler is better.  pythonv should 
virtualize environments layered on top of python, and should have one 
obvious predictable behavior.  Certainly if it supports a configuration 
file pythonv should run without it and pick sensible defaults.


What are the use cases where you need these things to be configurable?


Let me propose further about python and pythonv:

   * As Antoine suggested, the CPython interpreter should sprout a new
 command-line switch, "--prefix", which adds a new prefix directory.
   * pythonv's purpose in life is to infer your prefix directory and
 run "pythonX.X --prefix  [ all args it got ... ]".
   * Should pythonv should be tied to the specific Python executable? 
 If you run install pythonv as "python", should it look for

 "python" or explicitly look for the specific Python it shipped
 with, like "python3.2"?  I suspect the latter though I'm no longer
 sure.


I'm one of those folks who'd like to see this be stackable.  If we tweak 
the semantics just a bit I think it works:


   * pythonv should inspect its --prefix arguments, as well as passing
 them on to the child python process it runs.
   * When pythonv wants to run the next python process in line, it
 scans the path looking for the pythonX.X interpreter but /ignores/
 all the interpreters that are in in a --prefix bin directory it's
 already seen.
   * python handles multiple --prefix options, and later ones take
 precedence over earlier ones.
   * What should sys.interpreter be?  Explicit is better than implicit:
 the first pythonv to run also adds a --interpreter  to
 the front of the command-line.  Or they could all add it and
 python only uses the last one.  This is one area where "python" vs
 "python3.2" makes things a little complicated.


I'm at PyCon and would be in

[Python-Dev] lib3to2 in the 3.2 standard library?

2010-02-21 Thread Joe Amenta

Hey folks,

I'm going to write a PEP for inclusion of lib3to2 in the standard library
for 3.2 and above.  Before do, though, do people have any quick thoughts
about it?

My inclination is to get it stabilized beforehand (perhaps during another
GSoC) by fleshing out the fixer that warns about backwards-incompatible
features in Python 3 and by finishing up the fix_imports2 fixer, probably
involving a rewrite.

http://bitbucket.org/amentajo/lib3to2 is where the source is hosted (there's
a separate branch for 3.1)
http://www.startcodon.com/wordpress/?cat=8 is where I blog about it.
http://pypi.python.org/pypi/3to2 is the PyPI page that has both of those
links.

--Joe Amenta
___
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] lib3to2 in the 3.2 standard library?

2010-02-21 Thread Guido van Rossum

What would be the advantage of having it in the stdlib? It would put a
stop on further development once it's been released as such, which
strike me as a bad idea for a heuristic tool like 3to2. I would expect
that you will continue to add more rules (and more exceptions) to it
for the foreseeable future. You'll probably want to continue to
maintain it as a 3rd party library so you can release those rules
easily. Sounds like a bad idea to put it also in the stdlib, since you
can't effectively update the stdlib version.

--Guido

On Sun, Feb 21, 2010 at 1:00 PM, Joe Amenta  wrote:
> Hey folks,
> I'm going to write a PEP for inclusion of lib3to2 in the standard library
> for 3.2 and above.  Before do, though, do people have any quick thoughts
> about it?
> My inclination is to get it stabilized beforehand (perhaps during another
> GSoC) by fleshing out the fixer that warns about backwards-incompatible
> features in Python 3 and by finishing up the fix_imports2 fixer, probably
> involving a rewrite.
> http://bitbucket.org/amentajo/lib3to2 is where the source is hosted (there's
> a separate branch for 3.1)
> http://www.startcodon.com/wordpress/?cat=8 is where I blog about it.
> http://pypi.python.org/pypi/3to2 is the PyPI page that has both of those
> links.
> --Joe Amenta
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>

-- 
--Guido van Rossum (python.org/~guido)
___
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] some notes from the first part of the lang summit

2010-02-21 Thread Steven Bethard

Thanks all for the updates. Sorry I can't make it to PyCon this year!

On Sun, Feb 21, 2010 at 1:30 AM, Eric Smith  wrote:
> There was also a quick discussion on maybe implementing optparse using
> argparse, then getting rid of the existing optparse.

I think the PEP pretty much already covers why this isn't possible. See:
http://www.python.org/dev/peps/pep-0389/#why-isn-t-the-functionality-just-being-added-to-optparse
Some of the reasons this would be really difficult include optparse's
baroque extension API and the fact that it exposes the internals of
its parsing algorithm, which means it's impossible to use a better
algorithm that has a different implementation.

On Sun, Feb 21, 2010 at 6:19 AM,   wrote:
> Would a 2to3 fixer be possible?
On Sun, Feb 21, 2010 at 6:29 AM, Benjamin Peterson  wrote:
> I don't think so. There would be subtle semantic difference 2to3
> couldn't detect.

Yep, that's probably right. And I don't know how I'd write the fixers
for anyone who was using the old optparse extension API.

On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum  wrote:
> Maybe the best thing is to make optparse *silently* deprecated, with a
> big hint at the top of its documentation telling new users to use
> argparse instead, but otherwise leaving it in indefinitely for the
> benefit of the many existing users.

So basically do what the PEP does now, except don't remove optparse in
Python 3.5?  For reference, the current proposal is:

* Python 2.7+ and 3.2+ -- The following note will be added to the
optparse documentation:
The optparse module is deprecated and will not be developed
further; development will continue with the argparse module.
* Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided
at the command line, then importing optparse will issue a
DeprecationWarning. Otherwise no warnings will be issued.
* Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.
* Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a
PendingDeprecationWarning, which is not displayed by default.
* Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a
DeprecationWarning, which is displayed by default.
* Python 3.5 (estimated Jan 2015) -- The optparse module will be removed.

So if I drop that last bullet, is the PEP ready for pronouncement?

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] some notes from the first part of the lang summit

2010-02-21 Thread Guido van Rossum

On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard
 wrote:
> On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum  wrote:
>> Maybe the best thing is to make optparse *silently* deprecated, with a
>> big hint at the top of its documentation telling new users to use
>> argparse instead, but otherwise leaving it in indefinitely for the
>> benefit of the many existing users.
>
> So basically do what the PEP does now, except don't remove optparse in
> Python 3.5?  For reference, the current proposal is:
>
> * Python 2.7+ and 3.2+ -- The following note will be added to the
> optparse documentation:
>    The optparse module is deprecated and will not be developed
> further; development will continue with the argparse module.
> * Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided
> at the command line, then importing optparse will issue a
> DeprecationWarning. Otherwise no warnings will be issued.
> * Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a
> PendingDeprecationWarning, which is not displayed by default.
> * Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a
> PendingDeprecationWarning, which is not displayed by default.
> * Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a
> DeprecationWarning, which is displayed by default.
> * Python 3.5 (estimated Jan 2015) -- The optparse module will be removed.
>
> So if I drop that last bullet, is the PEP ready for pronouncement?

Drop the last two  bullets and it's a deal. (OTOH AFAIK we changed
DeprecationWarning so it is *not* displayed by default.)

-- 
--Guido van Rossum (python.org/~guido)
___
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] lib3to2 in the 3.2 standard library?

2010-02-21 Thread Martin v. Löwis

Joe Amenta wrote:
> Hey folks,
> 
> I'm going to write a PEP for inclusion of lib3to2 in the standard
> library for 3.2 and above.  Before do, though, do people have any quick
> thoughts about it?

I do: it seems too early to me. Before it is added, I'd like a see a
significant success story of its use.

When lib2to3 was added, both Guido and Benjamin were also concerned that
it is too early, and that 2to3 would change over time, so somehow
freezing the API was undesirable. I personally felt more comfortable: I
had ported a large project myself (Django), so I knew what little API I
used could actually help porting, and also that the set of fixers
implemented was useful (although the initial port had to made quite some
work-arounds for missing and incorrect fixers which aren't need today
anymore).

So find somebody to write a large project in Python 3, and then have
them backport it with 3to2 :-) Seriously, find somebody who ports a
large Python 2 project (e.g. with 2to3) in a burn-your-bridges fashion,
and then uses 3to2 to provide 2.x releases.

In addition, I recall talk (again from Guido and Benjamin, and perhaps
also Collin) that they would prefer all of this to be rewritten as a
general rewriting library, where 2to3 and 3to2 would just be specific
sets of transformations. If that is still the case, I think such a PEP
should address that (and the code should actually be refactored

> My inclination is to get it stabilized beforehand (perhaps during
> another GSoC) by fleshing out the fixer that warns about
> backwards-incompatible features in Python 3 and by finishing up the
> fix_imports2 fixer, probably involving a rewrite.

I think stabilization must require applications. So any further
development should focus on that. In my experience, this means that
you'll have to do the porting yourself, and then offer patches. Approach
some package author(s) whether they would be interested in using 3to2 if
you did the work for them, and then pick one such project as the litmus
test. My expectation is that you'll find a need for additional changes
in doing so.

Regards,
Martin
___
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] Proposal for virtualenv functionality in Python

2010-02-21 Thread Ian Bicking

On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings  wrote:

>  * I'd rather ~/env/bin/python be a symlink instead of copying it.
>>
>
> The thread discussing Windows suggests that we shouldn't use symlinks
> there.  I'd say either copying or symlinking pythonv should be supported,
> and on Windows we recommend copying pythonv.exe.

Sure, on Windows this is clearly the case.  I'm not sure if it's worth
supporting elsewhere.  One problem with copying is that (a) you don't know
where it is copied from (requiring extra information somewhere) and (b) if
there is a minor Python release then things break (because you've copied an
old interpreter).  Probably there should be a check to catch (b) and print
an appropriate (helpful) error.

>  * Compiling extensions can be tricky because code may not find headers
>> (because they are installed in /usr, not ~/env/).  I think this can be
>> handled better if virtualenv is slightly less intrusive, or distutils is
>> patched, or generally tools are more aware of this layout.
>>
>
> Conversely, headers may be installed in ~/env and not /usr.  The compiler
> should probably look in both places.  But IIUC telling the compiler how to
> do that is only vaguely standardized--Microsoft's CL.EXE doesn't seem to
> support any environment variable containing an include /path/.
>
> I suspect solving this in a general way is out-of-band for pythonv, but I'm
> willing to have my mind changed.  Certainly pythonv should add its prefix
> directory to LD_LIBRARY_PATH on Linux.

Yes, it might be possible to change distutils to be aware of this, and some
things will work okay as a result.  Some things will really require changes
to the problematic project's setup.py to support this.

>
>  Additionally, the binary will look for a configuration file.  I'm not sure
>> where this file should go; perhaps directly alongside the binary, or in some
>> location based on sys.prefix.
>>
>> The configuration file would be a simple set of assignments; some I might
>> imagine:
>>
>> * Maybe override sys.prefix
>> * Control if the global site-packages is placed on sys.path
>> * On some operating systems there are other locations for packages
>> installed with the system packager; probably these should be possible to
>> enable or disable
>> * Maybe control installations or point to a file like distutils.cfg
>>
>
> I'm unexcited by this; I think simpler is better.  pythonv should
> virtualize environments layered on top of python, and should have one
> obvious predictable behavior.  Certainly if it supports a configuration file
> pythonv should run without it and pick sensible defaults.
>
> What are the use cases where you need these things to be configurable?
>

* Override sys.prefix: allow you to put the binary in someplace other than,
say, ~/env/bin/python and still support an environment in ~/env/.  Also the
use case of looking for libraries in a location based on the interpreter
name (not the containing directory), like supporting /usr/bin/python2.7 and
/usr/bin/python2.7-dbg.
* Control global site-packages: people use this all the time with
virtualenv.
* Other locations: well, since Ubuntu/Debian are using dist-packages and
whatnot, to get *full* isolation you might want to avoid this.  This is
really handy when testing setup instructions.
* Control installations: right now distutils only really looks in
/usr/lib/pythonX.Y/distutils/distutils.cfg for settings.  virtualenv
monkeypatches distutils to look in
/lib/pythonX.Y/distutils/distutils.cfg in addition, and several
people use this feature to control virtualenv-local installation.

>
> Let me propose further about python and pythonv:
>
>   * As Antoine suggested, the CPython interpreter should sprout a new
> command-line switch, "--prefix", which adds a new prefix directory.
>

OK; or at least, it seems fine that this would be equivalent.

>   * pythonv's purpose in life is to infer your prefix directory and
> run "pythonX.X --prefix  [ all args it got ... ]".
>

I don't see any reason to call the other Python binary, it might as well
just act like it was changed.  sys.executable *must* point to the originally
called interpreter anyway.

>   * Should pythonv should be tied to the specific Python executable? If
> you run install pythonv as "python", should it look for
> "python" or explicitly look for the specific Python it shipped
> with, like "python3.2"?  I suspect the latter though I'm no longer
> sure.
>

Experience shows the latter, plus this would only really make sense if you
really called the other interpreter (which I guess you could if you also
added an --executable option or something to fix sys.executable).  If you
did that, then maybe it would be possible to do with PEP 3147 (
http://www.python.org/dev/peps/pep-3147/) since that makes it more feasible
to support multiple Python versions with a single set of installed
libraries.  3147 is important (and that it be backported to 2.7).

I have to think about i

Re: [Python-Dev] some notes from the first part of the lang summit

2010-02-21 Thread Steven Bethard

On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum  wrote:
> On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard  
> wrote:
>> So basically do what the PEP does now, except don't remove optparse in
>> Python 3.5?  For reference, the current proposal is:
>>
>> * Python 2.7+ and 3.2+ -- The following note will be added to the
>> optparse documentation:
>>    The optparse module is deprecated and will not be developed
>> further; development will continue with the argparse module.
>> * Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided
>> at the command line, then importing optparse will issue a
>> DeprecationWarning. Otherwise no warnings will be issued.
>> * Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a
>> PendingDeprecationWarning, which is not displayed by default.
>> * Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a
>> PendingDeprecationWarning, which is not displayed by default.
>> * Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a
>> DeprecationWarning, which is displayed by default.
>> * Python 3.5 (estimated Jan 2015) -- The optparse module will be removed.
>>
>> So if I drop that last bullet, is the PEP ready for pronouncement?
>
> Drop the last two  bullets and it's a deal. (OTOH AFAIK we changed
> DeprecationWarning so it is *not* displayed by default.)

Done:

http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse

Thank you, and thanks to all who helped in the discussion of this PEP!

My plan is to make a final external release of argparse (1.1) fixing
some current issues, and then merge that into the Python repository. I
should be able to get this done before Python 2.7 alpha 4 on
2010-03-06.

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] some notes from the first part of the lang summit

2010-02-21 Thread Brett Cannon

On Sun, Feb 21, 2010 at 13:31, Guido van Rossum  wrote:

> On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard
>  wrote:
> > On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum 
> wrote:
> >> Maybe the best thing is to make optparse *silently* deprecated, with a
> >> big hint at the top of its documentation telling new users to use
> >> argparse instead, but otherwise leaving it in indefinitely for the
> >> benefit of the many existing users.
> >
> > So basically do what the PEP does now, except don't remove optparse in
> > Python 3.5?  For reference, the current proposal is:
> >
> > * Python 2.7+ and 3.2+ -- The following note will be added to the
> > optparse documentation:
> >The optparse module is deprecated and will not be developed
> > further; development will continue with the argparse module.
> > * Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided
> > at the command line, then importing optparse will issue a
> > DeprecationWarning. Otherwise no warnings will be issued.
> > * Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a
> > PendingDeprecationWarning, which is not displayed by default.
> > * Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a
> > PendingDeprecationWarning, which is not displayed by default.
> > * Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a
> > DeprecationWarning, which is displayed by default.
> > * Python 3.5 (estimated Jan 2015) -- The optparse module will be removed.
> >
> > So if I drop that last bullet, is the PEP ready for pronouncement?
>
> Drop the last two  bullets and it's a deal. (OTOH AFAIK we changed
> DeprecationWarning so it is *not* displayed by default.


Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a
DeprecationWarning would only pop up if developers exposed
DeprecationWarning. But if the module is not about to be removed in 3.x then
I think regardless of the silence of both warnings it should stay
PendingDeprecationWarning.

-Brett
___
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] Proposal for virtualenv functionality in Python

2010-02-21 Thread Tres Seaver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gregory P. Smith wrote:

> On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby  wrote:
>> At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
>>> I'm not sure how this should best work on Windows (without symlinks, and
>>> where things generally work differently), but I would hope if this idea is
>>> more visible that someone more opinionated than I would propose the
>>> appropriate analog on Windows.
>> You'd probably have to just copy pythonv.exe to an appropriate directory,
>> and have it use the configuration file to find the "real" prefix.  At least,
>> that'd be a relatively obvious way to do it, and it would have the advantage
>> of being symmetrical across platforms: just copy or symlink pythonv, and
>> make sure the real prefix is in your config file.

+1 for having the conf file in the same directory as the pythonv
esecutable (yes, I know it isn't FHS compatible, but virtualevn is kind
of antithetical to the spirit of FHS anyway).

>> (Windows does have "shortcuts" but I don't think that there's any way for a
>> linked program to know *which* shortcut it was launched from.)
> 
> Some recent discussion pointed out that vista and win7 ntfs actually
> supports symlinks.  the same question about determining where it was
> launched from may still hold there? (and we need this to work on xp).
> 
> How often do windows users need something like virtualenv?  (Asking
> for experience from windows users of all forms here).  I personally
> can't imagine anyone that would ever use a system generic python
> install from a .msi unless they're just learning python.  I would hope
> people would already use py2exe or similar and include an entire
> CPython VM with their app with their own installer but as I really
> have nothing to do with windows these days I'm sure I'm wrong.
> 
> What about using virtualenv with ironpython and jython?  does it make
> any sense in that context?  how do we make it not impossible for them
> to support?

virtualenv already works with jython:  I used it just the other day to
test installing BFG in a jython sandbox (which also worked fine).



Tres.
- --
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuBgLgACgkQ+gerLs4ltQ5x8ACghv5gXczECU+gKHmZg6L+LYA1
CWMAn0j99m9TtE0LeQ2Z9zOUpse3P53b
=l+uZ
-END PGP SIGNATURE-

___
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] some notes from the first part of the lang summit

2010-02-21 Thread Eric Smith


Brett Cannon wrote:
Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a 
DeprecationWarning would only pop up if developers exposed 
DeprecationWarning. But if the module is not about to be removed in 3.x 
then I think regardless of the silence of both warnings it should stay 
PendingDeprecationWarning.


But if we're never going to change it to a DeprecationWarning, it's not 
pending. So why not just change the docs and not add any warnings to the 
code?


Eric.
___
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] some notes from the first part of the lang summit

2010-02-21 Thread Brett Cannon

On Sun, Feb 21, 2010 at 14:46, Eric Smith  wrote:

> Brett Cannon wrote:
>
>> Yes, DeprecationWarning is now silent under Python 2.7 and 3.1 so a
>> DeprecationWarning would only pop up if developers exposed
>> DeprecationWarning. But if the module is not about to be removed in 3.x then
>> I think regardless of the silence of both warnings it should stay
>> PendingDeprecationWarning.
>>
>
> But if we're never going to change it to a DeprecationWarning, it's not
> pending.

Well, it's pending until Py4K, so it's accurate, we just don't know yet when
it will change to an actual deprecation. =)

> So why not just change the docs and not add any warnings to the code?

Could, but the code will go away some day and not everyone will read the
docs to realize that they might want to upgrade their code if they care to
use the shiniest thing in the standard library.

-Brett
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Collin Winter

Hey Dirkjan,

Would it be possible for us to get a Mercurial repository on
python.org for the Unladen Swallow benchmarks? Maciej and I would like
to move the benchmark suite out of Unladen Swallow and into
python.org, where all implementations can share it and contribute to
it. PyPy has been adding some benchmarks to their copy of the Unladen
benchmarks, and we'd like to have as well, and Mercurial seems to be
an ideal solution to this.

Thanks,
Collin Winter
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Dirkjan Ochtman

Hi Collin (and others),

On Sun, Feb 21, 2010 at 15:28, Collin Winter  wrote:
> Would it be possible for us to get a Mercurial repository on
> python.org for the Unladen Swallow benchmarks? Maciej and I would like
> to move the benchmark suite out of Unladen Swallow and into
> python.org, where all implementations can share it and contribute to
> it. PyPy has been adding some benchmarks to their copy of the Unladen
> benchmarks, and we'd like to have as well, and Mercurial seems to be
> an ideal solution to this.

Just a repository on hg.python.org?

Sounds good to me. Are you staying for the sprints? We'll just do it.
(Might need to figure out some hooks we want to put up with it.)

Cheers,

Dirkjan
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Collin Winter

On Sun, Feb 21, 2010 at 3:31 PM, Dirkjan Ochtman  wrote:
> Hi Collin (and others),
>
> On Sun, Feb 21, 2010 at 15:28, Collin Winter  wrote:
>> Would it be possible for us to get a Mercurial repository on
>> python.org for the Unladen Swallow benchmarks? Maciej and I would like
>> to move the benchmark suite out of Unladen Swallow and into
>> python.org, where all implementations can share it and contribute to
>> it. PyPy has been adding some benchmarks to their copy of the Unladen
>> benchmarks, and we'd like to have as well, and Mercurial seems to be
>> an ideal solution to this.
>
> Just a repository on hg.python.org?
>
> Sounds good to me. Are you staying for the sprints? We'll just do it.
> (Might need to figure out some hooks we want to put up with it.)

Yep, that's all we want. I'll be around for the sprints through
Tuesday, sitting at the Unladen Swallow sprint.

Collin Winter
___
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] Proposal for virtualenv functionality in Python

2010-02-21 Thread Larry Hastings




Ian Bicking wrote:
On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings > wrote:
* Override sys.prefix: allow you to put the binary in someplace other 
than, say, ~/env/bin/python and still support an environment in 
~/env/.  Also the use case of looking for libraries in a location 
based on the interpreter name (not the containing directory), like 
supporting /usr/bin/python2.7 and /usr/bin/python2.7-dbg.


I'm new to this: why would you want to change sys.prefix in the first 
place?  Its documentation implies that it's where Python itself is 
installed.  I see two uses in the standard library (trace and gettext) 
and they both look like they'd get confused if sys.prefix pointed at a 
virtualized directory.


* Control global site-packages: people use this all the time with 
virtualenv.
* Other locations: well, since Ubuntu/Debian are using dist-packages 
and whatnot, to get *full* isolation you might want to avoid this. 
 This is really handy when testing setup instructions.
* Control installations: right now distutils only really looks in 
/usr/lib/pythonX.Y/distutils/distutils.cfg for settings.  virtualenv 
monkeypatches distutils to look in 
/lib/pythonX.Y/distutils/distutils.cfg in addition, and 
several people use this feature to control virtualenv-local installation.


Okey-doke, I defer to your experience.

Obviously if this is going into Python we can do better than 
monkeypatching distutils.



  * pythonv's purpose in life is to infer your prefix directory and
run "pythonX.X --prefix  [ all args it got ... ]".


I don't see any reason to call the other Python binary, it might as 
well just act like it was changed.  sys.executable *must* point to the 
originally called interpreter anyway.


If by this you mean pythonv should load the Python shared library / DLL 
directly, that would make it impossible to stack environments.  Which 
I'm still angling for.



/larry/
___
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] Proposal for virtualenv functionality in Python

2010-02-21 Thread Barry Warsaw

On Feb 21, 2010, at 01:51 PM, Tres Seaver wrote:

>+1 for having the conf file in the same directory as the pythonv
>esecutable (yes, I know it isn't FHS compatible, but virtualevn is kind
>of antithetical to the spirit of FHS anyway).

Which is okay, right? because virtualenv is really about development and the
FHS is really about installation.  Is that what you meant by "antithetical"?

-Barry

signature.asc
Description: PGP signature
___
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] Proposal for virtualenv functionality in Python

2010-02-21 Thread Tres Seaver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Barry Warsaw wrote:
> On Feb 21, 2010, at 01:51 PM, Tres Seaver wrote:
> 
>> +1 for having the conf file in the same directory as the pythonv
>> esecutable (yes, I know it isn't FHS compatible, but virtualevn is kind
>> of antithetical to the spirit of FHS anyway).
> 
> Which is okay, right? because virtualenv is really about development and the
> FHS is really about installation.  Is that what you meant by "antithetical"?

FHS is about keeping the "system" components in known location, and
mandates stuff like separation of binaries, configuration, shared libs,
data, etc..  virtualenv is about building an envirnoment which is
insultated from the system components (and avoids polluting them).

Putting the config file next to the binary would be verboten under the
FHS, but I don't think it is relevant.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuBqQMACgkQ+gerLs4ltQ6hsACeJl44YWskNdPiPhAkLcu0RSom
sXAAn0/8dD++Z17VvtknD2hGQcYRGOPX
=WXX4
-END PGP SIGNATURE-
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Daniel Stutzbach

On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter wrote:

> Would it be possible for us to get a Mercurial repository on
> python.org for the Unladen Swallow benchmarks? Maciej and I would like
> to move the benchmark suite out of Unladen Swallow and into
> python.org, where all implementations can share it and contribute to
> it. PyPy has been adding some benchmarks to their copy of the Unladen
> benchmarks, and we'd like to have as well, and Mercurial seems to be
> an ideal solution to this.
>

If and when you have a benchmark repository set up, could you announce it
via a reply to this thread?  I'd like to check it out.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Maciej Fijalkowski

Hello.

We probably also need some people, besides CPython devs having some
access to it (like me).

Cheers,
fijal

On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach
 wrote:
> On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter 
> wrote:
>>
>> Would it be possible for us to get a Mercurial repository on
>> python.org for the Unladen Swallow benchmarks? Maciej and I would like
>> to move the benchmark suite out of Unladen Swallow and into
>> python.org, where all implementations can share it and contribute to
>> it. PyPy has been adding some benchmarks to their copy of the Unladen
>> benchmarks, and we'd like to have as well, and Mercurial seems to be
>> an ideal solution to this.
>
> If and when you have a benchmark repository set up, could you announce it
> via a reply to this thread?  I'd like to check it out.
> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>
>
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Dirkjan Ochtman

On Sun, Feb 21, 2010 at 21:31, Maciej Fijalkowski  wrote:
> We probably also need some people, besides CPython devs having some
> access to it (like me).

Right. I've setup a public repository on hg.python.org:

http://hg.python.org/benchmarks/

Right now, I still need to have Martin change some configuration so I
will be able to set up push access for people other than me, so it's
pull-only for now. I've already sent an email to Martin to help me get
this fixed, so it should be fixed soon. Let me know if there are any
issues.

Cheers,

Dirkjan
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Collin Winter

Hey Daniel,

On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach
 wrote:
> On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter 
> wrote:
>>
>> Would it be possible for us to get a Mercurial repository on
>> python.org for the Unladen Swallow benchmarks? Maciej and I would like
>> to move the benchmark suite out of Unladen Swallow and into
>> python.org, where all implementations can share it and contribute to
>> it. PyPy has been adding some benchmarks to their copy of the Unladen
>> benchmarks, and we'd like to have as well, and Mercurial seems to be
>> an ideal solution to this.
>
> If and when you have a benchmark repository set up, could you announce it
> via a reply to this thread?  I'd like to check it out.

Will do.

In the meantime, you can read
http://code.google.com/p/unladen-swallow/wiki/Benchmarks to find out
how to check out the current draft of the benchmarks, as well as which
benchmarks are currently included.

Thanks,
Collin Winter
___
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] Another mercurial repo

2010-02-21 Thread Tarek Ziadé

Hello Dirkjan,

We are going to start working on a few things in Distutils at Pycon
outside the trunk.

I was about to start this work in the svn sandbox, but if possible I'd
rather have a repo at hg.python.org as well

Regards
Tarek

-- 
Tarek Ziadé | http://ziade.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] Another mercurial repo

2010-02-21 Thread Dirkjan Ochtman

On Sun, Feb 21, 2010 at 21:44, Tarek Ziadé  wrote:
> We are going to start working on a few things in Distutils at Pycon
> outside the trunk.

This would be full branch of Python? In that case, we probably don't
want to go there yet, because the hashes of the python repository
currently on hg.p.o will definitely change more and that will cause
problems.

Cheers,

Dirkjan
___
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] Another mercurial repo

2010-02-21 Thread Tarek Ziadé

On Sun, Feb 21, 2010 at 9:47 PM, Dirkjan Ochtman  wrote:
> On Sun, Feb 21, 2010 at 21:44, Tarek Ziadé  wrote:
>> We are going to start working on a few things in Distutils at Pycon
>> outside the trunk.
>
> This would be full branch of Python? In that case, we probably don't
> want to go there yet, because the hashes of the python repository
> currently on hg.p.o will definitely change more and that will cause
> problems.

No that would be just a new fresh empty repository for "distutils 2"
that will be developed outside the Python stdlib for a while, and will
enventually get back into it when it's ready I guess.

I figured it would be easier for people to fork/clone it to work on it
if ts a DVCS, even if it's just me that can push in it for the moment.

But if this is too much trouble right now don't worry about it.

Tarek

-- 
Tarek Ziadé | http://ziade.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] Mercurial repository for Python benchmarks

2010-02-21 Thread Benjamin Peterson

2010/2/21 Dirkjan Ochtman :
> Right. I've setup a public repository on hg.python.org:

I think we should probably develop a policy about hg.python.org repos
before we start handing them out. Who will be able to have a repo on
hg.python.org? What kinds of projects?


-- 
Regards,
Benjamin
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Dirkjan Ochtman

On Sun, Feb 21, 2010 at 22:21, Benjamin Peterson  wrote:
> I think we should probably develop a policy about hg.python.org repos
> before we start handing them out. Who will be able to have a repo on
> hg.python.org? What kinds of projects?

I'd be happy to host stuff for people who are already Python
committers, and limit it to stuff that would otherwise live somewhere
in Python's svn repository.

Cheers,

Dirkjan
___
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] Mercurial repository for Python benchmarks

2010-02-21 Thread Benjamin Peterson

2010/2/21 Dirkjan Ochtman :
> On Sun, Feb 21, 2010 at 22:21, Benjamin Peterson  wrote:
>> I think we should probably develop a policy about hg.python.org repos
>> before we start handing them out. Who will be able to have a repo on
>> hg.python.org? What kinds of projects?
>
> I'd be happy to host stuff for people who are already Python
> committers, and limit it to stuff that would otherwise live somewhere
> in Python's svn repository.

+1 Sounds like a good starting place.



-- 
Regards,
Benjamin
___
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] Another mercurial repo

2010-02-21 Thread Dirkjan Ochtman

On Sun, Feb 21, 2010 at 21:56, Tarek Ziadé  wrote:
> No that would be just a new fresh empty repository for "distutils 2"
> that will be developed outside the Python stdlib for a while, and will
> enventually get back into it when it's ready I guess.
>
> I figured it would be easier for people to fork/clone it to work on it
> if ts a DVCS, even if it's just me that can push in it for the moment.
>
> But if this is too much trouble right now don't worry about it.

Sounds good, per the policy for Mercurial hosting, see the other
thread (but weren't you going to improve distutils, instead of
rewriting it?). Only problem is, right now you could only push through
me. So, start off in hg, put it on bitbucket for now and we'll set it
up on hg.p.o when Martin gets back to me (also see the other thread).

Cheers,

Dirkjan
___
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] Another mercurial repo

2010-02-21 Thread Tarek Ziadé

On Sun, Feb 21, 2010 at 10:54 PM, Dirkjan Ochtman  wrote:
> On Sun, Feb 21, 2010 at 21:56, Tarek Ziadé  wrote:
>> No that would be just a new fresh empty repository for "distutils 2"
>> that will be developed outside the Python stdlib for a while, and will
>> enventually get back into it when it's ready I guess.
>>
>> I figured it would be easier for people to fork/clone it to work on it
>> if ts a DVCS, even if it's just me that can push in it for the moment.
>>
>> But if this is too much trouble right now don't worry about it.
>
> Sounds good, per the policy for Mercurial hosting, see the other
> thread (but weren't you going to improve distutils, instead of
> rewriting it?).

I am improving it, continuing the work that has been started.

Here's the bottom line:

We decided during the language summit that I would perform this work
outside the stdlib (e.g. fork
distutils), and leave the current distutils in its current state to
avoid any backward compat work nightmares, and possible issues with
some third party projects that might be sensitive to some changes even
if performed in the internals. (it happened)

The new PEPs will be implemented in distutils2 (non-definitive name)
and I'll be able to remove
stuff we don't want to keep in there without worrying. I was reluctant
with this idea at first because I've started to work on this in
distutils itself and I wanted the work to be included in 2.7 so we
wouldn't wait 18 more months.

But now I am fully convinced this is the best plan : around the time
2.7 is out, we will be able to release distutils2 and provide a
version for 2.4/2.5/2.6/3.1 as well, and get feedback from the
community to prepare a rock-solid version for 3.3. And if we make some
mistakes in it, we will be able to correct them faster.

We do want this package in the stdlib, because its part of what people
are expecting in the batteries included, but as Guido explained during
the summit, a package in the stdlib has one foot in the grave.

> Only problem is, right now you could only push through
> me. So, start off in hg, put it on bitbucket for now and we'll set it
> up on hg.p.o when Martin gets back to me (also see the other thread).

Sounds good, thanks

Tarek
-- 
Tarek Ziadé | http://ziade.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

[Python-Dev] 'languishing' status for the tracker

2010-02-21 Thread R. David Murray

I believe Brett mentioned the 'languishing' status for the tracker in
passing in his notes from the language summit.

To expand on this: the desire for this arises from the observation
that we have a lot of bugs in the tracker that we don't want to close,
because they are real bugs or non-crazy enhancement requests, but for
one reason or another (lack of an interested party, lack of a good,
non-controversial solution, lack of a test platform on which to test the
bug fix, the fix is hard but the bug is not of a commensurate priority,
etc) the issue just isn't getting dealt with, and won't get dealt with
until the blocking factor changes.

The motivation for introducing a new status, rather than continuing
to leave these bugs in 'open' state, is to make it clear which bugs
are the *active* bugs, the ones we should be focusing on and working
to fix first.  This would allow the count of open bugs to be a more
meaningful metric than it is currently, and might even allow us to get
to a point where the open bug count stops increasing.  More importantly,
however, it would act as a first level partition of the non-closed bugs,
such that the ones for which it is most likely that effective action can
be taken will be what appear first.  This is especially important for new
people coming in to help.  How many people have looked at the tracker,
and decided to start from the oldest bugs and see what they can fix?
I know I started out that way.  Looking through those oldest bugs can
be quite discouraging, since many of them are old because they are hard,
or blocked for one reason or another.

We would in addition propose that a 'languishing' search be added to
the standard searches.  I would also propose that the default search
be changed to search all bugs, and group them by status, not priority.
This will make it more likely that bug *reporters* will find existing
bugs that relate to the problem they are experiencing or the feature
they want to propose.  The other searches (except open) should probably
return languishing issues as well as open, since they sort in reverse
chronological order the more active bugs will be at the top, and that
way the languishing bugs won't be forgotten.  (Note: languishing bugs
should probably never have the 'needs review' keyword, since bugs should
not be allowd to languish simply for need of a review.)

To move a bug to state languishing, the procedure should be to post
a comment saying why you are moving the bug to that status, that by
implication or explicitly lays out the conditions required for it to
move back to open.  Doing so may wake someone up who wants to and can
deal with the issue, in which case it can be moved back to open.

--David

PS: I believe that the other change that would be required in addition
to adding the new status and search is to alter the bug summary email
script to handle the languishing state.  If I've missed anything else
please let me know.
___
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] Proposal for virtualenv functionality in Python

2010-02-21 Thread Neil Hodgson

Larry Hastings:

> But IIUC telling the compiler how to
> do that is only vaguely standardized--Microsoft's CL.EXE doesn't seem to
> support any environment variable containing an include /path/.

   The INCLUDE environment variable is a list of ';' separated paths
http://msdn.microsoft.com/en-us/library/36k2cdd4%28VS.100%29.aspx

   Neil
___
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

37 matches

Mail list logo