[issue13771] HTTPSConnection __init__ super implementation causes recursion error

2012-02-04 Thread Michael Mulich

Michael Mulich michael.mul...@gmail.com added the comment:

Sure does. But that's the point of the package.

Why is this super usage without arguments considered a hack?


 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue13771
 ___

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13771
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13771] HTTPSConnection __init__ super implementation causes recursion error

2012-01-11 Thread Michael Mulich

New submission from Michael Mulich michael.mul...@gmail.com:

While working on porting wsgi_intercept to Python 3 I came across a recursion 
issue with http.client.HTTPSConnection. The following is an lesser extraction 
of the traceback:


Traceback (most recent call last):
  File .../wsgi_intercept/test/test_httplib.py, line 28, in test_success
http = self.make_one(self.domain)
  File .../wsgi_intercept/test/test_httplib.py, line 40, in make_one
return http.client.HTTPSConnection(*args)
  File .../lib/python3.2/http/client.py, line 1075, in __init__
source_address)
  ...
  File .../lib/python3.2/http/client.py, line 1075, in __init__
source_address)
  File .../lib/python3.2/http/client.py, line 1074, in __init__
super(HTTPSConnection, self).__init__(host, port, strict, timeout,
RuntimeError: maximum recursion depth exceeded while calling a Python object

Some background information is necessary to explain what is happening here. 
One, this is a traceback from a test method (make_one) which makes and https 
connection. Two, wsgi_intercept has overridden http.client.HTTPSConnection with 
a class that subclasses HTTPSConnection and overrides a few methonds. For more 
general information, see the PyPI page 
(http://pypi.python.org/pypi/wsgi_intercept). 

After the wsgi_intercept behavior is invoked the __mro__ of 
http.client.HTTPSConnection becomes: (class 
'wsgi_intercept.WSGI_HTTPSConnection', class 'http.client.HTTPSConnection', 
class 'http.client.HTTPConnection', class 'object'). Because of this we end 
up recursively running the __init__.

Possible solutions:

1) Fix the issue in http/client.py:1074 by replacing super(HTTPSConnection, 
self) with super(), which if I'm not mistaken is the recommended usage of 
super in Python 3.
2) Fix the issue in the wsgi_intercept package.

I was successful with both approaches, but applying the second fix would make 
the maintenance of wsgi_intercept slightly harder because of the code 
duplication and round-about-way of calling its parent classes.

--
components: None
messages: 151072
nosy: michael.mulich
priority: normal
severity: normal
status: open
title: HTTPSConnection __init__ super implementation causes recursion error
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13771
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8668] Packaging: add a 'develop' command

2011-07-12 Thread Michael Mulich

Michael Mulich michael.mul...@gmail.com added the comment:

On Tue, Jul 12, 2011 at 9:39 AM, higery rep...@bugs.python.org wrote:
 The develop command writes three pieces of information to the filesystem:
  1. It calls upon the build action(s) to build the package relative to
 the package's root directory.
  2. It calls the [build|install]_distinfo action to write the
 .dist-info metadata inside the build directory. (see also Issue 12279)
  3. It adds the build directory's path to a .pth file.


 You are right, what you listed above are also the things done by the
 'develop' command of my current implementation. In addition, as I replied
 earlier, we can also add a .distinfo-link file  more than the .pth file.

I don't like the idea of a .distinfo-link file. Would it even be
necessary if we already have a .pth entry?

We should probably just use one of these files, either .distinfo-link
or .pth. The .pth implementation has the least impact on code base and
is already implemented. If we add support for a .distinfo-link, we
would then need to modify database module to support that extension.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8668
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12532] PyPI server index names with '/' in them

2011-07-11 Thread Michael Mulich

New submission from Michael Mulich michael.mul...@gmail.com:

Forward slashes show up in a project's (packaging.pypi.dist.ReleaseList) name 
when using a crawler (packaging.pypi.simple.Crawler) against, say and Apache 
index page. The packaging.tests:/pypiserver/foo_bar_baz directory is a perfect 
example of this type of data, but it isn't used anywhere in the current tests.

If a crawl is run on the index, results will come back with '/' in there name.

The issue was found when I was attempting to use a Crawler against the 
packaging.tests.pypi_server.PyPIServer in my package's tests.

--
assignee: tarek
components: Distutils2
files: test_name.py
messages: 140117
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: PyPI server index names with '/' in them
versions: Python 3.3
Added file: http://bugs.python.org/file22621/test_name.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12532
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12532] PyPI server index names with '/' in them

