python.org/dev/library/collections.html#abcs-abstract-base-classes
I would like all of the targets to have meaningful names.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
interfere with the automatically
generated names if their names are the same. The solution was
to *remove* the manually generated anchor points.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
ooglers and only one has put a Google
copyright notice in the source.
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
[Raymond Hettinger]
I'm at a loss of why the notice needs to be there at all.
[GvR]
There's a difference between contributing a whole file and
contributing a patch. Patches do not require copyright notices. Whole
files do. This is not affected by later edits to the file.
That m
the post, but I consider it
to be a good practice to introduce oneself when posting the first
time, so: Hello, my name is Konrad, I'm an IT student and I'm
following python-dev for some time, but never posted before.
Hello Konrad. Welcome to python-dev.
Raymond Hettinger
___
ed by operator.mul:
operator.mul('abc', 3) --> 'abcabcabc'
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
Raymond Hettinger wrote:
Since I expect students to be among the users for the comb/perm
functions, there is some merit to keeping the API as simple as possible.
Besides, it is not hard to use the existing tool as a primitive to get to
the one you want:
def mycombinations(iterable, r_seq
For Py3.0.1, can we just rip these out and skip deprecation?
I don't think they will be missed at all.
Raymond
- Original Message -
From: "Guido van Rossum"
To: "Nick Coghlan"
Cc:
Sent: Sunday, January 25, 2009 2:50 PM
Subject: Re: [Python-Dev] Operator
backporting several module improvements already in 3.1, including two new
itertools and one collections class. These are already fully documented, tested, and checked-in to 3.1 and it would be ashamed to
let them sit idle for a year or so, when the module updates are already ready-to-ship.
Raymond
API fixes, huge performance fixes, and whatnot).
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
ny chips in the paint.
If 3.1 goes out right away, then it doesn't matter if 3.0 looks ridiculous.
All eyes go to the latest release. Better to get this done before more
people download 3.0 to kick the tires.
Raymond
___
Python-Dev
;>
None of those ideas can be run through eval, nor do they identify the type of
iterator. Perhaps these would be better:
or
iter(['A', 'B', 'C', 'D', 'E', 'F'])
Do you guys have any thoughts on the subject?
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
[Guido van Rossum]
My only thought is that whatever you do, target Python 3.1, not 3.0.1.
Of course.
Do you have any thoughts on the most useful display format?
What do you want to see from pprint(mydict.items())?
Raymond
___
Python-Dev
r
to adoption in a production environment.
How far away is it?
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%4
[Antoine Pitrou]
Now here are some performance figures. Text I/O is done in utf-8 with universal
newlines enabled:
That's a substantial boost.
How does it compare to Py2.x equivalents?
Raymond
___
Python-Dev mailing list
Python-Dev@pytho
gets called 3.1, the nice side effect for me is that my itertools updates
get fielded a bit sooner. But that is a somewhat unimportant consideration.
I really have no opinion on what the next release gets called.
Raymond
___
Python-Dev mailing list
P
case because it is IMO a broken release.
AFAICT, it is not in any distro yet. Hopefully, no one will keep it around
and it will vanish silently.
Raymond
- Original Message -
I have no problem with removing things that were advertised and/or
documented to be removed in 3.0 but acciden
nd won't change. So, the speedup doesn't really affect whether
the release gets named 3.0.1 or 3.1. The important part is that
we get it out as soon as it's solid so that we don't preclude adoption
by users who need fast IO.
Raymond
___
question on this batch.
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
[Adam Olsen]
It'd also help if the file repr gave the encoding:
+1 from me too. That will be a big help.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
just did something simple with the pattern newline-tab. It worked, it
stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my
embedded base. The rest, sadly, is history." -- Stuart Feldman
"""
[i] = '"%s"' % args[i]
TypeError: 'str' object does not support item assignment
1 test failed:
test_distutils
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
[Tarek Ziadé]
That's me. I'll fix this problem right now.
Thanks. I appreciate it.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
benefits of the fixes.
Barry, are you actively opposed to marking 3.0.x as experimental, or do
you just dislike it? (I.e. are you -1 or -0?)
My preference is to *not* mark it as experimental. Instead, I prefer
doing what it takes to make the 3.0.x series viable.
Raymond
__
with the
expectation it'll be built into 3.1.
Will do. That was my original plan since the day bsddb got ripped out.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
l sqlite. To me, that is something a little
different than changing a pickle protocol or somesuch.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
playhook).
Just wanted to provide some early feedback based on my experiences
heavily exercising 3.0.
Raymond
P.S. My other experience with 3.0 is that my most frequent error has
changed. It used to be that the number reason for my getting a syntax
error was leaving-off a colon. Now, my number one
[Guido van Rossum]
Sorry, not convinced.
No worries. Py3.1 is not far off.
Just so I'm clear. Are you thinking that 3.0.x will never have
fast shelves, or are you thinking 3.0.2 or 3.0.3 after some
external deployment and battle-testing for the module?
Ra
[Hrvoje Niksic]
The one thing missing from the array
module is the ability to directly access array values from C.
Please put a feature request on the bug tracker.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
an equivalent lambda. IMO, lambda has
an advantage over partial.skip() because the lambda is easier to read:
modcubes = lambda base, mod: pow(base, 3, mod)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
illed with lots of
red-outlined pink-boxed warning signs, effectively communicating that Python itself is dangerous and unreliable.
Raymond
-
Happy FUN BALL! -only $14.95-
Warning: Pregnant women, the elderly and children under 10 should avoid
prolonged exposu
On Jul 30, 2011, at 11:28 PM, Georg Brandl wrote:
>
> (Also, there must have been some reason to make "..." available everywhere
> for Python 3.)
>
It's really nice for stub functions:
def foo(x):
...
Raymond
On Aug 10, 2011, at 4:15 AM, Nick Coghlan wrote:
>> After implementing the aforementioned step 5, you will find that the
>> performance of everything, including the threaded code, will be quite a bit
>> worse. Frankly, this is probably the most significant obstacle to have any
>> kind of GIL-
ge.
>
> Agreed. Also, flat is better than nested. Whoever wants to populate the
> concurrent package should work on new features to be added to it, rather
> than plans to rename things around.
I concur.
Raymond
___
Python-Dev mailing list
On Aug 10, 2011, at 1:58 PM, Ezio Melotti wrote:
> we would have to update all the links manually to link to h.p.o instead of
> s.p.o.
sed is your friend.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
another return style makes the C API harder to learn and remember.
If we we're starting from scratch, Py_RETURN(obj) would make sense.
But we're not starting from scratch, so we should stick with the precedents.
Raymond
___
Python-Dev ma
weird to call something UCS-2 if code points above 65535 are
representable.
The naming convention for codecs is that the UTF prefix is used for lossless
encodings that cover the entire range of Unicode.
"The first amendment to the original editio
On Sep 6, 2011, at 1:36 PM, Martin v. Löwis wrote:
> I think this is what people underestimate. I can't name
> applications either - but that doesn't mean they don't exist.
Google code search is pretty good indicator that this method
has near zero uptake. If it dies, I don't think anyone will
ange() that creates floats.
That works reasonably well if the default argument pattern is the same as
range: frange(10.0, 20.0, 0.5)
There could be an optional argument to compute the interval: frange(10.0,
20.0, numpoints=20)
And possibly a option to include both endpoints: frange(10.
On Sep 27, 2011, at 3:22 PM, Ethan Furman wrote:
> Well, actually, I'd be using it with dates. ;)
FWIW, an approach using itertools is pretty general but even it doesn't work
for dates :-)
>>> from itertools import count, takewhile
>>> from decimal import Decimal
>>> from fractions import Fra
d instead, which
> I will, but I still find that uglier than +=. I would submit a patch
> to implement __iadd__, but I first want to know if that's considered
> the right behavior, since it changes the semantics of +=:
Yes, update() is the
l bugs, that's fine, but as MvL often
> points out, even innocent looking changes can break code *somewhere*. We
> don't lose by being conservative with our stable branches.
>
> -Barry
I concur with Barry and MvL. Random code cleanups increas
pplied to Py2.7 and Py3.2.
We don't backport API changes. That would just make Jython
and IronPython become non-compliant in mid-stream.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
; If anybody has spare time at their hands, they should go through the
> code base and eliminate all uses of concrete API where it's not certain
> that the object really is of the base class (unless I missed that
> somebody already did, and that any remaining occurrences would be just
>
; Needs work?
You could try a more positive leadership style: THAT LOOKS GREAT, I'M SURE THE
RM FOR PYTHON 3.5 WILL LOVE IT ;-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
On Nov 25, 2011, at 6:18 PM, Jesus Cea wrote:
> On 12/11/11 16:56, Éric Araujo wrote:
>> Ezio and I chatted a bit about his on IRC and he may try to write
>> a Python parser for Misc/NEWS in order to write a fully automated
>> merge tool.
>
> Anything new in this front? :-)
To me, it would make
On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote:
> Hi,
> our current deprecation policy is not so well defined (see e.g. [0]), and it
> seems to me that it's something like:
> 1) deprecate something and add a DeprecationWarning;
> 2) forget about it after a while;
> 3) wait a few versions unt
docs for an example of good writing. The prevention of SQL
injection attacks is discussed briefly and effectively without big red boxes
littering the page.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
On Dec 6, 2011, at 7:23 PM, Cameron Simpson wrote:
> This assures that files are flushed [...]
>
> It does not. It _ensures_ that files are flushed. The doco style "affirmative
> tone" _assures_. The coding practice _ensures_!
>
> Pedanticly,
> --
> Cameron Simpson
I can assure you that I'v
vior).
+1 on changing the batty behavior.
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
doctests, book examples
not matching actual dict reprs, and on efforts by users to optimize
the insertion order into dicts with frequent lookups.
Raymond
On Dec 28, 2011, at 5:28 PM, Michael Foord wrote:
> Hello all,
>
> A paper (well, presentation) has been published highlighting
else {
>statement;
> }
Really? Do we need to have a brace war?
People have different preferences.
The standard library includes some of both styles
depending on what the maintainer thought was cleanest to their eyes in a given
context.
Raymond
27;ve happily lived with a
mixture of styles for a very long time.
ISTM, our committers have had good instincts about when braces add clarity and
when they add clutter.
If Nick pushes through an always-use-braces mandate, A LOT of code will need to
be changed.
Raymond
___
On Jan 2, 2012, at 2:09 PM, Tim Delaney wrote:
> I'd also point out that if you're expecting braces, not having them can make
> the code less readable.
If a programmer's mind explodes when they look at the simple and beautiful
examples in K&R's The C Programming Language, then they've got pro
On Jan 2, 2012, at 4:27 PM, Nick Coghlan wrote:
> With my perception of the status quo corrected, I can stop worrying
> about preserving a non-existent consistency.
+1 QOTD
Raymond
___
Python-Dev mailing list
Python-Dev@python.or
On Jan 26, 2012, at 7:19 PM, Ethan Furman wrote:
> One of the open issues from PEP 3134 is suppressing context: currently there
> is no way to do it. This PEP proposes one.
Thanks for proposing fixes to this issue.
It is an annoying problem.
R
ch a non-problem.
There is no need to add more code and slow
running time with superfluous type checks.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
quest frozen variante of other containers).
Raymond
P.S. The one advantage I can see for frozensets and frozendicts
is that we have an opportunity to optimize them once they are built
(optimizing insertion order to minimize collisions, increasing or
decreasing density, eliminating dummy entries,
ing a new
itertool tends to make the whole module harder to figure-out.
Raymond
P.S ISTM that lately Python is growing fatter without growing more
powerful or expressive. Generators, context managers, and decorators
were honking good ideas -- we need more of those rather than
minor vari
ill be drawn
to frozendicts like moths to a flame.
The tuple-as-frozenlist anti-pattern shows
what we're up against.
Another thought: if pypy is successful at providing sandboxing,
the need for sandboxing in CPython is substantially abated.
Raymond
_
dds to the expressivity of the language. Minor variants
on what we already have just makes that language harder to learn and remember
but not providing much of a payoff in return.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
On Mar 16, 2012, at 4:54 AM, Nick Coghlan wrote:
> Don't forgot you also have the option of splitting out a separate
> HOWTO tutorial section, leaving the main docs as a pure API reference.
> (I personally find that style easier to use than the ones which try to
> address both needs in the main m
On Mar 20, 2012, at 5:37 PM, Antoine Pitrou wrote:
> Georg Brandl wrote:
>> Hi all,
>>
>> recently I've grown a bit tired of seeing our default Sphinx theme,
>> especially as so many other projects use it. I decided to play around
>> with something "clean" this time, and this is the result:
>>
he code would
be better (i.e. what negative outcome would be avoided with time.monotonic or
somesuch).
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
confusing)?
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
On Apr 11, 2012, at 2:49 AM, Jim Jewett wrote:
> I believe PEP 418 (or at least the discussion) would benefit greatly
> from a glossary to encourage people to use the same definitions.
This sort of information is a good candidate for the HOW-TO section
of the docs.
Raymond
.connect(filename)
with auto_commit_or_rollback(db):
# do a transaction
Explicit beats implicit whenever the implicit behavior would deviate from
expected norms.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
On Apr 18, 2012, at 1:38 PM, Guido van Rossum wrote:
>
> Let's change this to something more reasonable, e.g.
>
> """
> If operators with different priorities are used, consider adding
> whitespace around the operators with the lowest priority(ies). This is
> very much to taste, however, never
On May 18, 2012, at 11:24 AM, Barry Warsaw wrote:
> At what point should we cut over docs.python.org to point to the Python 3
> documentation by default? Wouldn't this be an easy bit to flip in order to
> promote Python 3 more better?
My experience teaching and consulting suggests that this wou
On Jun 13, 2012, at 10:35 AM, Eli Bendersky wrote:
> Did you mean to send this to the list, Raymond?
Yes. I wanted to find-out whether someone approved changing
all the dict tunable parameters. I thought those weren't supposed
to have changed. PEP 412 notes that the existing pa
;t be changed without deep thought and study.
Certainly, "I think a growth factor of x2 is best" is insufficient.
Raymond
P.S. In the tracker discussion of key-sharing dict, you were asked
to NOT change the tunable parameters. I'm not sure
On Jun 14, 2012, at 4:32 AM, Kristján Valur Jónsson wrote:
> I would like to two or more compile time
> settings to choose from: Memory optimal, speed optimal, (and mix).
A compile time option would be nice.
The default should be what we've had though.
The new settings cause a lot more collis
emory size, and its affect
on various dict use cases.
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
s.
Instead, I would be open adding "further reading" section with external links
to interesting iterator writeups in blogs, cookbooks, stack overflow answers,
wikis, etc.
If one of you wants to craft an elegant blog post on "Grouping, Blocking, or
Chunking Sequences and Iterables&qu
On Jul 1, 2012, at 5:01 AM, Stefan Behnel wrote:
> To address the main problem of users not finding what they need, what about
> simply extending the docstring of the grouper()
Here's a small change to the docstring:
http://hg.python.org/cpython/rev/d32f21d87363
FWIW, if you're interested i
to a new location in memory.Pre-sizing avoids that entirely.
> If resizing of lists is too slow, then we should reconsider the 9/8 factor
> and/or look to tweak the resizing code.
A great deal of thought and care went into the current design.
It has already been "tweaked".
Raymo
On Jul 15, 2012, at 7:22 AM, Antoine Pitrou wrote:
> On Mon, 16 Jul 2012 00:08:41 +1000
> Nick Coghlan wrote:
>> Right, I agree on the value in being able to return something to say "this
>> cannot be converted to a concrete container".
>
> Who would be able to return that, apart from trivial c
On Jul 16, 2012, at 12:36 AM, Stefan Behnel wrote:
> I'd like to more visibly repeat my suggestion to make this a slot method
> "tp_length_hint()" in extension types that returns a Py_ssize_t.
That is merely an implementation detail, but it would be a nice i
On Jul 18, 2012, at 3:30 AM, Nick Coghlan wrote:
> - Eugene Toder's patch to add an AST optimisation step to the compiler
> chain (http://bugs.python.org/issue11549) (I've asked Eugene about
> this patch more recently and his current thought is that subsequent
> improvements to the peephole optim
On Aug 1, 2012, at 1:46 AM, Mark Shannon wrote:
>
> '''
> Being able to pre-allocate lists based on the expected size, as estimated by
> __length_hint__,
> can be a significant optimization.
> PyPy has been observed to run some code slower than CPython, purely because
> this optimization is ab
, every entry in the
voluminous Misc/NEWS file, etc).
You can help out by checking-in draft entries for your favorite new features.
That way, I can avoid the time consuming curation step and focus on the text,
organization, and examples.
I appreciate
k/#activetcl-8-5-12> which has
a paragraph of text obscuring the link you actually needed:
http://www.activestate.com/activetcl/downloads .
I applaud that some effort was made to document a solution; however, in
practice the daisy chain of footnotes, tables, and links has proven unworkable
for most of the eng
On Sep 11, 2012, at 6:32 AM, Christian Heimes wrote:
>
> maybe you have noticed a bunch of commits I made the last couple of
> days.
I noticed! Thank you for all the work to improve quality.
Raymond___
Python-Dev mailing list
Python-Dev@python.org
anting to experiment with the design,
there is a pure Python proof-of-concept here:
http://code.activestate.com/recipes/578375
YMMV: Keep in mind that the above size statics assume a
build with 64-bit Py_ssize_t and 64-bit pointers. The
space savings percentages are a bit different on other
buil
> 'hash' field) of those empty slots that aren't part of the final
> contiguous block and fill those preferentially.
That's the plan. See the comment above the keylist.index(UNUSED)
line in the _next_open_index() method in the pure python implementation.
Raymond
On Dec 10, 2012, at 2:48 AM, Christian Heimes wrote:
> On the other hand every lookup and collision checks needs an additional
> multiplication, addition and pointer dereferencing:
>
> entry = entries_baseaddr + sizeof(PyDictKeyEntry) * idx
Currently, the dict implementation allows alternati
ce hash tables aren't a new problem, there may
already be published research on the best way to handle
the entries array.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
On Dec 10, 2012, at 1:38 PM, PJ Eby wrote:
> Without numbers it's hard to say for certain, but the advantage to
> keeping ordered dictionaries a distinct type is that the standard
> dictionary type can then get that extra bit of speed in exchange for
> dropping the ordering requirement.
I expec
come.
Further sniping and unsubstantiated FUD would not.
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
On Dec 10, 2012, at 4:02 AM, Serhiy Storchaka wrote:
> On 10.12.12 05:30, Raymond Hettinger wrote:
>> On Dec 9, 2012, at 10:03 PM, MRAB > <mailto:pyt...@mrabarnett.plus.com>> wrote:
>>> What happens when a key is deleted? Will that leave an empty slot in
>>
hg's ability to "make merges easier than svn" depend on having
all the intermediate commits? I thought the theory was that the smaller
changesets provided extra information that made it possible to merge
two expansive groups of changes.
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
etions will retain their insertion
order. If this is of concern, it would be no problem to implement
Antoine's idea of scrambling the entries during iteration.
Raymond
P.S. I've gotten a lot of suggestions for improvements to the
proof-of-concept code. Thank you for that. The latest versi
On Jan 3, 2013, at 2:22 AM, Maciej Fijalkowski wrote:
> Hello everyone.
>
> Thanks raymond for writing down a pure python version ;-)
Thanks for running with it.
>
> I did an initial port to RPython for experiments. The results (on
> large dicts only) are inconclusive -
d others) had done a darned fine job of tuning
dictionaries.
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
for
mostcommon() to a module of favorite utilities:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/347615
Alternatively, the recipe for a bag class is a more flexible and still
reasonably efficient:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/259174
Raymond Hettinge
t gets vetoed for min and max, I'd
> at least like to add a bit of documentation pointing users of min/max
> to nsmallest/nlargest if they want a key= argument...
Sounds reasonable.
Raymond
P.S. In case you're interes
it works.
Guido says yes. So, load the patch to SF and assign to me for review,
testing, and documentation.
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
Reminder: The head is now for Py2.5.
Please also do a checkin for release24-maint.
Raymond
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
Any objections to removing Cookie.Cookie, Cookie.SmartCookie,
and Cookie.SerialCookie?
Raymond
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
Hmph. The xmllib module has been deprecated since Py2.0 but is not
listed in PEP 4.
Question: Do we have to keep it for another two years because of that
omission?
It seems somewhat silly to keep an obsolete, supplanted module that
doesnt full support XML 1.0.
Raymond
901 - 1000 of 1495 matches
Mail list logo
