Status of the built-in virtualenv functionality in 3.3

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Status of the built-in virtualenv functionality in 3.3

Éric Araujo
Hi,

I started to play with virtualenv recently and wondered about the status
of the similar feature in 3.3 (cpythonv).  The last thread mentioned two
bugs; one has been fixed since.

Apart from the implicit vs. explicit download of distribute, are there
design issues to discuss?  Can we do that with a patch on a bug report?

Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
as it would shadow the third-party module name, and I’m not fond of
“virtualize”: it brings OS-level virtualization to my mind, not isolated
Python environments.

Cheers
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Christian Heimes-2
Am 06.10.2011 16:12, schrieb Éric Araujo:
> Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.

How about clutch? A virtualenv is a clutch of Python eggs, all ready to
hatch. (Pun intended). :)

Christian

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

briancurtin
In reply to this post by Éric Araujo
On Thu, Oct 6, 2011 at 09:12, Éric Araujo <[hidden email]> wrote:
> Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.

How about we just drop the "virtual" part of the name and make it "env"?

(or something non-virtual)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Barry Warsaw
In reply to this post by Éric Araujo
On Oct 06, 2011, at 04:12 PM, Éric Araujo wrote:

>I started to play with virtualenv recently and wondered about the status
>of the similar feature in 3.3 (cpythonv).  The last thread mentioned two
>bugs; one has been fixed since.
>
>Apart from the implicit vs. explicit download of distribute, are there
>design issues to discuss?  Can we do that with a patch on a bug report?
>
>Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
>as it would shadow the third-party module name, and I’m not fond of
>“virtualize”: it brings OS-level virtualization to my mind, not isolated
>Python environments.

Time to hit the hardware store and stock up on bikeshed paint!

I agree we can't use virtualenv, and shouldn't use virtualize.  I'm afraid
that picking something cute might make it harder to discover.  `pythonv` or
`cpythonv` seem like good choices to me.  Maybe the former, so we could
potentially have jythonv, etc.

-Barry
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Antoine Pitrou
In reply to this post by briancurtin
On Thu, 6 Oct 2011 10:06:17 -0500
Brian Curtin <[hidden email]> wrote:
> On Thu, Oct 6, 2011 at 09:12, Éric Araujo <[hidden email]> wrote:
> > Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
> > as it would shadow the third-party module name, and I’m not fond of
> > “virtualize”: it brings OS-level virtualization to my mind, not isolated
> > Python environments.
>
> How about we just drop the "virtual" part of the name and make it "env"?

"pythonenv"?


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Éric Araujo
In reply to this post by Barry Warsaw
Le 06/10/2011 17:31, Barry Warsaw a écrit :
> I agree we can't use virtualenv, and shouldn't use virtualize.  I'm afraid
> that picking something cute might make it harder to discover.  `pythonv` or
> `cpythonv` seem like good choices to me.  Maybe the former, so we could
> potentially have jythonv, etc.

I’m not sure we would.  The feature is two-fold:
- changes to getpath.c, site.py and other usual suspects so that CPython
supports being run in an isolated environment;
- a new module used to create isolated environments.

The first part is implemented in CPython; the second part needs a module
name to replace virtualenv.  python -m pythonv doesn’t seem right.

python -m makeenv?
python -m workon? (idea from virtualenvwrapper)
python -m nest?

Cheers
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

briancurtin
On Thu, Oct 6, 2011 at 10:46, Éric Araujo <[hidden email]> wrote:

> Le 06/10/2011 17:31, Barry Warsaw a écrit :
>> I agree we can't use virtualenv, and shouldn't use virtualize.  I'm afraid
>> that picking something cute might make it harder to discover.  `pythonv` or
>> `cpythonv` seem like good choices to me.  Maybe the former, so we could
>> potentially have jythonv, etc.
>
> I’m not sure we would.  The feature is two-fold:
> - changes to getpath.c, site.py and other usual suspects so that CPython
> supports being run in an isolated environment;
> - a new module used to create isolated environments.
>
> The first part is implemented in CPython; the second part needs a module
> name to replace virtualenv.  python -m pythonv doesn’t seem right.
>
> python -m makeenv?
> python -m workon? (idea from virtualenvwrapper)
> python -m nest?

develop? devenv?
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Barry Warsaw
In reply to this post by Éric Araujo
On Oct 06, 2011, at 05:46 PM, Éric Araujo wrote:

