> As for PEP 4: I don't know whether it needs to be listed there. It
> appears that the PEP is largely unmaintained (I, personally, do not
> really maintain it). So one option would be to just stop using PEP 4
> for recording deprecations, since we now have the warnings modul
es that goal.
my two cents,
Raymond
___
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
minate a small step or two from the eval-loop.
Those efforts should not be discarded lightly.
-1 on adding it directly.
-0 on adding it as a #ifdeffed compile option (with the default being to
exclude it).
Raymond Hettinger
___
Python-Dev mailing list
[EM
ferent cache effects than
the benchmarked loop.
For useful timings, run timeit on the specific feature in question.
Then check for overall impact using pybench, parrotbench, and
test_decimal.
Raymond
___
Python-Dev mailing list
[EMAIL PRO
gt;
> 2) Don't include the "Deprecated Modules Reference" in the standard
> distribution, but make it available as a separate download.
-1
We are trying to remove clutter, not keep it in perpetuity. Leaving the
docs means continuing to have to test it, field bug reports, be a
ack to specifics, it may be worthwhile to think through the
reason we kept the xmllib code but not whrandom. Both were documented,
non-buggy, tested, marked as deprecated for a long time, and it was
within the realm of possibility that some code still used them.
Also, the PEP should discuss t
One other thought: In deciding how long to leave module in, we should
consider that Python books are updated infrequently, if at all. It
would be a bummer if code in them stopped working as advertised.
Raymond
___
Python-Dev mailing list
[EMAIL
module around for another two versions.
>
> Why do you want to avoid that situation? What is the problem with
> waiting for two more versions? No harm is done in doing so.
If we really don't care whether it gets done, then we shouldn't bother
in the first place.
Raymond
_
phased out. I don't think it is good to leave active modules as
orphans.
Raymond
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
at it will take so
> long does not mean we should not start the process *now* - if we start
> the process in five years, it will *still* take 10 or 20 years. Just
> be patient.
I see. That also may useful to include in the motivation section of the
PEP.
W
rible thing to have someone say the superb productivity
gains come at the price of running slower than C. I would much rather
hear that than have people bag on the docs or standard library or launch
into a diatribe @decocrator destroying the beauty of the language.
Raymond
Acceptance for Py2.4 partially hinges on how quickly third party apps
have their binaries updated.
I wonder if there is anything we can do to help.
Raymond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Tuure Laurinolli
Sent: Tuesday, December 07
27;[EMAIL PROTECTED]
est_dir\\a'])
test_urllib.py
--
FAIL: test_basic (__main__.urlretrieve_FileTests)
--
Traceback (most recent call last):
File "test_urllib.py", line 142, in test_basic
sel
h "Python".
I always liked: "Python, the language that wraps tightly around a
problem and swallows it whole."
Raymond
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
lt the same way when reading it. Also, it seemed to embody the
political outlook that optimization is sinful. The document could be
much more positive, fact based, and informative. Also, the wording
seems somewhat outdated.
A draft for a new entry is included below. Review and feedback are
> > FWIW, the tests at issue pass on WinXP for me today w/ current CVS.
Tests pass here too.
Raymond
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
ace in struct module
http://www.python.org/sf/1072182
(assigned to me)
* fix bug in StringIO.truncate - length not changed
http://www.python.org/sf/951915
(assigned to me)
* Fix for off-by-one bug in urllib.URLopener.retrieve
http://www.python.org/sf/810023
> Raymond Hettinger wrote:
> > Perhaps a rather quick Py2.4.1 would be in order.
> >
> > Ideally, it should include other important fixes:
> [...]
> > * Fix for off-by-one bug in urllib.URLopener.retrieve
> >http://www.python.org/sf/810023
> >(ass
[Reinhold Birkenfeld]
> just felt a little bored and tried to review a few (no-brainer) patches.
Thanks, please assign to me and I'll apply them.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
o, it would partially breakdown the distinction between functions and
methods.
The behavior, on the other hand, would remain essentially the same (sans
type checking).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Would it be helpful for me to move the peepholer out of compile.c into a
separate source file?
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
omp_size, filenamesize, extra_size = fields
filename = g.getgroup('c', offset=16, times=filenamesize)
extra = g.getgroup('c', times=extra_size)
r.advance(comp_size)
print filename, hex(crc32), comp_size, uncomp_size
One other wrinkle is that "item" is itself a tuple and the whole thing
looks odd if unpacked:
((var0, var1, var2, var3), offset) = unpack_here(fmtstr, rec,
offset)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
> Instead, I would suggest that even a very limited initial
> implementation of StructReader() like object suggested by Raymond
would
> be more useful...
I have a draft patch also.
Let's work out improvements off-list (perhaps on ASPN).
Feel free to email me direc
est of the
CSV module because it also accepts/returns a list of fieldnames and a
sequence of records.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/362715
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
lso, it is not clear to me how or if existing manual adaption practices
should change. For example, if I need a file-like interface to a
string, I currently wrap it with StringIO. How will that change it the
future? By an explicit adapt/conform pair? Or by strings knowing how
to conform to fil
adapters
> think a bit more about the kind of adapter that they are providing.
Using optional arguments may not be the most elegant or extensible
approach. Perhaps a registry table or adapter attributes would fare
better.
Raymond Hettinger
___
Py
ne your plan. I hope your not planning on wrapping
all special method access as descriptor look-ups -- that would be a
somewhat radical change.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
ing object
> return getattr(self.__ref, name)
Instead of a __getattr__ solution, I recommend subclassing from a mixin:
class RichMap(SomePartialMapping, UserDict.DictMixin): pass
class RichFile(SomePartialFileClass, Mixins.FileMixin): pass
Raymond
_
pack the temporary argument tuple.
Even then, I don't see how to overcome the need to set useful default
values for optional object arguments.
Raymond Hettinger
___
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
than METH_O and METH_NOARGS,
* not handling more than nine arguments,
* separating function signature info from the function itself,
* the time to initialize all the argument variables to NULL,
* somewhat unattractive case stmt code for building the c function call.
Raymond
__
python.org/sf/1069160 )
> >
> > So, my question is: Is this important enough to delay a 2.4 final
> > for?
[Tim]
> Not according to me; said before I'd be happy if everyone pretended I
> hadn't filed that report until a month after 2.4 final was release
ce suggested syntactic support
differentiated from sequences but less awkward than a call to
itertools.islice().
itertools.islice(someseq, lo, hi) would be rendered as someseq'[lo:hi].
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
htt
[Anthony Baxter]
> >>> I'm
> >>> not aware of anyone having done a fix for the issue Tim identified
> >>> ( http://www.python.org/sf/1069160 )
[Raymond Hettinger]
> > Any chance of this getting fixed before 2.4.1 goes out in February?
[Timbot]
&
existing
near-optimal METH_O and METH_NOARGS code, doesn't mess with the
compiler, doesn't introduce new opcodes, doesn't alter import logic, and
doesn't muck-up existing extensions.
Raymond
"Until next week, keep your feet on the ground and keep reaching for th
nobody has reviewed the patch in detail yet.
Even if Guido were suffering from time machine induced hallucinations
that day, he still knew better than to go a full +1.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
prematurely immortalize design/implementation accidents); and
that they have only esoteric application (99.9% of programs won't need
them and should avoid them like the plague).
Calling it __internals__ will help emphasize that we are exposing
ess is there any reason this
needs to be done? Is there anything useful that currently cannot be
expressed without this new module?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
nts.
* Use b-trees instead of dictionaries (just kidding).
Raymond
___
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
[Anthony]
> While this is undoubtedly a bug fix, I'm not sure that it should be
> backported - it will break people's code that is "working" now (albeit
> in a faulty way). What do people think?
I concur -- the balance of risks is towards the patch causing m
released?
Just go to 2.3.6. No need to add a further complication to the
numbering scheme.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
r recognize the
> throwaway
> nature of lists
That's a good idea. Implementing it will be more straight-forward after
the AST branch gets completed.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
ormed to a single
lookup and dispatch (see MAL's note in pep 275).
Raymond
___
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
> Modified Files:
> Tag: release23-maint
> test_copy.py
> Log Message:
> fix bug 1114776
Don't forget release24-maint.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
Any objections to replacing the likes of types.IntType and
types.ListType with int and list?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
Feb 7 2005, 21:37:18) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
[Raymond]
> > > Remove the set conversion which didn't work with: [] in (0,)
[Jim]
> > Why is this a problem? If there were *any* unhashable objects
> > in the container, then the compiler would have bailed on the
> > initial set-conversion.
>
> >>
ocused on *consuming* iterators (IOW, extending the available standard
> accumulators beyond the existing min(), max() and sum() without further
> populating the builtins).
That would be nice. From the existing itertool recipes, good candidates would
include take(), all(), a
> but refactoring the contains code to use find_internal sounds like a
good
> first step. any takers?
>
>
I'm up for it.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
ntually get run even if no one is routinely using -u all.
Raymond
___
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
ct.
This is a more complicated than the original frozenset version of the
patch, so I would like to get feedback on whether you guys think it is
worth it.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
transformation idea should be carried a
step further so that a single step search operation replaces the linear
search.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
> > Raymond then
> translated
> >
> > for x in [1,2,3]:
> >
> > to
> >
> > for x in frozenset([1,2,3]):
That's not right. for-statements are not touched.
> I may be missing something here (didn't follow the whole thread) but
me. The part holding me
back is the introduction of searchset as a frozenset subtype and
teaching marshal how to put it a pyc file.
FWIW, some sample timings are included below (using frozenset to
approximate what searchset would do).
er algorithm and data structure -- hashing beats linear
search hands-down. The constant search time is faster for all n>1,
resulting in much improved scalability. No tweaking of
tuple.__contains__() can match it.
Sets are the right data structure for fast membership testing. I would
love for sets to be used internally while letting users continue to
write the clean looking code shown above.
Raymond
___
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
nt, float, complex}):
if opcode in {REPEAT, MIN_REPEAT, MAX_REPEAT}:
if (code in {301, 302, 303, 307} and m in {"GET", "HEAD"}:
if op in (ROT_TWO, POP_TOP, LOAD_FAST)
Perhaps something other notation would be better but the idea is
basically the same.
Raymond
_
7;'
> for Python syntax you'll see in the Nutshell -- top of p. 71, "The
> syntax of the class statement has a small, tricky difference from that
> of the def statement" etc.
+1 For me, this would come-up when experimenting with mixins. Adding and
removing a mixin usual
's the asymmetry with functions that gets to me - defining a
> > > function with no arguments still requires parentheses in the
> > > definition statement, but defining a class with no bases requires
the
> > > parentheses to be omitted.
>
> It'
uires string as left operand
This sort of thing is easy to test for and easy to fix. The question is
whether we care about updating this module anymore or is it a relic.
Also, is the use case one that we care about. AFAICT, this has never
come up before.
Raymond
n the standard library and test suite.
Raymond Hettinger
___
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
tch table is something like: [PyObject_Len,
PyObject_Repr, PyObject_IsInstance, PyObject_IsTrue, PyObject_GetIter,
...].
Of course, none of these offer a big boost and there is some loss of
dynamic behavior.
Raymond
___
Python-Dev mailing list
Python-Dev@python.
trospection and subclassing."
If we get a better implementation, it would be nice if the PEP were
updated with better examples. The TkInter example is weak because we
often want to set multiple defaults at the same time (foreground,
background, textsize,
functions, that part of "lambda is slower" is not relevant to the
comparison.
> Hmm, I'm starting to go round in circles here.
I also wish that partial() ran faster than closures, that it didn't have
limitations, and that it applied in more situations. C'est
r9 -s "from operator import itemgetter;
s=range(8); f=itemgetter(1)" "f(s)"
100 loops, best of 9: 0.806 usec per loop
C:\pydev>python -m timeit -r9 -s "s=range(8); f=lambda x:x[1]" "f(s)"
10 loops, best of 9: 1.18 usec per loop
So the savings is abo
far from its highest state of evolution.
Raymond
___
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
> > Along the way, they should assess whether
> > it is as applicable as expected, whether the existing limitations
are
> > problematic, and whether performance is an issue.
>
> Ah, so you question the specification, not the implementation of it.
My only issue with the PEP is that it seemed much
[Martin]
> It seems to me that the patch will be committed shortly, assuming
> somebody corrects the remaining flaws in the implementation. I could
> do that, but I would prefer if somebody contributed an updated patch.
Done.
Raymond
___
P
[Peter Harris]
> I look forward to the day when I can just use it.
You PEP is marked as final. The code has been checked in to CVS and
will be in Py2.5.
Congrats,
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
h
> 'plays
> nicely' with Decimal (but does not inherit from Decimal), since their
> __rop__
> methods never get called - Decimal's TypeError gets in the way.
Try to address this in a larger context than decimal. The same sort of
logic is pres
nother possible home for reduce.
If you want to add something new and useful to the functional module,
try a compose() function.
Raymond
___
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
ue was a pretty good
indicator that the code was doing something other than what the
programmer intended.
OTOH, there is almost certainly some existing, working code that would
stop working.
How about changing this to a warning in Py2.4?
Raymond
___
Pyt
, rank, proficiency
sorted(soldierdata, key=attrgetter('unit', 'rank', 'proficiency'))
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
arnings.warn("Call to deprecated function.")
> return func(*args, **kwargs)
newFunc.__name__ = func.__name__
newFunc.__doc__ = func.__doc__
newFunc.__dict__.update(func.__dict__)
> return newFunc
Raymond
__
rrectly, order would be determined by when the
key was first encountered. Presumably, that would mean that the related
value would also be the first encountered (not overridden by later-added
keys as dictated by your business requirements).
Raymond
he last
encountered. Starting with [(10, v1), (20, v2), (10.0, v3)], the
ordered dictionary's items would look like [(10, v3), (20, v2)].
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
to a regular
dictionary before ordereddict sees it.
Raymond Hettinger
___
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
any
thoughts on the design.
Raymond Hettinger
___
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
icate. Also, it avoids the kind of errors/confusion that people
currently experience with Python's unique implementation of "and" and
"or".
Returning the last element is not evil; it's just weird, unexpected, and
non-obvious. Resist the urge to get tricky with
nction can be moved to the functional module. The map() and filter()
functions are already covered by the itertools module.
Lambda will be more difficult. Eric Raymond adapted an anti-gun control
slogan and said "you can pry lambda out of my cold dead hands." A bunch
of folks will s
[Alex]
> If you're considering revisions to sum's design, my suggestion would
be
> to find a way to let the user tell sum to use a more accurate approach
> when summing floats.
FWIW, when accuracy is an issue, I use:
sum(sorted(data,
[Alex]
> > FWIW, when accuracy is an issue, I use:
> >
> >sum(sorted(data, key=abs))
>
> ...and you may still lose a LOT of accuracy that way:-(.
>
> Raymond, you technically reviewed the 2nd ed Cookbook -- don't you
> recall the sidebar abou
m.itervalues(), key=abs), 0.0)
The implementation can be tweaked to consume the error term right away
so the queue won't grow by more than few pending items. Also, the speed
can be boosted by localizing frexp, exp2sum.pop, and queue.append.
.0)
Aside from being a nice recipe, this was a good exercise in seeing what
pure Python can do with IEEE-754 guarantees. The modest memory
consumption and the typical O(n) runtime are a nice plus (no pun
intended).
Raymond
___
Python-Dev mailing list
Pyt
kwards.
-1
Sorry, I deem the proposal to be horrendous and hope it gets trounced
before it gets out of hand.
Raymond
___
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 use sum() quite a bit and have had no
disappointments with the current API.
Raymond
___
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
lity to descend through nested iterables (similar to
what os.walk does for directories). The one wrinkle is having a
stoplist argument to specify types that should be considered atomic
eventhough they might be iterable (strings for example).
Raymond Hettinger
___
s.
Set offset to -Emin to handle the full range of floats.
"""
cumv = 0L
for elem in seqn:
m, exp = frexp(abs(elem))
v = int(m * 2 ** 53) * 2L ** (exp + offset)
if cumv & v:
return False
cumv |= v
return True
Raymond
> I'm happy to announce the release of Python 2.4.1 (final).
Woohoo!
Raymond
___
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
> Tag: release24-maint
> handlers.py
> Log Message:
> Added optional encoding argument to File based handlers and improved
error
> handling for SysLogHandler
Are you sure you want to backport an API change and new fea
ns so he can help manage outstanding bugs and patches.
Raymond Hettinger
___
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%4
Does anyone know what has become of the following developers and perhaps
have their current email addresses? Are any of these folks still active
in Python development?
Ben Gertzfield
Charles G Waldman
Eric Price
Finn Bock
Ken Manheimer
Moshe Zadka
Raymond Hettinger
> [Raymond Hettinger]
> > Does anyone know what has become of the following developers and
perhaps
> > have their current email addresses?
[Tim Peters]
> How about we exploit that if someone is a Python developer on SF, they
> necessarily have an SF email address ($(SFNAME)@
bjects:
>>> class Boom(Exception):
pass
>>> x = 10
>>> if x != 5:
raise Boom("Value must be a five", x)
Traceback (most recent call last):
File "", line 2, in -toplevel-
raise Boom("Value must be a five", x)
Bo
bmit whichever is the most informative. For some changes, it is
easier to see the changed lines immediately above and below each other.
For others, it helps to be able to see the whole algorithm.
Raymond
___
Python-Dev mailing list
Pytho
am of Steve Bethard, Tim Lesher,
> and Tony Meyer. We're trying a collaborative approach to the
> summaries: each fortnight, we'll be getting together in a virtual
> smoke-filled back room to divide up the interesting threads.
Both your process and
lementation */
_PyUnicode_Fini();
#endif
Raymond Hettinger
___
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
lear-cut way to know which should be removed when
unregister() is called.
Likewise, I suspect that exposing the stack will create more pitfalls
and risks than it could provide in benefits. Dealing with a stack of
functions is likely to be clumsy at best.
Raymond Hettinger
__
[Raymond Hettinger]
> << Will mull it over for a while. My first impression is that
try/finally
> is a better tool for the scenario you outlined. >>
[Nick Jacobson]
> You're right. try/finally takes care of my sample scenario. There
may
> still be a case to
I haven't heard back from Greg Stein, Jim Fulton, or Paul Prescod.
If anyone can get in touch with them, that would be great.
I suspect that Jim may want to keep the commit privileges active
and that Paul and Greg are done with commits for the time being.
Raymond Hett
Thanks for the note.
Let me know if you need to be switched on again at some point.
Raymond Hettinger
> -Original Message-
> From: Paul Prescod [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 30, 2005 4:39 PM
> To: Raymond Hettinger
> Cc: python-dev@python.org
> Su
1001 - 1100 of 1495 matches
Mail list logo
