[Python-Dev] Accepting PEP 405 (Python Virtual Environments)

2012-05-25 Thread Nick Coghlan 
As the latest round of updates that Carl and Vinay pushed to the PEPs
repo have addressed my few remaining questions, I am accepting PEP 405
for inclusion in Python 3.3.

Thanks to all involved in working out the spec for what to model
directly on virtualenv, and areas where cleaner solutions could be
found given the power to tweak the behaviour of the core interpreter
and the standard library.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] VS 11 Express is Metro only.

2012-05-25 Thread Joao S. O. Bueno 
On 24 May 2012 19:36,   wrote:
>> The free Visual Studio 11 Express for Windows 8 (still in beta) will
>> produce both 32 and 64 bit binaries and allow multiple languages but will
>> only produce Metro apps. For desktop apps, either the paid Visual Studio
>> versions or the free 2010 Express releases are required.
>> https://www.microsoft.com/visualstudio/11/en-us/products/express
>> bottom of page.
>>
>> Will this inhibit someday moving to Visual Studio 11 Professional or would
>> VS2010 Express or VC++2010 Express still work for hacking on Python or
>> making extensions that would work with any VS11-produced binary?
>
>
> I think it's too early to guess what the final release of Visual Studio
> 11 Express will or will not include.

It is better documented here, and seems something to start thinking about:

http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/

>
> 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/jsbueno%40python.org.br
___
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] VS 11 Express is Metro only.

2012-05-25 Thread martin 

It is better documented here, and seems something to start thinking about:

http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/


This isn't actually better documentation, since it talks about the future,
without being "official" (i.e. it's Peter Bright's opinion, not a Microsoft
announcement).

I hereby predict that Microsoft will revert this decision, and that VS Express
11 will be able to build CPython.

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] VS 11 Express is Metro only.

2012-05-25 Thread Curt Hagenlocher 
On Fri, May 25, 2012 at 5:06 AM,  wrote:

> It is better documented here, and seems something to start thinking about:
>>
>> http://arstechnica.com/**information-technology/2012/**
>> 05/no-cost-desktop-software-**development-is-dead-on-**windows-8/
>>
>
> This isn't actually better documentation, since it talks about the future,
> without being "official" (i.e. it's Peter Bright's opinion, not a Microsoft
> announcement).
>
> I hereby predict that Microsoft will revert this decision, and that VS
> Express
> 11 will be able to build CPython.
>

But will it be able to target Windows XP?

http://connect.microsoft.com/VisualStudio/feedback/details/690617/bug-apps-created-with-crt-and-mfc-vnext-11-cannot-be-used-on-windows-xp-sp3

(Disclaimer: I work at Microsoft, but I know nothing about either of these
topics.)

-Curt
___
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] VS 11 Express is Metro only.

2012-05-25 Thread Nick Coghlan 
On Fri, May 25, 2012 at 10:17 PM, Curt Hagenlocher  wrote:
> But will it be able to target Windows XP?
>
> http://connect.microsoft.com/VisualStudio/feedback/details/690617/bug-apps-created-with-crt-and-mfc-vnext-11-cannot-be-used-on-windows-xp-sp3

The key things to remember at this point:

1. There's every chance Microsoft will reverse this decision, for all
the reasons they introduced the Express editions of Visual Studio in
the first place (e.g. to stop haemorrhaging hobbyist developers to
other ecosystems where development tools aren't a profit centre). The
collective "WTF?!" from third parties at their current approach
(eloquently expressed by Peter Bright over at Ars) is going to be hard
for even the most passionate Metro advocates to ignore.
2. It's going to be at least 18 months before CPython's Windows build
is likely to migrate to VS2011, and if there's still no desktop app
support in the Express edition at that time, that will be a strong
argument against migrating.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: issue 14660: Implement PEP 420, namespace packages.

2012-05-25 Thread Barry Warsaw 
On May 25, 2012, at 10:31 AM, Brett Cannon wrote:

>Is documentation coming in a separate commit?

Yes.  I've been reworking the import machinery documentation; it's a
work-in-progress on the pep-420 feature clone ('importdocs' branch).  I made
some good progress and then got side-tracked, but I'm planning on getting back
to it soon.

-Barry
___
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] Summary of Python tracker Issues

