Gustavo Niemeyer gustavo at niemeyer.net writes:
The StreamHandler available under the logging package is currently
catching all exceptions under the emit() method call. In the
Handler.handleError() documentation it's mentioned that it's
implemented like that because users do not care about
subclass and do everything inline,
as Skip has mentioned. And if one wants this functionality, and don't check on
every call, when would be a good time to check?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http
with
the same benefit as in the general case (I think).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
to avoid expensive
thread and process computations where not needed. The 'extra' mechanism will
remain to provide additional diagnostic information where e.g. the same code is
executed by multiple threads and there is a need to distinguish the different
threads in the logging output.
Regards,
Vinay
but StreamHandler and
FileHandler are defined in the handlers module.
In general, patches are gratefully received! If you don't want to invest too
much time up front, send me a mail indicating your general approach and
we'll discuss.
Best regards,
Vinay Sajip
be done). I'll readily declare an interest - I've implemented an
alternative hierarchical config module (which is in no way backward compatible
with ConfigParser), see
http://www.red-dove.com/python_config.html
Regards,
Vinay Sajip
___
Python-Dev
to know is, what happens how? There are a whole lot of
alternatives put forward in the ConfigParserShootout wiki page, but how do we
move things forward from here?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http
to build the documentation - I've not been able to
get a trouble-free setup of the docs toolchain on Windows.
Thanks for this,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
will elaborate on the class docstring to explain the usage
in a bit more detail, as well as of course detailing it in the docs in a
separate section entitled Passing contextual information to the log (or
similar).
Best regards,
Vinay Sajip
___
Python
involved in the PEP.
Added as PEP 404 - hope y'all can find it ;-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
the responsibility for supporting additional shells or helper scripts.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
a package with all its code in
venv/__init__.py and a scripts.zip adjacent to that. Does that seem like a
better solution? Can anyone suggest better alternatives? Sorry if this has come
up before and I've missed something obvious.
Regards,
Vinay Sajip
as a zip file once deployed.
It was a general point about data that I was making; in this particular case,
that data just happens to be source code.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
approach, it is straightforward
for third party tools to either easily replace completely, update selectively or
augment simply the scripts provided by base classes.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
code.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
I'm not saying you couldn't do this with e.g. directory trees; it just seems
neater to have the scripts in a black box once they're deployed, with a zip file
representing that black box.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev
the answer is run
pysetup run bdist_wininst on it. If that breaks (as it is likely to -
wininst format isn't very flexible) then tough, you're out of luck.
Yes, that's what I was getting at.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev
this particular pony. If bdist_pony is
easy enough to use and doesn't close any existing doors, then there's no obvious
reason why distribution authors wouldn't use it for future releases of their
distributions.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python
limitation.
You're right that it's not an inherent limitation, but I'm not sure which bug
you're referring to. Do you mean just a current limitation?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
discussing.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
from, right?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Python gets to run the script).
I've changed the implementation now to use a directory tree, and the API takes
the absolute pathname of the directory containing the scripts.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http
have mode 644, as expected.
This happens on two different Posix machines - Ubuntu Natty and OS X Leopard
- so doesn't seem to be related to the external environment.
Can anyone shed any light as to what might be going on?
Regards,
Vinay Sajip
Charles-François Natali neologix at free.fr writes:
It's a consequence of http://hg.python.org/cpython/rev/740baff4f169.
I'll fix that.
Should a new issue be opened (or #13303 re-opened) pending this fix?
Regards,
Vinay Sajip
___
Python-Dev
summary = New Environments Made, Obviously
description = A tool to manage virtual environments
download_url = UNKNOWN
home_page = https://bitbucket.org/vinay.sajip/nemo
author = Vinay Sajip
author_email = vinay_sa...@yahoo.co.uk
license = BSD
classifier = Development Status :: 3 - Alpha
.)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
] Access is denied:
'c:\\Users\\Vinay\\Projects\\pythonv\\build\\test_python_3532\\@test_3532_tmp'
Sorry if this has come up before, but why do we couple the tests in this way,
so
that failure to clean up in one test causes drive-by failures in other,
unrelated tests?
Regards,
Vinay Sajip
to determine :-(
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
to indicate the version dependency.
It's certainly feasible, but needs specifying in more detail ...
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
? :)
Actually you need Carl Meyer's agreement, not mine - he's the one writing the
PEP. But I'm in favour :-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
, but to
an anonymous object - this is set in SimpleLazyObject.__init__).
Puzzling!
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
the workaround suggested in the issue.
Yes, that workaround worked. Good catch - thanks!
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
, because some
variant of a package will still have to use u() and b(), just for 3.2 support.
I'm not arguing against your proposed change itself - just against your point
about the relevance of 3.2.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python
.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
on the hunch that the elephant was only a chocolate elephant, and not a
real one. Time will of course tell ;-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
development session. That, along with some more/smarter fixers,
could go some way to addressing the too slow issue.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
it isn't a real performance problem, I'm just asking
where the evidence is, whether running on PyPy or elsewhere.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
, which is why
the fixers currently generate imports from django.utils.py3. Obviously, I'll
change this in due course.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
give any one here who's interested a chance to comment, in case they can spot
any shortcomings of the approach I suggest.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Antoine Pitrou solipsis at pitrou.net writes:
def filename(self, name) sounds like a poor method name.
You're right - perhaps def rotation_filename(self, default_name) is better.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev
(as in the ActiveState example).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
for the current behaviour? If
there isn't one, I'll raise an issue.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
hard to use ...
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
concurrently/asynchronously, so the proc.wait()
and subsequent processing happens at a different time and place to the kick-off.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
been using them like that, in general. But reading those two
sentences above made the light bulb come on :-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Martin v. Löwis martin at v.loewis.de writes:
One way of providing this might be a u mode for open, which
updates an existing file on close (unlike a, which appends,
and unlike w, which truncates first).
Doesn't r+ cover this?
Regards,
Vinay Sajip
.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
).
Even if you have arguments against this idea, I think it's at least worth
mentioning in the PEP with any counter-arguments you have.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Serhiy Storchaka storchaka at gmail.com writes:
n = str
Well, n to indicate that native string is required.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
, especially if it speeds
transition to 3.x.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
somewhat in the PEP,
it would be nice to see the suggested on-installation hook fleshed out a little
more.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
-and-run contributors without changes, ISTM that could
compromise the quality of the codebase somewhat.
Also, is not the overall impact on the codebase of hit-and-run contributors
small compared to more the impact from involved contributors?
Regards,
Vinay Sajip
/logutils/
I will add a section in the logging cookbook about support for alternative
formatting styles. I thought I already had, but on inspection, it appears not to
be the case.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http
to dictionaries and wraps their result
with a list() because 3.x produces iterators where 2.x produces lists. This has
caused problems in practice, e.g. with Django where IIRC calls to the values()
method of querysets were wrapped with list(), when it was wrong to do so.
Regards,
Vinay Sajip
the right thing (as we see it), but wishing don't make it so.
Do I sense a certain amount of worry about the pace of the 2.x - 3.x
transition? It feels like we're blinking first ;-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev
of the
2.x - 3.x transition, we can appease these views fairly easily, so why not do
it? And while we're at it, we can perhaps also look at those pesky exception
clauses and see if we can't get 3.x to support 2.x exception syntax, to make
that porting job even easier ;-)
Regards,
Vinay Sajip
) in the
discussion so far.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
can't just edit-and-test, which to me
is the main benefit of a single codebase.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
it should work within the
constraints you mentioned for your software.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
as keys in a kwargs dictionary, or some API that wants you to use
str explicitly. But at least some of those places will be things you would have
to address anyway, when porting, whatever the state of Unicode literal support.
Regards,
Vinay Sajip
experience ;-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
. My particular interest is w.r.t. the installation hook for 3.2 and the
workflow for testing code in 3.2 and 3.3 at the same time.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
): return literal.encode('utf-8')
on Python 2.
I'm not saying this is the right thing to do for all cases - just that str() may
not be, either. This should be elaborated in the PEP.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
u'xxx' less pretty than 'xxx' for text.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
can.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Nick Coghlan ncoghlan at gmail.com writes:
On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip vinay_sajip at yahoo.co.uk
wrote:
If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
potentially involve running a fixer on all files in the project every time a
change is made
, but I seem to recall having
problems with some of the cookie APIs insisting on native strings (rather than
text, which is validated against ASCII where appropriate).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http
(of
course there can be pathological cases), so the number of calls to n() or
whatever it's called is unlikely to have any significant impact. Even when I was
using u() calls with the 2.5 port - which are of course much more common - the
performance impact was unremarkable.
Regards,
Vinay Sajip
a lot of time spent on this (at
least, in my experience). Having a good test suite helps catch those byte-string
cases more easily, of course.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
prompted the PEP in the first place.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
against 2.7 or 3.2, and sometimes they
even apply clearly to both).
Fixes may be trivial, but new features might not always be so.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
on those, how
does it propose to do that, independently of my editing tools?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
well with Python 2.6.
Let's hope not. We can mitigate that by spelling out in the docs that there's
no one right way, how to choose which approach is best for a given project, and
so on.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev
currently.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
support :-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
bothering
with, and that I do not find to be true based on my own experience.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
to your apparent bewilderment at some
of the reaction to the PEP.
I have confidence that with your continued input and Nick's input, the wording
of the PEP can be made such that it doesn't ruffle quite so many feathers. I'm
looking forward to seeing the updates.
Regards,
Vinay Sajip
these APIs as they are indefinitely, and
perhaps using a marker like n('xxx') for native strings would help to remind us
that these areas need addressing at some point.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http
in a relevant problem domain, unicode_literals
and native string markers would appear not to adversely impact readability or
performance.
Your comments would be appreciated.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http
, and use native string markers where you need to
message has received anything like the same level of airplay. If you talk to
people who have *actually tried* this approach (say Barry, or me) you'll hear
that it's not been all that rough a ride.
Regards,
Vinay Sajip
forward about porting from 2.x - 3.x, as others
have done - that's not OT, is it?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
3 and the latest versions of Python 2. In terms of practicality, it is
IMO quite practical (assuming 2.5 / earlier support can be dropped) to move to a
2.6+/3.x-friendly codebase, e.g. by using Armin's python-modernize.
Regards,
Vinay Sajip
___
Python
was needed), and then, when it
appeared likely that Django would drop 2.5 support after 1.4, I wrote a fixer to
go from u('xxx') to 'xxx'. Once I learned to use lib2to3, with a few pointers
from Benjamin, it worked like a charm for me.
Regards,
Vinay Sajip
for this error.
It's because you're using the free Express edition of Visual Studio, and not
the full, paid-for Visual Studio.
However, I believe you can ignore the error, and the solution should still be
built. (I'm not absolutely sure, as I use the full Visual Studio).
Regards,
Vinay Sajip
3.3 right now (before the PEP gets
implemented).
Please take a look at it, try it out, and give some feedback.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
this can be added without too much trouble.
Thanks for the feedback.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
for
their use cases and development work processes.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
of its effect on the transformed code, what are the
differences between this hook and running 2to3 with just the fix_unicode fixer?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
before it's even got going.
Regards,
Vinay Sajip
It is not enough merely to win; others must lose. - Gore Vidal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
is not overwritten.
Before raising an issue I thought I'd check here, in case it's something to do
with my configuration. Can anyone else confirm my findings?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
it - thanks. I uninstalled, removed the key from the
SharedDLLs (it was still there with a refcount of 1, as per your analysis),
reinstalled and uninstalled - all is well.
I did raise an issue but I'll go and close it now. Thanks for the help.
Regards,
Vinay Sajip
figures.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
mentioned in my other post, I happened to have the Django test suite
figures to hand, and to my mind they suited the purpose of showing that wrapper
calls, in the overall mix, don't seem to have a noticeable impact (whereas they
do, in a microbenchmark).
Regards,
Vinay Sajip
.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
of resolving open issues.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
as objectionable.
Regards,
Vinay Sajip
[1] http://bugs.python.org/issue14452
[2] http://bugs.python.org/issue7077
[3] http://bugs.python.org/issue8795
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
not private).
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
be appreciated.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
1 - 100 of 425 matches
Mail list logo
