[Greg Ewing]
> I'd still like to see next(x) / x.__next__() in
> some form in 3.0 for the sake of consistency,
> though.
+1 on modifying next() in Py3.0 to accept the send argument.
-1 on the silly renaming to __next__ and adding __builtin__.next().
We have len() because it applies to many differ
>> -1 on the silly renaming to __next__ and adding __builtin__.next().
>> We have len() because it applies to many different object types.
>> In contrast, next() would apply only to iterables.
[Greg Ewing]
> And you don't think there are many different
> types of iterables?
Um, I meant iterators
[Collin Winter]
> I've just posted a patch to SF (python.org/sf/1442442) that I thought
> I'd bring to everyone's attention. Executive summary: by changing the
> behaviour of the unused LIST_APPEND opcode, it's possible to get a 16%
> speed boost for list comprehensions.
That was working fine in P
[Aahz]
> * As a writer/teacher, I want to be able to say, "All Python special
> methods have leading and trailing double-underscore." Period, end of
> story.
When teaching your classes, do you sense an aversion to using double underscore
methods in regular code? I sense an implied message that
[Anna Ravenscroft]
>>I think this is a really good point. next() is supposed to get used, by
>>coders, in regular code - so it shouldn't be __next__. I can understand the
>>desire for both forms, although that seems it would clutter things up
>>unnecessarily - particularly if the two do the same
[Neil Schemenauer]
>I occasionally need dictionaries or sets that use object identity
> rather than __hash__ to store items. Would it be appropriate to add
> these to the collections module?
Why not decorate the objects with a class adding a method:
def __hash__(self):
return id(self)
[Steven Elliott]
> As you probably know each access of a builtin requires two hash table
> lookups. First, the builtin is not found in the list of globals. It is
> then found in the list of builtins.
If someone really cared about the double lookup, they could flatten a level by
starting their m
[Ian Bicking]
> The question then is what the API should look like for such an object --
> an ordered, multi-value dictionary.
May I suggest that multidict begin it's life as a cookbook recipe so that its
API can mature.
Raymond
___
Python-Dev mai
[Ian Bicking]
>> memoize seems to fit into functools fairly well, though deprecated not
>> so much. functools is similarly named to itertools, another module
>> that
>> is kind of vague in scope (though functools is much more vague).
>> partial would make just as much sense in functools as in func
[Nick Coghlan]
> I agree it makes sense to have "decorator", "memoize", "deprecated" and
> "partial" all being members of the same module, whether the name be
> "functools" or "functional" (although I have a slight preference for
> "functools" due to the parallel with "itertools").
I like "functoo
> In PEP 356, there is even a suggestion to "add builtin @deprecated
> decorator?".
Restraint please. Go easy on the decorator additions.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
A user on comp.lang.python has twisted himself into knots writing
multi-threaded
code that avoids locks and queues but fails when running code with non-atomic
access to a shared resource. While his specific design is somewhat flawed, it
does suggest that we could offer an easy way to make a blo
7;s fatally flawed for several reasons: it doesn't translate
reasonably to Jython or IronPython, it's really tricky to implement,
and it's an invitation for deadlocks. The danger of this thing in the
wrong hands is too big to warrant the (rare) use case that can only be
solved elegant
> it doesn't translate reasonably to Jython or IronPython, it's really tricky
> to
> implement,
FWIW, someone on the newsgroup suggested implementing this via a slight
modification to sys.checkinterval(). The idea was that a None argument would
translate to "stop-checking" and the active thre
[Samuele Pedroni]
> there's no sys.checkinterval in Jython. Implementing this would need the
> introduction of some kind of GIL implementation in Jython, the JVM has no
> primitive for global critical sections.
Wouldn't Java implement this directly by suspending and resuming the other
threads (b
[Nice analysis from Michael Chermside]
> The concept of a "critical section" makes great sense when there is
> effectively only one CPU: just stop switching threads. But if code
> is using multiple CPUs, what does it mean? Shut down the other CPUs?
. . .
> I think it is unwise to build such a
> fe
FWIW, I've been working on a way to simplify the use of queues with daemon
consumer threads
Sometimes, I launch one or more consumer threads that wait for a task to enter
a
queue and then work on the task. A recurring problem is that I sometimes need
to
know if all of the tasks have been comp
[Raymond]
>> While this is a somewhat rough approach, it is dramatically
>> simpler than the alternatives (i.e. wrapping locks around every access to a
>> resource or feeding all resource requests to a separate thread via a Queue).
[Alexander]
> Why is that actually more difficult to write? Consid
> Isn't this a job for threading.BoundedSpemaphore()?
I don't see how that would work. ISTM that we need an inverse of a
BoundedSemaphore. If it understand it correctly, a BS blocks after some
pre-set
maximum number of acquires and is used for resources with limited capacity
(i.e.
a number
>> Raymond is on it, anyway:
>>
>> http://python.org/sf/1444398
>
> You found it, you fix it :-)
I've got this one.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
[Neal]
>I posted a message to c.l.p about the upcoming alpha 1.
>
> Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
> real quick, hopefully within a couple of weeks. If you have any
> *major* features (particularly implemented in C) that you want to see
> in 2.5, bring it up no
[Barry Warsaw]
> Oh, also, we have a couple of additions to the PySet C API.
> I'll work on putting together an SF patch for them over the weekend.
What are you proposing to add to the PySet API?
Raymond
___
Python-Dev mailing list
Python-Dev@python
[Raymond]
> FYI, I have several non-major C components to go in but not in time for alpha
> 1.
> They include some minor fix-ups in the sets module, the str.partition
> function,
> add gc to itertools.tee, a couple of functions in binascii, add
> itertools.izip_longest, Crutcher's patch to make e
> [Barry Warsaw]
>> Oh, also, we have a couple of additions to the PySet C API.
>> I'll work on putting together an SF patch for them over the weekend.
What are you proposing to add to the PySet API?
I designed an API that was both minimal and complete. The idea was to provide
direct access to
[Raymond]
>> What are you proposing to add to the PySet API?
[Barry]
> PySet_Clear(), PySet_Next(), PySet_Update(), and PySet_AsList().
PySet_Clear()
-
Use PyObject_CallMethod(s, "clear", NULL).
Or if you need to save a millisecond on an O(n) operation, use
PyNumber_InPlaceSubtract(
[Guido]
> Sigh. Enough already. PEP 352 was chosen to minimize incompatibilities
> and maximize gain with minimal changes in the tree. Also note that
> Warnings can sometimes be raised and should then treated as errors, so
> Warning would have to inherit from Error.
>
> I vote for the status quo in
[Barry]
> Is it your intent to push for more use of the abstract API instead of
> the concrete APIs for all of Python's C data structures? Current API
> aside, are you advocating this approach for all new built-in types?
> Would you argue that Python 3.0's C API be stripped of everything but
> the
[Me]
> There is a semantic difference between
> code like s+=t and s.update(t). The former only works when t is a set
> and the latter works for any iterable. When the C code corresponds to
> the Python code, that knowledge is kept intact and there is no confusion
> between
> PyNumber_InPlaceAd
>> I can't see all that much use for GeneratorExit in code that needs to
>> be compatible with 2.4, since the rest of the machinery that makes
>> exception handling around yield feasible doesn't exist.
>
> I agree entirely - my goal is to make sure it stays that way.
>
> The kind of code I'm talkin
[Barry]
> Maybe it will help you to understand why I want a richer concrete API.
> I work on an app that is deeply integrated with Python. It's hard to
> say whether we embed or extend -- it's a lot of both. We use Python
> data structures such as lists, dicts, and sets in many places as our
> fu
[Alex]
> And I'm on the fence regarding the specific issue of PySet_Next.
>
> So, having carefully staked out a position smack in the middle, I
> cheerfully now expect to be fired upon from both sides!-)
Okay, here's the first cheap shot ;-) Which of the following pieces of code is
preferable?
[Aahz]
> Speaking as a person who does relatively little C programming, I don't
> see much difference between them. The first example is more Pythonic --
> for Python. I agree with Barry that it's not much of a virtue for C
> code.
It was a trick question. Everyone is supposed to be attracted t
[Alex]
> Sure, accidentally mutating underlying iterables is a subtle (but alas
> frequent) bug, but I don't see why it should be any harsher when the loop is
> using a hypothetical PySet_Next than when it is using PyIter_Next --
> whatever
> precautions the latter takes to detect the bug a
>> The difference is that the PySet_Next returns pointers to the table keys and
>> that the mutation occurs AFTER the call to PySet_Next, leaving pointers to
>> invalid addresses. IOW, the function cannot detect the mutation.
>
> I'm coming late to the discussion: where did anybody ever suggest th
Why don't we expose _PySet_Next() for Barry and leave it out of the public API
for everyone else.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
>> Why don't we expose _PySet_Next() for Barry and leave it out of the public
>> API
>> for everyone else.
[Alex]
> There are precedents for adding some functionality to the C API but not
> documenting it to ensure "non advanced users" don't get hurt -- that's how
> we
> added the ability t
>> Thank would be nice. It gives me the ability to keep a clean, sane API
>> while
>> at
>> the same time making sure that my most important customer (Barry) gets his
>> needs
>> met.
> I'm having a hard time deciphering whether you're being condescending or
> trying to be funny. I'm going to
Barry, go ahead with PySet_Clear().
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
[Gareth McCaughan]
> For what it's worth[1], I think Raymond is absolutely on crack here.
Nope. No mind-altering drugs here. Based on real-word experience, I have
found
PySet_Next() to be a bug factory and do not want it included in the API.
The story is different for PySet_Update(). Definin
[Raymond Hettinger]
> > Barry, go ahead with PySet_Clear().
[Barry]
Cool thanks. I think we've also compromised on _PySet_Next(), correct?
Yes, _PySet_Next() is a good compromise for you and me -- it saves you from
writing a hack and saves my API from including a bug factory. The
[Jack Diederich]
>> Classes have a unique property in that they are the easiest way to make
>> little namespaces in python.
[Greg Ewing]
> For a while now, I've been wondering whether it would
> be worth having a construct purely for creating little
> namespaces, instead of abusing a class for thi
>> The idea is not yet ready for prime-time. If I do it for one of the named
>> operations, I will do it for all (to keep the interface uniform).
> Which named operations are you thinking of?
s.union(t), s.intersection(t), s.difference(t), s.symmetric_difference(t),
s.update(t), s.intersection
>> I've found out that the hash value of tuples isn't saved after it's
>> calculated. With strings it's different: the hash value of a string is
>> calculated only on the first call to hash(string), and saved in the
>> structure for future use. Saving the value makes dict lookup of tuples
>> an ope
[Alex]
> This is quite general and simple at the same time: for example, it
> was proposed originally to answer some complaint about any and all
> giving no indication of the count of true/false items:
>
> tally(bool(x) for x in seq)
>
> would give a dict with two entries, counts of true and
> Benchmarking is hard, let's go shopping!
Quick reminder: pystone is mostly useful for predicting Python's relative
performance across various machines and operating systems. For benchmarking
Python itself, pystone is a seriously impaired tool. For one, it exercises
only
a tiny subset of t
> a while ago, Raymond proposed str.partition, and I guess the reaction
> was positive. So what about including it now?
Neal approved this for going into the second alpha.
Will do it this month.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
> I may not be right, but I don't see how this can't help but not free the
> intermediate PyString object.
Good catch.
> It doesn't seem to be used, except for in situations where Python is not
> going
> to continue working
> much longer anyway (specifically, in compile.c and ceval.c.)
Those
[Bill Janssen]
> Yeah, but you can't do more complicated expressions that way, like
>
> any(lambda x: x[3] == "thiskey")
You're not making any sense. The sequence argument is not listed and the
lambda
is unnecessary. Try this instead:
any(x[3] == 'thiskey' for x in seq)
> I think
't be bad either.
>>
>>Jeremy
>>
>>On 4/11/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>>
>>
>>>On 4/11/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>>>It strikes me that it should not be
M.-A. Lemburg wrote:
>I could contribute pybench to the Tools/ directory if that
>makes a difference:
>
>
>
+1 on adding pybench.
And we already have parrotbench in the sandbox.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
tomer filiba wrote:
> many times, templating a string is a tidious task. using the %
> operator, either with tuples or dicts,
> is difficult to maintain, when the number of templated arguments is
> large. and string.Template,
> although more easy to read, is less intutive and cumbersome:
>
> imp
>
>If you don't like the $name style of template markup and prefer
>delimiters instead, then check-out the recipe at:
>
>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053
>
>
The link should have been:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305306
Georg Brandl wrote:
>Guido van Rossum wrote:
>
>
>>Backticks certainly are deprecated -- Py3k won't have them (nor will
>>they become available for other syntax; they are undesirable
>>characters due to font issues and the tendency of word processing
>>tools to generate backticks in certain case
Tim Peters wrote:
>[Tim Peters, on giving commit privs to a sprinter after
> extracting a signed PSF contributor form]
>
>
>>>The more realistically ;-) I try to picture the suggested
>>>alternatives, the more sensible this one sounds. ...
>>>
>>>
>
>[Martin v. Löwis]
>
>
>>I completely
>Guido> Hm... Without reading though all this, I expect that you'd be
>Guido> better off implementing this for yourself without attempting to pull
>Guido> the standard library sets into the picture (especially since sets.py
>Guido> is obsolete as of 2.4; set and frozenset are now built-in types).
Aahz wrote:
>On Thu, May 18, 2006, Neal Norwitz wrote:
>
>
>>I moved up the 2.5 release date by a bit. Ideally, I wanted to have
>>the final on July 27 which corresponds to OSCON. This seems too
>>aggressive since I haven't updated the schedule publicly. So the new
>>schedule has rc1 slated f
Runar Petursson wrote:
> We've been talking this week about ideas for speeding up the parsing
> of Longs coming out of files or network. The use case is having a
> large string with embeded Long's and parsing them to real longs. One
> approach would be to use a simple slice:
> long(mystring[x
Fredrik Lundh wrote:
> >>> -1 * (1, 2, 3)
>()
> >>> -(1, 2, 3)
>Traceback (most recent call last):
> File "", line 1, in
>TypeError: bad operand type for unary -
>
>We Really Need To Fix This!
>
>
The second one doesn't bug me. Unary minus on a sequence is meaningless.
The first is a bit o
Fredrik Lundh wrote:
Yes. It went to my todo list and is awaiting some free raymond-cycles
to finish it up. I've been task saturated of late but would like to get
this a number of other patches complete for Py2.5.
no need to wait for any raymond-cycles here; just point me
Steve Holden wrote:
>
> This reminds me I am tasked with trying to find out what the interface
> to timeit.py is supposed to look like. Raymond, your name has been
> mentioned as someone who took part int he discussions. Google hasn't
> given me a lot to go on. Anyone?
>
IIRC, Guido's words we
Giovanni Bajo wrote:
Fredrik Lundh wrote:
does anyone remember? given what we're currently working on,
implementing it would take roughly no time at all. do people still
think it's a good idea ?
I had enquired this before but got no answer. I assume nobody's workin
> 1) Is str.rpartition() still wanted?
Yes.
___
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
> It would help me enormously if someone could summarize the status and
> everything that went on. These are the things that would help me the
> most.
>
> * What are the speed diffs before/after the sprint
> * What was modified (summary)
> * What is left to do
>- doc
>- tests
>- code
> Aahz <[EMAIL PROTECTED]> wrote:
>>> Some open question remain:
>>> - should iwindow return lists or tuples?
>>> - what happens if the length of the iterable is smaller than the
>>> window size, and no padding is specified? Is this an error? Should
>>> the generator return no value at all or one w
From: "Nick Coghlan" <[EMAIL PROTECTED]>
> A python-dev Google search for "itertools window" found me your original
> suggestion to include Jack Diedrich's itertools.window in Python 2.3 (which
> was only deferred because 2.3 was already past beta 1 at that point).
>
> I couldn't find any discuss
> In the process of reviewing and possibly extending getargs.c, I stumbled
> over the "compatibility" flag supposedly used for METH_OLDARGS functions.
> No code in the core uses this calling convention any more, and it has been
> deprecated for quite a long time (since 2.2), so would it be appropri
From: "Armin Rigo" <[EMAIL PROTECTED]>
> I've finally come around to writing a patch that stops dict lookup from
> eating all exceptions that occur during lookup, like rare bugs in user
> __eq__() methods.
Is there a performance impact?
Raymond
___
> On Mon, May 29, 2006 at 12:20:44PM -0700, Raymond Hettinger wrote:
>> > I've finally come around to writing a patch that stops dict lookup from
>> > eating all exceptions that occur during lookup, like rare bugs in user
>> > __eq__() methods.
>>
>&g
Armin Rigo wrote:
Hi Raymond,
On Mon, May 29, 2006 at 02:02:25PM -0700, Raymond Hettinger wrote:
Please run some better benchmarks and do more extensive assessments on the
performance impact.
At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously o
When the result of an expression is None, the interactive interpreter
correctly suppresses the display of the result. However, it also
suppresses the underscore assignment. I'm not sure if that is correct
or desirable because a subsequent statement has no way of knowing
whether the undersc
> for users, it's actually quite simple to figure out what's in the _
> variable: it's the most recently *printed* result. if you cannot see
> it, it's not in there.
Of course, there's a pattern to it. The question is whether it is the *right*
behavior. Would the underscore assignment be more
When the result of an expression is None, the interactive interpreter
correctly suppresses the display of the result. However, it also
suppresses the underscore assignment. I'm not sure if that is correct
or desirable because a subsequent statement has no way of knowing
whether the underscore
Alex Martelli wrote:
>...claims:
>
>Note that for even rather small len(x), the total number of
>permutations of x is larger than the period of most random number
>generators; this implies that "most" permutations of a long
>sequence can never be generated.
>
>Now -- why would the behavior of "mos
The optimisation of the if-elif case would then simply be to say that the
compiler can recognise if-elif chains like the one above where the RHS
of the comparisons are all hashable literals and collapse them to switch
statements.
Right (constants are usually hashable :-).
Alexander Belopolsky wrote:
>As an exercise in using the new set C API, I've replaced the
>"interned" dictionary in stringobject.c with a set. Surprisingly,
>what I thought would be a simple exercise, took several hours to
>implement and debug. Two problems are worth mentioning:
>
>1. I had to a
Alexander Belopolsky wrote:
> This is very raw, but in the spirit of "release early and often",
> here it is:
>
> http://sourceforge.net/tracker/download.php?
> group_id=5470&atid=305470&file_id=181807&aid=1507011
>
> On Jun 15, 2006, at 8:47 PM,
Alexander Belopolsky wrote:
>1. Is there a reason not to have PySet_CheckExact, given that
>PyFrozenSet_CheckExact exists? Similarly, why PyAnySet_Check, but no
>PySet_Check or PyFrozenSet_Check?
>
>
If you NEED PySet_CheckExact, then say so. Adding it is trivial.
Each of the six combinatio
>>
In abstract.c, there are many error messages like
>>
>> type_error("object does not support item assignment");
>>
>> It helps debugging if the object's type was prepended.
>> Should I go through the code and try to enhance them
>> where possible?
>
> So that's definite "perhaps"?
Anthony Baxter wrote:
>A question has been asked about branching release25-maint at the time
>of beta1. I was actually thinking about doing this for 2.5rc1 - once
>we're in release candidate stage we want to really be careful about
>checkins. I'm not sure it's worth branching at beta1 - it's a
Guido van Rossum wrote:
On 6/18/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
[...] Offering arbitrary expressions whose
meaning can vary at runtime would kill any potential speedup (the
ultimate purpose for having a switch statement), [...]
Um, is this dogma? Wouldn't a
>> A switch-statement offers only a modest readability improvement over
>> if-elif chains.
>
>
> Probably, which is why it hasn't been added yet. :-)
>
> But there is a definite readability improvement in that you *know*
> that it's always the same variable that is being compared and that no
> ot
>> > But there is a definite readability improvement in that you *know*
>> > that it's always the same variable that is being compared and that no
>> > other conditions are snuck into some branches.
>>
>> Hmm, when I saw that "arbitrary expressions" were being proposed, I took
>> that took mean th
>> My thought is that we *should* define switching in terms of hash
>> tables. It builds off of existing knowledge and therefore has a near
>> zero learning curve. The implementation is straight-forward and there
>> are none of the hidden surprises that we would have with
>> fastpath/slowpath ap
>From what I can see, almost everyone wants a switch statement, though perhaps
for different reasons.
The main points of contention are 1) a non-ambiguous syntax for assigning
multiple cases to a single block of code, 2) how to compile variables as
constants in a case statement, and 3) handling
[Phillip Eby]
> I would like to be able to use switches on types, enumerations, and the like.
Be careful about wanting everything and getting nothing.
My proposal is the simplest thing that gets the job done for key use cases
found
in real code.
Also, it is defined tightly enough to allow room f
> Sorry, no go. You can say "supports key use cases found in real code"
> as often as you like,
Those were not empty words. I provided two non-trivial worked-out examples
taken from sre_constants.py and opcode.py. Nick provided a third example from
decimal.py. In all three cases, the proposal
>>No thanks. That is its own can of worms. The obvious solutions (like const
>>declarations, macros, or a syntax to force compile-time expression
>>evaluation)
>>are unlikely to sit well because they run afoul Python's deeply ingrained
>>dynamism.
>>
>>
>
>I think perhaps you haven't been p
Michael Urman wrote:
> I'm trying to find some real world examples of a pygame event loop
>
>that really show the benefit of supporting named constants and
>expressions. I may mess up irrelevant details, but the primary case
>looks something like the following (perhaps Pete Shinners could point
>u
Gregor Lingl wrote:
>I would appreciate it very much if xturtle.py could go into Python2.5.
>
>
+1 The need for turtle.py improvements was discussed at the last
PyCon. It would be a nice plus for people teaching programming to kids.
In theory, it is a little late to be adding new modules.
> i thought avoiding a second dict lookup should be faster, but it turned out
> to be completely wrong.
Unless you have an expensive hash function, it is almost never worth it to try
to avoid a second lookup. Because of memory cache effects, the second lookup
is
dirt cheap (a cache miss is abo
> I forgot about this but was recently reminded. How much opposition
> would there be to sneaking this into 2.5b2? It would consist of
> adding a relatively simple new function, docs, and tests; since it
> wouldn't _change_ any existing code, it would have a hard time
> breaking anything that cu
[Raymond]
> > The above recommendations should get the PEP ready for judgement
day.
[David Eppstein]
> I thought judgement day already happened for this PEP in the "Parade
of
> PEPs". No?
The parade's text said the main gripe was having the index in the
middle, rather than right after the keywor
ion is entirely unintuitive (it has
to be studied a bit before being able to see what it is for). Also, the
OP is short on use cases (none were presented). IMO, this belongs as a
cookbook recipe.
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
[Paul Moore on readline getting a record separator argument]
> As a more general approach, would it be worth considering an addition
> to itertools which took an iterator which generated "blocks" of items,
> and split them on a subsequence?
Nope. Assign responsibility to the class that has all o
I'm getting a compiler warning from your checkin:
C:\py25\Objects\floatobject.c(1430) : warning C4244: 'initializing' :
conversion from 'double ' to 'float ', possible loss of data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
> Should I write a PEP?
No. Just let it evolve naturally.
The next step is for a builtin C version. That will likely happen as
soon as one of us has the time and inclination to write it.
If that works out well, then writing decimal literals like 123d may be
plausible.
And, if that works out w
> If there are no objections, I propose to do the following (only in
> Python 2.4 and 2.5):
>
> * Add set.union_update() as an alias for set.update().
No. It was intentional to drop the duplicate method with the
hard-to-use name. There was some thought given to deprecating
sets.union_upda
[Nicolas Fleury]
> This comment reminds me another small inconsistency/annoyance.
>
> Should copy and clear functions be added to lists, to be more
consistent
> with dict and set, and easing generic code?
I think not.
Use copy.copy() for generic copying -- it works across a wide range of
objec
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
For instance, if the new magic methods are added to decimal.Context(),
do we then describe Context objects as "withable" ;-)
The PEP itself doesn't pro
[Shane Holloway]
> I would agree generic clearing is a lark in terms of programming
> feature. However, I have been asked how to clear a list more than a
> handful of times.
list.clear() does not solve the root problem. The question is
symptomatic of not understanding slicing. Avoidance of tha
1201 - 1300 of 1487 matches
Mail list logo