>Le 06/10/2011 17:31, Barry Warsaw a écrit :
>> I agree we can't use virtualenv, and shouldn't use virtualize.  I'm afraid
>> that picking something cute might make it harder to discover.  `pythonv` or
>> `cpythonv` seem like good choices to me.  Maybe the former, so we could
>> potentially have jythonv, etc.
>
>I’m not sure we would.  The feature is two-fold:
>- changes to getpath.c, site.py and other usual suspects so that CPython
>supports being run in an isolated environment;
>- a new module used to create isolated environments.

While the other implementations might not be able to share any of CPython's
code, it's still a worthy feature for any Python implementation I think.

>The first part is implemented in CPython; the second part needs a module
>name to replace virtualenv.  python -m pythonv doesn’t seem right.

Nope, although `python -m virtualize` seems about perfect.

I don't particularly like the -m interface though.  Yes, it should work, but I
also think there should be a command that basically wraps whatever the -m
invocation is, just for user friendliness.

>python -m makeenv?
>python -m workon? (idea from virtualenvwrapper)
>python -m nest?

Well, I have to be honest, I've *always* thought "nest" would be a good choice
for a feature like this, but years ago (IIRC) PJE wanted to reserve that term
for something else, which I'm not sure ever happened.

There's a PyNEST project here:

http://www.nest-initiative.uni-freiburg.de/index.php/PyNEST

which might cause problems with a built-in `nest` module.  Still, I'm a bit
fond of `python -m nest` and a `pynest` wrapper.

Barring that, `python -m virtualize` with an appropriate cli shortcut
(`pysolate`? - say it out loud :) seems good.

-Barry
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Antoine Pitrou
On Thu, 6 Oct 2011 12:02:05 -0400
Barry Warsaw <[hidden email]> wrote:
>
> >The first part is implemented in CPython; the second part needs a module
> >name to replace virtualenv.  python -m pythonv doesn’t seem right.
>
> Nope, although `python -m virtualize` seems about perfect.

`python -m sandbox` ?



_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Carl Meyer-4
In reply to this post by Éric Araujo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Éric,

Vinay is more up to date than I am on the current status of the
implementation. I need to update the PEP draft we worked on last spring
and get it posted (the WIP is at
https://bitbucket.org/carljm/pythonv-pep but is out of date with the
latest implementation work).

On 10/06/2011 08:12 AM, Éric Araujo wrote:
> Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.

What about "venv"? It's short, it's already commonly used colloquially
to refer to virtualenv so it makes an accurate and unambiguous mental
association, but AFAIK it is currently unused as a script or module name.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6N0+QACgkQ8W4rlRKtE2fCOwCg1YOWcMCZH6HOdyKepcQG3RgB
T48AoIIqol+sUpOAFI+4HJH/dAdX5Xwm
=DLjq
-----END PGP SIGNATURE-----
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

PJ Eby
In reply to this post by Barry Warsaw
On Thu, Oct 6, 2011 at 12:02 PM, Barry Warsaw <[hidden email]> wrote:
Well, I have to be honest, I've *always* thought "nest" would be a good choice
for a feature like this, but years ago (IIRC) PJE wanted to reserve that term
for something else, which I'm not sure ever happened.

Actually, it was pretty much for this exact purpose -- i.e. it was the idea of a virtual environment.  Ian just implemented it first, with some different ideas about configuration and activation.  Since this is basically the replacement for that, I don't have any objection to using the term here.  (In my vision, "nest" was also the name of a package management tool for creating such nests and manipulating their contents, though.)
 

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Vinay Sajip
In reply to this post by Éric Araujo
----- Original Message -----

> I started to play with virtualenv recently and wondered about the status
> of the similar feature in 3.3 (cpythonv).  The last thread mentioned two
> bugs; one has been fixed since.

The pythonv branch is pretty much up to date with the default branch (3.3). I regularly merge with default and post the results of running the Python regression suite in a virtual environment - in fact I'm running such a test right now :-). The test results and a screencast are linked from the project's BitBucket page at

https://bitbucket.org/vinay.sajip/pythonv/

> Apart from the implicit vs. explicit download of distribute, are there
> design issues to discuss?  Can we do that with a patch on a bug report?