2011-07-11 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
type:  - behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12532
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8668] Packaging: add a 'develop' command

2011-07-11 Thread Michael Mulich

Michael Mulich michael.mul...@gmail.com added the comment:

After looking over the use cases, these are my findings and questions:

* Cases 2, 3, 5 and 6 are strongly related. I'd suggest you condense them into 
a single use case. I agree with case 2 and 6 most, but have questions:
** Why wouldn't one simply use a virtualenv? -- Case 5 touches on this topic, 
but if we are installing in-place, who cares if can place a development package 
in the global site-packages directory?
** After the package has been installed in-place (using the develop command), 
how does one identify it as an in development project (or in development mode)? 
-- Case 3 and 6 touch on this topic (case 3 is a little vague at this time), 
but doesn't explain what type of action is intended. So if we install in-place 
(aka, develop), how does the python interpreter find the package? Are we using 
PYTHONPATH at this point (which would be contradict a requirement in  case 6)?

* Case 4 is a be unclear. Is Carl, the actor, pulling unreleased remote changes 
(hg pull --update) for these mercurial server plugins then running the develop 
command on them? 

* Case 1 is good and very clear, but I'd consider it a feature rather than 
required. Perhaps it should not be focused on first (priority). Thoughts?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8668
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12279] Add build_distinfo command to packaging

2011-07-11 Thread michael mulich

michael mulich michael.mul...@gmail.com added the comment:

We have to generate a RECORD, otherwise resource lookups in
development and testing modes will fail or at least should fail.

Yes, but that's not all.

 4) don’t add a build_distinfo command, just run install_distinfo to the build 
 dir from the test and develop commands

The action needs to be called with an install, develop or test
context, so I think item four is our best option.

--
nosy: +michael.mulich2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12279
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12279] Add build_distinfo command to packaging

2011-07-11 Thread michael mulich

michael mulich michael.mul...@gmail.com added the comment:

Gmail decided to strip the quotes... Grr...

   So, what do we do?
   1) don’t generate RECORD at all → invalid PEP 376
We have to generate a RECORD, otherwise resource lookups in
development and testing modes will fail or at least should fail.

   2) generate RECORD with paths to the files in the build dir
Yes, but that's not all.

   4) don’t add a build_distinfo command, just run install_distinfo
to the build dir from the test and develop commands

The action needs to be called with an install, develop or test
context, so I think item four is our best option.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12279
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12279] Add build_distinfo command to packaging

2011-07-11 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
nosy:  -michael.mulich2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12279
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12279] Add build_distinfo command to packaging

2011-07-11 Thread Michael Mulich

Michael Mulich michael.mul...@gmail.com added the comment:

On Mon, Jul 11, 2011 at 11:43 AM, Éric Araujo rep...@bugs.python.org wrote:
  What do you mean with context?  Wouldn’t all three commands just
make install_distinfo generate files in the build dir?

Right, my context comment is invalid.

  I think that option 4 is the most inelegant, and would be sad to see it win.
Ok... I forgot that we now have this RESOURCES file, which makes
leaving out the RECORD file less important, but still invalid based on
PEP 376.

So if we include the RECORD file (point number 2) without the checksum
and size (two columns in the RECORD csv format), we will still be
PEP376 valid (maybe?), but the file verification information will be
missing. And we don't really want this information because if we edit
a file, the checksum and size will be incorrect anyhow. This missing
information is not important when using the develop or test commands,
because we are running the commands on a trusted local copy. What are
the consequences of not writing the checksum or size to the RECORD
file? And does that solve the issue?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12279
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8668] Packaging: add a 'develop' command

2011-07-11 Thread Michael Mulich

Michael Mulich michael.mul...@gmail.com added the comment:

On Mon, Jul 11, 2011 at 1:14 PM, Carl Meyer rep...@bugs.python.org wrote:
 * Cases 2, 3, 5 and 6 are strongly related.
 I don't know. I don't consider case 3 useful, because I don't consider
 I don't want to use a virtualenv (without some clearer technical
 justification) to be a prejudice the develop feature needs to support;
 especially if supporting it essentially means re-implementing a
 less-capable version of virtualenv within the develop command.

I think your later comments about the use of .pth files solves the
issue for all four cases. We simply make reference in a .pth file in
one of the approved site locations. For example, in case two we would
write a .pth entry to site.USER_SITE. Sound about right?

 -- Case 5
 Several of these stories make the assumption that even the in-place
 installation will require placing a file in the installation location (a
 .pth file, if we follow the current setuptools implementation strategy).
 I think this is probably true, given the requirements in case 6 (which I
 agree with). So if you want an in-place install that's globally
 accessible, you'd need write access to global site-packages.