2012-05-25 Thread Python tracker 

ACTIVITY SUMMARY (2012-05-18 - 2012-05-25)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open3440 ( +8)
  closed 23254 (+58)
  total  26694 (+66)

Open issues with patches: 1455 


Issues opened (44)
==

#11804: expat parser not xml 1.1 (breaks xmlrpclib)
http://bugs.python.org/issue11804  reopened by xrg

#14852: json and ElementTree parsers misbehave on streams containing m
http://bugs.python.org/issue14852  opened by Frederick.Ross

#14853: test_file.py depends on sys.stdin being unseekable
http://bugs.python.org/issue14853  opened by gregory.p.smith

#14854: faulthandler: fatal error with "SystemError: null argument to 
http://bugs.python.org/issue14854  opened by zbysz

#14855: IPv6 support for logging.handlers
http://bugs.python.org/issue14855  opened by cblp

#14856: argparse: creating an already defined subparsers does not rais
http://bugs.python.org/issue14856  opened by eacb

#14857: Direct access to lexically scoped __class__ is broken in 3.3
http://bugs.python.org/issue14857  opened by ncoghlan

#14858: 'pysetup create' off-by-one when choosing classification matur
http://bugs.python.org/issue14858  opened by todddeluca

#14869: imaplib erronously quotes atoms such as flags
http://bugs.python.org/issue14869  opened by brightbyte

#14870: Descriptions of os.utime() and os.utimensat() use wrong notati
http://bugs.python.org/issue14870  opened by hynek

#14871: Rewrite the command line parsers and actions system used in di
http://bugs.python.org/issue14871  opened by eric.araujo

#14873: Windows devguide: clarification for build errors due to missin
http://bugs.python.org/issue14873  opened by valhallasw

#14874: Faster charmap decoding
http://bugs.python.org/issue14874  opened by storchaka

#14876: IDLE highlighting theme does not preview with user-selected fo
http://bugs.python.org/issue14876  opened by andrew.m

#14877: No option to run bdist_wininst against newer msvc versions on 
http://bugs.python.org/issue14877  opened by Aaron.Staley

#14878: send statement from PEP342 is poorly documented.
http://bugs.python.org/issue14878  opened by Stephen.Lacy

#14879: invalid docs for subprocess exceptions with shell=True
http://bugs.python.org/issue14879  opened by techtonik

#14880: csv.reader and .writer use wrong kwargs notation in 2.7 docs
http://bugs.python.org/issue14880  opened by hynek

#14881: multiprocessing.dummy craches when self._parent._children does
http://bugs.python.org/issue14881  opened by Itay.Brandes

#14882: Link/Compile Error on Sun Sparc Solaris10 with gcc3.4.3pyt
http://bugs.python.org/issue14882  opened by seeker77

#14886: json C vs pure-python implementation difference
http://bugs.python.org/issue14886  opened by mmarkk

#14892: 'import readline' hangs when launching with '&' on BSD and OS 
http://bugs.python.org/issue14892  opened by olivier-mattelaer

#14893: Tutorial: Add function annotation example to function tutorial
http://bugs.python.org/issue14893  opened by zach.ware

#14894: distutils.LooseVersion fails to compare number and a word
http://bugs.python.org/issue14894  opened by Natalia

#14895: test_warnings.py EnvironmentVariableTests is a bad test
http://bugs.python.org/issue14895  opened by tebeka

#14897: struct.pack raises unexpected error message
http://bugs.python.org/issue14897  opened by mesheb82

#14899: Naming conventions and guidelines for packages and namespace p
http://bugs.python.org/issue14899  opened by benoitbryon

#14900: cProfile does not take its result headers as sort arguments
http://bugs.python.org/issue14900  opened by ArneBab

#14901: Python Windows FAQ is Very Outdated
http://bugs.python.org/issue14901  opened by michael.driscoll

#14902: test_logging failed
http://bugs.python.org/issue14902  opened by cblp

#14903: dictobject infinite loop on 2.6.5 on 32-bit x86
http://bugs.python.org/issue14903  opened by Daniel.Farina