I've made changes to get packaging to work well with virtualenv, some of which I raised as packaging issues on the tracker. In some cases, I've fixed them in the pythonv branch. The last bug is a problem with test_user_similar which has an existing issue (#9100) in a non-virtual environment. This is not a show-stopper, but I'm not really sure how the user scheme is supposed to work in venvs: perhaps Carl has a view on this. BTW there have been intermittent failures in test_packaging, too but they've generally been fixed by changes in core).


In terms of design issues, it would be useful if someone (apart from me that is) could look at how the pythonv fork differs from the core and comment on any issues they find. (Much of the change can be summed up as replacing occurrences of "sys.prefix" with "sys.getattr('site_prefix', sys.prefix)".)

BitBucket makes this type of comparison fairly easy to do; I'm not sure if there's a lot of value in adding a patch on the tracker for Rietveld review, until (and if) the PEP is accepted.


Re. distribute: At the moment the pythonv branch downloads a private version of distribute. The only significant difference from the vanilla distribute is the use of sys.site_prefix and sys.site_exec_prefix (falling back to sys.prefix and sys.exec_prefix if we're not running distribute in a virtual env, so it's backward compatible - but I didn't ask anyone in the packaging/distribute team to port this small change across. The only reference to sys.site_prefix is this code in setuptools/command/easy_install.py:

if hasattr(sys, 'site_prefix'):
    prefixes = [sys.site_prefix]
else:
    prefixes = [sys.prefix]
    if sys.exec_prefix != sys.prefix:
        prefixes.append(sys.exec_prefix)

If this were ported to distribute, that would be nice :-)

I think the plan is to remove the distribute-downloading functionality from the stdlib. However, I am working on a companion project, "nemo", which will have this functionality and in addition provides virtualenvwrapper-like functionality for Linux, Mac and Windows. (This is based on the stdlib API, is WIP, not released yet, though shown in the screencast I mentioned earlier).

> Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.

I'm OK with Carl's suggestion of "venv", and prefer it to Brian's suggestion of "env".

Regards,

Vinay Sajip

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Barry Warsaw
In reply to this post by Antoine Pitrou
On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote:

>On Thu, 6 Oct 2011 12:02:05 -0400
>Barry Warsaw <[hidden email]> wrote:
>>
>> >The first part is implemented in CPython; the second part needs a module
>> >name to replace virtualenv.  python -m pythonv doesn’t seem right.
>>
>> Nope, although `python -m virtualize` seems about perfect.
>
>`python -m sandbox` ?

That's nice too.

-Barry
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Lennart Regebro-2
+1 for env or sandbox or something else with "box" in it.

pythonbox? envbox? boxenv?
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Georg Brandl-2
In reply to this post by Barry Warsaw
On 10/06/11 18:02, Barry Warsaw wrote:

> On Oct 06, 2011, at 05:46 PM, Éric Araujo wrote:
>
>>Le 06/10/2011 17:31, Barry Warsaw a écrit :
>>> I agree we can't use virtualenv, and shouldn't use virtualize.  I'm afraid
>>> that picking something cute might make it harder to discover.  `pythonv` or
>>> `cpythonv` seem like good choices to me.  Maybe the former, so we could
>>> potentially have jythonv, etc.
>>
>>I’m not sure we would.  The feature is two-fold:
>>- changes to getpath.c, site.py and other usual suspects so that CPython
>>supports being run in an isolated environment;
>>- a new module used to create isolated environments.
>
> While the other implementations might not be able to share any of CPython's
> code, it's still a worthy feature for any Python implementation I think.
>
>>The first part is implemented in CPython; the second part needs a module
>>name to replace virtualenv.  python -m pythonv doesn’t seem right.
>
> Nope, although `python -m virtualize` seems about perfect.

Hmm, with proper interpreter support I don't see what would be so "virtual"
about it anymore.

Georg

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Paul Moore
In reply to this post by Barry Warsaw
On 6 October 2011 17:02, Barry Warsaw <[hidden email]> wrote:
> I don't particularly like the -m interface though.  Yes, it should work, but I
> also think there should be a command that basically wraps whatever the -m
> invocation is, just for user friendliness.

No problem with a wrapper, but the nice thing about the -m form is
that it's portable. On Unix, shell script wrappers are pretty portable
(no idea if C-shell users would agree...) On Windows, though, there
are all sorts of problems. BAT files don't nest, so you end up having
to use atrocities like "CALL virtualenv" within a batch file.
Powershell users prefer .ps1 files. The only common form is an EXE,
but nobody really likes having to use a compiled form every time.

Paul.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Vinay Sajip
In reply to this post by Éric Araujo
Éric Araujo <merwok <at> netwok.org> writes:


> Oh, let’s not forget naming.  We can’t reuse the module name virtualenv
> as it would shadow the third-party module name, and I’m not fond of
> “virtualize”: it brings OS-level virtualization to my mind, not isolated
> Python environments.

Another possible name would be "isolate":

python -m isolate /project/env

doesn't look too bad. There's no eponymous package on PyPI, and note also that
in addition to the common usage of isolate as a verb, it's also a noun with an
appropriate meaning in this context.

Regards,

Vinay Sajip




_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Nick Coghlan
In reply to this post by Barry Warsaw
On Thu, Oct 6, 2011 at 12:50 PM, Barry Warsaw <[hidden email]> wrote:

> On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote:
>
>>On Thu, 6 Oct 2011 12:02:05 -0400
>>Barry Warsaw <[hidden email]> wrote:
>>>
>>> >The first part is implemented in CPython; the second part needs a module
>>> >name to replace virtualenv.  python -m pythonv doesn’t seem right.
>>>
>>> Nope, although `python -m virtualize` seems about perfect.
>>
>>`python -m sandbox` ?
>
> That's nice too.

sandbox is a bit close to Victor's pysandbox for restricted execution
environments.

'nest' would probably work, although I don't recall the 'egg'
nomenclature featuring heavily in the current zipimport or packaging
docs, so it may be a little obscure.

'pyenv' is another possible colour for the shed, although a quick
Google search suggests that may have few name clash problems.

'appenv' would be yet another colour, since that focuses on the idea
of 'environment per application'.

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Carl Meyer-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/06/2011 12:12 PM, Nick Coghlan wrote:

> sandbox is a bit close to Victor's pysandbox for restricted execution
> environments.
>
> 'nest' would probably work, although I don't recall the 'egg'
> nomenclature featuring heavily in the current zipimport or packaging
> docs, so it may be a little obscure.
>
> 'pyenv' is another possible colour for the shed, although a quick
> Google search suggests that may have few name clash problems.
>
> 'appenv' would be yet another colour, since that focuses on the idea
> of 'environment per application'.

I still think 'venv' is preferable to any of the other options proposed
thus far. It makes the virtualenv "ancestry" clearer, doesn't repeat
"py" (which seems entirely unnecessary in the name of a stdlib module,
though it could be prepended to a script name if we do a script), and
doesn't try to introduce new semantic baggage to the concept, which is
already familiar to most Python devs under the name "virtualenv".

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6N9H4ACgkQ8W4rlRKtE2doVACcChCim7CNS0czZisjEmw9NblS
MqkAn1FyT+A/UiKodCh1siHrQXf2/yZQ
=TAUV
-----END PGP SIGNATURE-----
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Status of the built-in virtualenv functionality in 3.3

Barry Warsaw
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Oct 06, 2011, at 12:33 PM, Carl Meyer wrote:

>I still think 'venv' is preferable to any of the other options proposed
>thus far.

It's also nicely unique for googling.  Funnily enough, the top hit right now
for 'venv' is apparently Lua's project of the same name for the same purpose.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJOjfwcAAoJEBJutWOnSwa/JRwQALLgtxOAmI9dhgaxudZgsDS7
ZeyaKFTDp2gnteMwXPFv2KK0n1SCsCIzOj807xel8id2Mr5R4FeoBC/HmySSsbxv
2U29QxXHAl/a3pZ50C5a3O7ZV4DShXuPQC/Y430PkwAkrP1ydb/I7KQEgmvHe2A1
UJQ1zbdX+gadk6n9sUo7NuEtvL7lMQdDeGLXvflqRJrVLeGxYV3AHwjByBE6MggU
n5tZNv5G/H4fr/pD0SoMlI7MKoWRJkdqAeo3ASySVDn8LXe9UNjJb21YW18RyZPv
qcdTzD4NYLJy5FQCmG9N2mOGwUjvrt82kLkcoKcNBekY5TfELshlqgqn31n+bxPo
yV4Mr2IFOpRFTW218hwPbpEGK6Mfe03AV59Qey0zSKOsiJPUiPhXu9XdozvlF+Bx
7OdvhTe2nQBf8lp/KaKj4uZnnAvA9C8mMoukn6ly0Kk0EcDw81Ls9nMYxg/3gH7b
0SfvJH+8uQBjXF24Ce/xQkm6D7cB5e9GeilruH9VZ4LfZXYpP7jMdvWhW0g2S4PD
KJWChqetOajJBZmWWK0vSBuLAjVxJTZ0Y5q0k9BNOiFj8/5v3QvpCAXQFFv7LTcX
RDPI8rk73qjZiyAsVHMOmjSZfpY3aJnhPVMBSn0++yCzWx+YQbPwWkt6VihC6Ve4
Od0WX6XSEEu5BxJYaM/v
=/f38
-----END PGP SIGNATURE-----
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
12