Basically write the .pth entry for the build to a site (the standard
lib module) recognized location.

 * Case 4
 Right, although the requirement for that story is that you don't have to
 re-run the develop command after every pull; if you develop-install it
 once, you can simply pull more code changes in and they'll immediately
 be available. I've added a line to that story to make it more clear.

Ah, this case impacts the decision being made in issue 12279
(http://bugs.python.org/issue12279). The decision is to write a RECORD
file or not. We wouldn't write a RECORD if you want to be able to
update without rerunning the develop command. But this would be
invalid based on PEP 376 guidelines. Please post your thoughts about
this in that issue.

The wiki page has been edited to note what the develop command will
write to the file system. I'll restate it here as well...

The develop command writes three pieces of information to the filesystem:
 1. It calls upon the build action(s) to build the package relative to
the package's root directory.
 2. It calls the [build|install]_distinfo action to write the
.dist-info metadata inside the build directory. (see also Issue 12279)
 3. It adds the build directory's path to a .pth file.

Thanks Carl

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8668
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12526] packaging.pypi.Crawler and resulting objects have a circular API

2011-07-10 Thread Michael Mulich

New submission from Michael Mulich michael.mul...@gmail.com:

The issue, as best I can describe it, is in how the a release list 
(packaging.pypi.dist.ReleaseList) looks up releases.

Here is a simple example using a random package on PyPI.

 crawler = Crawler()
 projects = crawler.search_projects('snimpy')
 projects
[Project snimpy]
 project = projects[0]
 [x for x in project]
[]

The results show that project 'snimpy' has no releases, but this is incorrect 
because distribution 'snimpy' has five releases.

Even after calling sort_releases and fetch_releases on the project which both 
refer back to the crawler instance (see the project's _index attribute) the 
project fails to get the releases.

 project.fetch_releases()
[]
 project.sort_releases()
 [x for x in project]
[]

In order to get the releases, one is forced to use the crawler's
API rather than the resulting project's API.

 crawler.get_releases(project.name, force_update=True)
Project snimpy versions: 0.5, 0.4, 0.3, 0.2.1, 0.2
 [x for x in project]
[snimpy 0.5, snimpy 0.4, snimpy 0.3, snimpy 0.2.1, snimpy 0.2]

So as far as I can gather, We lack the ability to forcibly update the project 
(or ReleaseList). I don't have a solution at this time, but we may want to look 
into adding a force_update argument to the get_release method on the Crawler.

--
assignee: tarek
components: Distutils2
messages: 140083
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: packaging.pypi.Crawler and resulting objects have a circular API
type: behavior
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12526
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12366] packaging.pypi.dist should abstract download errors.

2011-06-19 Thread Michael Mulich

New submission from Michael Mulich michael.mul...@gmail.com:

packaging.pypi.dist should abstract download errors, especially those from 
external sources. Download errors are currently reported from urllib. We should 
probably be using packaging.errors.PackagingPyPIError in this situation. Other 
suggestions?

Example case:

sake version 0.0.0 has a external download URL that throws a 404 (see also 
http://pypi.python.org/simple/sake/). When attempting to download this release, 
we receive a ValueError from urllib, which is not very detailed and could mean 
a number of things.

Traceback (most recent call last):
  ... [dev project] ...
  File .../cpython/Lib/packaging/pypi/dist.py, line 167, in download
.download(path=temp_path)
  File .../cpython/Lib/packaging/pypi/dist.py, line 302, in download
path + / + archive_name)
  File .../cpython/Lib/urllib/request.py, line 150, in urlretrieve
return _urlopener.retrieve(url, filename, reporthook, data)
  File .../cpython/Lib/urllib/request.py, line 1600, in retrieve
block = fp.read(bs)
ValueError: read of closed file

--
assignee: tarek
components: Distutils2
messages: 138658
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: packaging.pypi.dist should abstract download errors.
type: behavior
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12366
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12368] packaging.pypi.simple.Crawler assumes external download links are ok to follow

2011-06-19 Thread Michael Mulich

New submission from Michael Mulich michael.mul...@gmail.com:

The packaging.pypi.simple.Crawler blindly follows external download URLs. The 
crawler should honor a list of allowed hosts (see also the hosts parameter) 
before attempting to download from an external source.