#14904: test_unicode_repr_oflw (in test_bigmem) crashes
http://bugs.python.org/issue14904  opened by pitrou

#14905: zipimport.c needs to support namespace packages when no 'direc
http://bugs.python.org/issue14905  opened by eric.smith

#14906: rotatingHandler WindowsError
http://bugs.python.org/issue14906  opened by jacuro

#14907: SSL module cannot handle unicode filenames
http://bugs.python.org/issue14907  opened by ms4py

#14908: datetime.datetime should have a timestamp() method
http://bugs.python.org/issue14908  opened by djc

#14909: Fix incorrect use of *Realloc() and *Resize()
http://bugs.python.org/issue14909  opened by kristjan.jonsson

#14910: argparse: disable abbreviation
http://bugs.python.org/issue14910  opened by jens.jaehrig

#14911: generator.throw() documentation inaccurate
http://bugs.python.org/issue14911  opened by kristjan.jonsson

#14912: Pdb does not stop at a breakpoint after a restart command and 
http://bugs.python.org/issue14912  opened

Re: [Python-Dev] Accepting PEP 405 (Python Virtual Environments)

2012-05-25 Thread Georg Brandl 
Am 25.05.2012 10:44, schrieb Nick Coghlan:
> As the latest round of updates that Carl and Vinay pushed to the PEPs
> repo have addressed my few remaining questions, I am accepting PEP 405
> for inclusion in Python 3.3.
> 
> Thanks to all involved in working out the spec for what to model
> directly on virtualenv, and areas where cleaner solutions could be
> found given the power to tweak the behaviour of the core interpreter
> and the standard library.

Great!  Please remember that the next 3.3 alpha is scheduled for this
weekend, so please let me know in which timescale you plan to implement
this PEP.  If you want to commit it before this alpha, I can shift it
by a few days, but not a whole week since I'm on vacation for one week
from June 2nd.

Georg

___
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] cpython: simplify and rewrite the zipimport part of 702009f3c0b1 a bit

2012-05-25 Thread Georg Brandl 
Am 25.05.2012 07:54, schrieb benjamin.peterson:
> http://hg.python.org/cpython/rev/a47d32a28662
> changeset:   77129:a47d32a28662
> user:Benjamin Peterson 
> date:Thu May 24 22:54:15 2012 -0700
> summary:
>   simplify and rewrite the zipimport part of 702009f3c0b1 a bit
> 
> files:
>   Modules/zipimport.c |  92 ++--
>   1 files changed, 41 insertions(+), 51 deletions(-)
> 
> 
> diff --git a/Modules/zipimport.c b/Modules/zipimport.c
> --- a/Modules/zipimport.c
> +++ b/Modules/zipimport.c
> @@ -319,13 +319,20 @@
>  return MI_NOT_FOUND;
>  }
>  
> +typedef enum {
> +fl_error,
> +fl_not_found,
> +fl_module_found,
> +fl_ns_found
> +} find_loader_result;

This is probably minor, but wouldn't it make more sense to have those
constants uppercased?  At least that's the general style we have in
the codebase for enum values.

(There's one exception, but also recently committed, in posixmodule.c
for the utime_result enum.  Maybe that could also be fixed.)

Georg

___
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] cpython: simplify and rewrite the zipimport part of 702009f3c0b1 a bit

2012-05-25 Thread Antoine Pitrou 
On Fri, 25 May 2012 18:57:57 +0200
Georg Brandl  wrote:

> Am 25.05.2012 07:54, schrieb benjamin.peterson:
> > http://hg.python.org/cpython/rev/a47d32a28662
> > changeset:   77129:a47d32a28662
> > user:Benjamin Peterson 
> > date:Thu May 24 22:54:15 2012 -0700
> > summary:
> >   simplify and rewrite the zipimport part of 702009f3c0b1 a bit
> > 
> > files:
> >   Modules/zipimport.c |  92 ++--
> >   1 files changed, 41 insertions(+), 51 deletions(-)
> > 
> > 
> > diff --git a/Modules/zipimport.c b/Modules/zipimport.c
> > --- a/Modules/zipimport.c
> > +++ b/Modules/zipimport.c
> > @@ -319,13 +319,20 @@
> >  return MI_NOT_FOUND;
> >  }
> >  
> > +typedef enum {
> > +fl_error,
> > +fl_not_found,
> > +fl_module_found,
> > +fl_ns_found
> > +} find_loader_result;
> 
> This is probably minor, but wouldn't it make more sense to have those
> constants uppercased?  At least that's the general style we have in
> the codebase for enum values.

+1, this surprised me too.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] doc change for weakref

2012-05-25 Thread Ethan Furman 

I'd like to make a slight doc change for weakref to state (more or less):

   weakrefs are not invalidated when the strong refs
   are gone, but rather when garbage collection
   reclaims the object

Should this be accurate for all implementations, or should it be more 
along the lines of:


   weakrefs may be invalidated as soon as the strong refs
   are gone, but may last until garbage collection reclaims
   the object

~Ethan~
___
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] doc change for weakref

2012-05-25 Thread Benjamin Peterson 
2012/5/25 Ethan Furman :
> I'd like to make a slight doc change for weakref to state (more or less):
>
>   weakrefs are not invalidated when the strong refs
>   are gone, but rather when garbage collection
>   reclaims the object

 I think this is fine.


-- 
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] doc change for weakref

2012-05-25 Thread Antoine Pitrou 
On Fri, 25 May 2012 10:21:39 -0700
Ethan Furman  wrote:
> I'd like to make a slight doc change for weakref to state (more or less):
> 
> weakrefs are not invalidated when the strong refs
> are gone, but rather when garbage collection
> reclaims the object
> 
> Should this be accurate for all implementations, or should it be more 
> along the lines of:
> 
> weakrefs may be invalidated as soon as the strong refs
> are gone, but may last until garbage collection reclaims
> the object

How about: weakrefs are invalidated when the object is destroyed,
either as a product of all the strong references being gone or the
object being reclaimed by the :term:`cyclic garbage collector
`.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Rietveld update

2012-05-25 Thread martin 

As some have probably noticed: I updated the Rietveld version that we use to
the current code base. There have been a few incompatible changes (schema, GAE
API) which I hope I resolved. If you find new problems, please report them
to the meta tracker.

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] Volunteering to be PEP czar for PEP 421, sys.implementation

2012-05-25 Thread Barry Warsaw 
On May 21, 2012, at 05:24 PM, Barry Warsaw wrote:

>I've mentioned this in private to a few folks, with generally positive
>feedback.
>
>I am formally volunteering to be PEP czar for PEP 421, sys.implementation.  If
>there are no objections in the next few days, I'll make it official.

I received no objections, so I've claimed BDFL-Delegate on this PEP.  I am
doing a little bit more research, but I'm nearly ready to pronounce on this.

Cheers,
-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] sys.implementation

2012-05-25 Thread Barry Warsaw 
On May 17, 2012, at 07:19 AM, Eric Snow wrote:

>PEP 421 has reached a good place and I'd like to ask for pronouncement.

As the newly self-appointed PEP 421 czar, I hereby accept this PEP.

Eric, you've done a masterful job at balancing and addressing the input from
the Python development community, and the PEP looks great.  I have not yet
reviewed the patches in issue 14673, but the last message on that item
indicates the patch is not yet up-to-date with the PEP description.

Please update the issue, and if possible, let's get it landed before Sunday's
alpha 4.

Congratulations.
-Barry

http://bugs.python.org/issue14673


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] Accepting PEP 405 (Python Virtual Environments)

2012-05-25 Thread Vinay Sajip 
Georg Brandl  gmx.net> writes:

> Great!  Please remember that the next 3.3 alpha is scheduled for this
> weekend, so please let me know in which timescale you plan to implement
> this PEP.  If you want to commit it before this alpha, I can shift it
> by a few days, but not a whole week since I'm on vacation for one week
> from June 2nd.

I believe it is ready to integrate now. I aim to do it tomorrow (26 May) a.m.
UTC, so that it can make the next alpha.

Regards,

Vinay Sajip



___
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] sys.implementation