Éric Araujo has also pointed out that established tools like easy_install and 
pip provide ways of allowing/restricting by host.

--
assignee: tarek
components: Distutils2
messages: 138663
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: packaging.pypi.simple.Crawler assumes external download links are ok to 
follow
type: behavior
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12368
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12279] Add build_distinfo command to packaging

2011-06-10 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
nosy: +michael.mulich

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12279
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8371] Add a command to download distributions

2011-06-09 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
nosy: +michael.mulich

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8371
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8501] --dry-run option doesn't work

2011-06-09 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
nosy: +michael.mulich

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8501
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8591] update mkpkg to latest coding standards

2011-06-09 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
nosy: +michael.mulich

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8591
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11880] add a {dist-info} category to distutils2

2011-06-09 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
nosy: +michael.mulich

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11880
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8668] Packaging: add a 'develop' command

2011-06-09 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
nosy: +michael.mulich

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8668
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12302] pysetup run test

2011-06-09 Thread Michael Mulich

New submission from Michael Mulich michael.mul...@gmail.com:

A package's metadata (dist-info) should be available to it while running the 
test command (pysetup run test)?

The use case:

I've written a test for a function that is supposed to find the default 
configuration or one provided in a users local area (or {userbase} as sysconfig 
puts it). As part of the test, I'm ensuring that the forcibly found default 
config is loaded correctly. The function that finds the configuration uses 
sysconfig paths (sysconfig.get_paths) which rely on the packaging database (PEP 
376 API now in packaging.database).

To find the default config, or resource in packaging terms, I'm using the 
packaging.database.get_file_path, which requires the distribution metadata 
(dist-info) be available within the Python path, because it must lookup the 
RESOURCES file.

I've started work, in my local clone. We lack a unittest for this case. I'll be 
writing it some time within the next few days.

I'd like to know where this RESOURCES file came from? I don't recall, nor see 
mention of it in PEP 376. I would also have expected to find something in 
packaging.command.install_distinfo command related to this file. The 
install_distinfo command is lacking this logic. I'll add it after the first 
half of this case working.

--
assignee: tarek
components: Distutils2
messages: 138032
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: pysetup run test
type: behavior
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12302
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12302] test command is not loading the distribution metadata

2011-06-09 Thread Michael Mulich

Changes by Michael Mulich michael.mul...@gmail.com:


--
title: pysetup run test - test command is not loading the distribution metadata

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12302
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12302] test command is not loading the distribution metadata

2011-06-09 Thread Michael Mulich

Michael Mulich michael.mul...@gmail.com added the comment:

The RESOURCES implement in install_distinfo command should probably be a 
separate case, no?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12302
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10884] pkgutil EggInfoDistribution requirements for .egg-info metadata

2011-06-08 Thread michael mulich

michael mulich michael.mul...@gmail.com added the comment:

Sure, I'll have a look. I'm only getting back into the swing of
things, but hopefully I can get more involved. Trying to do one or two
small tasks a night.

-Michael Mulich (pumazi)

On Mon, Jun 6, 2011 at 11:33 AM, Éric Araujo rep...@bugs.python.org wrote:

 Éric Araujo mer...@netwok.org added the comment:

 Can you check if this is covered in test_database?

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue10884
 ___


--
nosy: +michael.mulich2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10884
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10884] pkgutil EggInfoDistribution requirements for .egg-info metadata

2011-06-05 Thread Michael Mulich

Michael Mulich michael.mul...@gmail.com added the comment:

Looks like someone fixed this before distutils2 was merged into cpython as 
packaging. Thanks.

--
resolution:  - works for me
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10884
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue10884] pkgutil EggInfoDistribution requirements for .egg-info metadata

2011-01-10 Thread Michael Mulich

New submission from Michael Mulich michael.mul...@gmail.com:

Found an issue where the metadata initialization of .egg-info dirs (an 
EggInfoDistribution object) overrides the 'path' variable, which makes it 
impossible to find a distributions requirements.

I've fixed the issue at 
https://bitbucket.org/pumazi/distutils2-fixes/changeset/f3b5eb2aac2c (changeset 
also attached).

--
assignee: tarek
components: Distutils2
files: distutils2-fixes-f3b5eb2aac2c.diff
keywords: patch
messages: 125982
nosy: eric.araujo, pumazi, tarek
priority: normal
severity: normal
status: open
title: pkgutil EggInfoDistribution requirements for .egg-info metadata
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20351/distutils2-fixes-f3b5eb2aac2c.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10884
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com