2012-05-25 Thread Eric Snow 
On Fri, May 25, 2012 at 12:23 PM, Barry Warsaw  wrote:
> On May 17, 2012, at 07:19 AM, Eric Snow wrote:
>
>>PEP 421 has reached a good place and I'd like to ask for pronouncement.
>
> As the newly self-appointed PEP 421 czar, I hereby accept this PEP.
>
> Eric, you've done a masterful job at balancing and addressing the input from
> the Python development community, and the PEP looks great.  I have not yet
> reviewed the patches in issue 14673, but the last message on that item
> indicates the patch is not yet up-to-date with the PEP description.

Thanks Barry, and everyone who chimed in!  This PEP is a whole lot
better because of the feedback of this community.  I'm hopeful that it
will be a good vehicle to make life easier for the other
implementations.

> Please update the issue, and if possible, let's get it landed before Sunday's
> alpha 4.

I'll do that tonight.

-eric

>
> Congratulations.
> -Barry
>
> http://bugs.python.org/issue14673
___
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] doc change for weakref

2012-05-25 Thread Tim Delaney 
On 26 May 2012 03:46, Antoine Pitrou  wrote:

> On Fri, 25 May 2012 10:21:39 -0700
> Ethan Furman  wrote:
> > I'd like to make a slight doc change for weakref to state (more or less):
> >
> > weakrefs are not invalidated when the strong refs
> > are gone, but rather when garbage collection
> > reclaims the object
> >
> > Should this be accurate for all implementations, or should it be more
> > along the lines of:
> >
> > weakrefs may be invalidated as soon as the strong refs
> > are gone, but may last until garbage collection reclaims
> > the object
>
> How about: weakrefs are invalidated when the object is destroyed,
> either as a product of all the strong references being gone or the
> object being reclaimed by the :term:`cyclic garbage collector
> `.
>

I think this could be misleading - it could be read as weakrefs are gone as
soon as all strong refs are gone if there are no cycles. It's
CPython-specific.

IIRC this was exactly Ethan's issue on python-list - he'd made the
assumption that weakrefs went away as soon as all strong refs were gone,
which broke on other Python implementations (and would have also broken if
he'd had cycles).

How about: weakrefs are invalidated only when the object is destroyed,
which is dependent on the garbage collection method implemented.

That then prevents an implementation from invalidating weakrefs before GC -
however, since the object would then be completely unreachable (except by C
code) I'm not sure it matters.

Tim Delaney
___
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] doc change for weakref

2012-05-25 Thread Steven D'Aprano 

Ethan Furman wrote:

I'd like to make a slight doc change for weakref to state (more or less):


What specific part of the docs are you planning to change?

My guess is that you want to change this start of the third paragraph:

http://docs.python.org/py3k/library/weakref.html

[quote]
A weak reference to an object is not enough to keep the object alive: when the 
only remaining references to a referent are weak references, garbage 
collection is free to destroy the referent and reuse its memory for something 
else.

[end quote]

I don't think that should be changed. It makes no promises except that weak 
refs won't keep an object alive. Everything else is an implementation detail, 
as it should be.




   weakrefs are not invalidated when the strong refs
   are gone, but rather when garbage collection
   reclaims the object



I think you're making a distinction here that we should not make. Reference 
counting *is* a garbage collector (even if gc-bigots like to sneer at ref 
counting as "not a real gc"), and implementations with such a ref counting gc 
will not always distinguish the two states "strong refs are gone" and "object 
is reclaimed".


I don't believe that we need to make promises about the exact timing of when 
weak refs will be invalidated.



Should this be accurate for all implementations, or should it be more 
along the lines of:


   weakrefs may be invalidated as soon as the strong refs
   are gone, but may last until garbage collection reclaims
   the object


This is better than the previous suggestion, since it says "may" rather than 
implies a "will".



--
Steven
___
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] Accepting PEP 405 (Python Virtual Environments)

2012-05-25 Thread Vinay Sajip 
Georg Brandl  gmx.net> writes:

> Great!  Please remember that the next 3.3 alpha is scheduled for this
> weekend, so please let me know in which timescale you plan to implement
> this PEP.  If you want to commit it before this alpha, I can shift it
> by a few days, but not a whole week since I'm on vacation for one week
> from June 2nd.

It's now implemented in the default branch :-)

Regards,

Vinay Sajip

___
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