Brett Cannon wrote:
> As I am sure some have noticed, as part of my dissertation I have been
> trying to fix the various crashers.
Nice project.
One quick thought: Any crasher that relies on gc.get_referrers() should
not be considered a bug. The codebase should not be convoluted,
complexifi
Tim Peters wrote:
[Neal Norwitz]
There hasn't been much positive response (in the original thread or
here).
Do note that there was little response of any kind, but all it got was
positive. It's not sexy, but is essential for debugging deadlocks.
If you ask for positive
Anthony Baxter wrote:
But, the imagined costs of a new feature
during beta are illusory.
This, I cannot agree with. The costs and risks of just continuing to
add new features all through the release process are high.
I meant this particular feature.
In general, there ough
Russell E. Owen wrote:
>I'd like to have the get method available for lists and tuples. (I
>figured this must have been discussed before but can't recall it and
>didn't turn anything up on google).
>
>It's obviously not a use-all-the-time method (or it'd already be there),
>but I find myself wa
I briefly had a chance to look at some of the work being done on a C
implementation of decimal, and it looks like the approach is following
the Python version too literally.
Ideally, it should be written as if Python were not involved and
afterwards add the appropriate method wrappers. Context
Aahz wrote:
On Tue, Jul 18, 2006, Raymond Hettinger wrote:
P.S. The dictionary approach to context objects should likely be
abandoned for the C version. If the API has to change a bit, then so
be it.
Why do you say that? The rest I agree with; seems to me that making
Lisandro Dalcin wrote:
On 7/18/06, Tim Peters <[EMAIL PROTECTED]> wrote:
[Raymond Hettinger]
...
If the current approach gets in their way, the C implementers should feel free to
make an alternate design choice.
I expect they will, even
I think it was tripping-up the folks working on the C implementation.
Georg can speak to it more directly. IIRC, the issue was that the
context object exposed a dictionary which a user could update directly
and there was no notification back to the surrounding object so it could
upda
Tim Peters wrote:
...
[Raymond]
Even then, we need to drop the concept of having the flags as counters
rather than booleans.
[Georg Brandl]
Yes. Given that even Tim couldn't imagine a use case for counting the
exceptions, I think it's sensible.
Greg Ewing
> And all of this is getting rather far away from where we
> started, which was simply instrumenting a piece of code
> to count floating point exceptions.
I'm thinking of adding a note to the Py2.5 docs that the counting feature is
not
part of the standard and should not be expected t
I suggest that there be a third beta release and that we then wait just
a bit before going final.
The bugs that were found and fixed in the first two beta releases
suggest that Py2.5 is not yet as stable as we would like. Over the next
few days, I'll try to run it on as much third-party code a
Neal Norwitz wrote:
>Anthony and I talked about still having b3 on Aug 1. rc1 around Aug
>17-18 (just before the Google sprint which Martin, Jeremy and I will
>be attending). Final around 24-29. We didn't discuss with Martin
>yet, so these dates are quite tentative.
>
>
If it doesn't muck-up
Greg Ewing wrote:
>As an aside, does anyone else think that it would be
>useful to have a builtin which rounds and converts to
>an int in one go? Whenever I use round(), I almost
>always want the result as an int, and making me do
>it in two steps seems unnecessarily bothersome.
>
>
I think this
Nick Maclaren wrote:
Well, maybe. There are other approaches, too, and Decimal has its
problems with that. In particular, when people need precisely
defined decimal rounding, they ALWAYS need fixed-point and not
floating-point.
The decimal spec was designed to encompass both floating-
>> Most typical uses of round() don't use the
>> optional argument, true, but I still fail
>> to see what returning an integer instead of
>> a float would buy you.
>
>
> It saves you a function call in the vast
> majority of cases, where an int is what
> you ultimately want.
>
-1 on an extra buil
of suppressing exceptions.
Raymond
From: [EMAIL PROTECTED] on behalf of Guido
van RossumSent: Thu 8/24/2006 4:08 PMTo: Raymond
Hettinger; python-dev@python.org; Brian HolmesSubject: zip ->
izip; is __length_hint__ required?
At today's sprint, Brian Holmes contributed a
I would like to see the changes to the decimal module reverted for the
Py2.5 release.
Currently, the code in the decimal module implements the context manager
as a separate class instead of incorporating it directly in
decimal.Context. This makes the API unnecessarily complex and is not
prett
Raymond Hettinger wrote:
>I would like to see the changes to the decimal module reverted for the
>Py2.5 release.
>
>Currently, the code in the decimal module implements the context manager
>as a separate class instead of incorporating it directly in
>decimal.Context.
>
Phillip J. Eby wrote:
> At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote:
>
>> * The implementation's doc string examples were not tested and don't
>> work (this is a deep error). One reads:
>>
>> with decimal.getcontext() as ctx:
>>
Nick Coghlan wrote:
> Raymond Hettinger wrote:
>
>> I would like to see the changes to the decimal module reverted for
>> the Py2.5 release.
>
>
> I believe you may be overreacting - I don't consider the current
> behaviour buggy and the module level API can
I believe you may be overreacting - I don't consider the current
behaviour buggy and the module level API can be added later.
My preference is to remove the method entirely and then implement the
approach in PEP 343 by adding a module level "localcontext()" function
in
Nick Coghlan wrote:
> Raymond Hettinger wrote:
>
>> The right way to do it was presented in PEP343. The implementation
>> was correct and the API was simple.
>
>
> Raymond's persuaded me that he's right on the API part at the very
> least. The current
>>> The right way to do it was presented in PEP343. The implementation
>>> was correct and the API was simple.
>>
>>
>>
>> Raymond's persuaded me that he's right on the API part at the very
>> least. The current API was a mechanical replacement of the initial
>> __context__ based API with a no
Currently, both the partition() and rpartition() methods return a (head,
sep, tail) tuple and the only difference between the two is whether the
partition element search starts from the beginning or end of the
string. When no separator is found, both methods return the string S
and two empty s
[Neal]
> Please review the patch and make a comment. I did a diff between HEAD
> and 2.4 and am fine with this going in once you are happy.
I fixed a couple of documentation nits in rev 51688.
The patch is ready-to-go.
Nick, please go ahead and backport.
Raymond
___
Jim Jewett wrote:
>
>Why not just change which of the three strings holds the remainder in
>the not-found case?
>
>
That was the only change submitted.
Are you happy with what was checked-in?
Raymond
___
Python-Dev mailing list
Python-Dev@python.o
>
> This change looks wrong:
>
> PyDoc_STRVAR(rpartition__doc__,
> -"S.rpartition(sep) -> (head, sep, tail)\n\
> +"S.rpartition(sep) -> (tail, sep, head)\n\
>
> It looks like the code itself does the right thing, but I wasn't quite
> confident of that.
>
It is correct. There may be some confusion
> ISTM this is just begging for newbie (and maybe not-so-newbie)
> confusion. Why not just document both as returning (left, sep,
> right) which seems the most obvious description of what the methods
> return?
I'm fine with that (though it's a little sad that we think the rather
basic co
>
> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail)
Gads, the cure is worse than the disease.
car and cdr are starting to look pretty good ;-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
Jim Jewett wrote:
>
> Another possibility is data (for head/tail) and unparsed (for rest).
>
>S.partition(sep) -> (data, sep, unparsed)
>S.rpartition(sep) -> (unparsed, sep, data)
This communicates very little about the ordering of the return tuple.
Beware of overly general terms like
Ron Adam wrote:
>I hope this discussion is only about the words used and the
>documentation and not about the actual order of what is received. I
>would expect both the following should be true, and it is the current
>behavior.
>
> ''.join(s.partition(sep)) -> s
> ''.join(s.rpartition(sep)
Tim Peters wrote:
>upto, sep, rest
>
>in whatever order they apply.
>
In the rpartition case, that would be (rest, sep, upto) which seems a
bit cryptic.
We need some choice of words that clearly mean:
* the chopped-off snippet (guaranteed to not contain the separator)
* the separator if f
See, for me, it's all about the results of the operation, not how the
results are (supposedly) used. The way I think about it is that I've
got some string and I'm looking for some split point within that
string. That split point is clearly the "middle" (but "sep" works
too) and every
Giovanni Bajo wrote:
>
>+1, but I would love to see a more formal definition of what a "bugfix" is,
>which would reduce the ambiguous cases, and thus reduce the number of times the
>release managers are called to pronounce.
>
>
Sorry, that is just a pipe-dream. To some degree, all bug-fixes are
[Michael Foord]
>I have a suggestion for a new Python built in function: 'flatten'.
> ...
> There are several different possible approaches in pure Python,
> but is this an idea that has legs ?
No legs.
It has been discussed ad naseum on comp.lang.python. People seem to
enjoy writing their own
tomer filiba wrote:
> i'd like to suggest adding weak attributes and weak methods to the std
> weakref
> module.
. . .
>
> i think these two features are quite useful, and being part of the
> stdlib, would
> provide programmers with easy-to-use solutions to object-aliveness issues.
>
> more i
> Also, I question the utility of maintaining a weakref to a method or
> attribute instead of holding one for the object or class.
Strike that paragraph -- the proposed weakattrs have references away from the
object, not to the object.
Raymond
___
Py
[Alex Martelli]
>I've had use cases for "weakrefs to boundmethods" (and there IS a
>Cookbook recipe for them),
>
Weakmethods make some sense (though they raise the question of why bound
methods are being kept when the underlying object is no longer in use --
possibly as unintended side-effect of
> There are *definitely* use cases for keeping bound methods around.
>
> Contrived example:
>
>one_of = set([1,2,3,4]).__contains__
>filter(one_of, [2,4,6,8,10])
ISTM, the example shows the (undisputed) utility of regular bound methods.
How does it show the need for methods bound weakly t
I'll mark it as withdrawn.
Raymond
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Jeremy Hylton
Sent: Wednesday, October 04, 2006 8:44 AM
To: Guido van Rossum
Cc: Hans Polak; python-dev@python.org
Subject: Re: [Python-Dev] PEP 315 - do while
On 10/4/06,
No need to backport. Py_TPFLAGS_DEFAULT implies
Py_TPFLAGS_HAVE_WEAKREFS.
The change was for clarity -- most things that have the weakref slots
filled-in will also make the flag explicit -- that makes it easier on
the brain when verifying code that checks the weakref flag.
Raymond
-Ori
> The change was for clarity -- most things that have the weakref slots
> filled-in will also make the flag explicit -- that makes it easier on
> the brain when verifying code that checks the weakref flag.
> I don't understand why you added this flag here;
Perhaps my other post wasn't clear. The
> From: Kristján V. Jónsson
> I think we should start considering to make PCBuild8 a "supported" build.
+1 and not just for the free speed-up. VC8 is what more and more Windows
developers will have on there machines. Without a supported build, it becomes
much harder to make patches or build co
My colleague got an odd result today that is reproducible on his build
of Python (RedHat's distribution of Py2.4.2) but not any other builds
I've checked (including an Ubuntu Py2.4.2 built with a later version of
GCC). I hypothesized that this was a bug in the underlying GCC
libraries, but the mag
80.0
>>> -194 * (1/100.0)
-19400.0
>>> -194 * (1/100.0)
-19400.0
Raymond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 1:44 PM
To: Raymond Hettinger
Cc: python-dev@python.org
Subject: Re: [P
[Ben Wing ]
>> many times writing somewhat complex loops over lists i've found the need
>> to sometimes delete an item from the list. currently there's no easy
>> way to do so; basically, you have to write something like
[Adam Olsen]
> As I don't believe there's any need for a language extension,
[Andrea Griffini]
> I'm experimenting with a patch for dictionary lookup caching, the
> main idea being avoiding the lookup of a constant (co_names) in
> a dictionary if the dictionary didn't change since last lookup.
. . .
> My opinion is that it would be by far better to do this ordering
> of co_
[Michael Foord]
> Could / should 'PropertyType' be added to the types module ?
PropertyType = property
Yawn,
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
"Christos Georgiou"
> In retrospection, the example code I chose, although it showed the two
> issues I thought important ('list / deque iteration discrepancy' and 'empty
> / non-empty deque iteration discrepancy') was not as plain as needed, ...
Lists are unique in the way they allow mutation du
<"Anthony Baxter">
> Comments? What else should get warnings?
It is my strong preference that we not go down this path.
Instead, the 2.6 vs 3.0 difference analysis should go in an
external lint utility.
The Py2.x series may live-on for some time and should do so
as if Py3.x did not exist. Bur
[Thomas Wouters]
> By Guido's plan, 3.0 will arrive well before 2.6, and the migration step is
> not as
> large as many fear it to be. Having Python 2.6 optionally warn for
> 3.0-compatibility
> is a lot easier for the average developer than having a separate tool or a
> separately
> compiled P
[Anthony Baxter]
> I've had a number of people say that this is something they would
> really, really like to see - the idea is both to let people migrate
> more easily, and provide reassurance that it won't be that bad to
> migrate!
If Py3.0 is going to come out before Py2.6, can we table the
[A.M. Kuchling]
> 2.6 wouldn't go changing existing APIs to begin requiring or returning
> the bytes type[*], of course, but extensions and new modules might use
> it.
The premise is dubious.
If I am currently maintaining a module, why would I switch to a bytes type
and forgo compatibility with P
ISTM, we can decide to limit 3.0's impact to a single compatibility module,
essentially as an alternate set of builtins.
import __new_builtins__
for name in 'bytes dict coerce'.split(): # list any new features you want
to support
setattr(__builtins__, name, getattr(__new_builtins__, nam
I bumped into an oddity today:
6.0 // 0.001 != math.floor(6.0 / 0.001)
In looking at Objects/floatobject.c, I was surprised to find that
float_floor_division() is implemented in terms of float_divmod(). Does anyone
know why it takes such a circuitous path? I had expected something simpler
[Michael O'Keefe]
> def desired():
>pass
># IF we had a --> operator which would execute the method at
># left but return a ref to object
>#return [8,9,7,1].sort()-->reverse()-->pop(0)--> # returns [8,7,1]
># return [8,9,7,1].sort()-->reverse()-->pop(0) # returns 9
># r
[GvR]
>I recently needed to access an HTTP URL with a timeout. I ended up
> monkey-patching httplib.HTTPConnection so that the connect() method
> has an optional second paramer, timeout, defaulting to None; if not
> None, a call to settimeout() is added right after successful creation
> of the sock
[MvL]
> 1. For 2.5.1, rewrite slot_nb_inplace_power to raise an exception
> if the third argument is not None, and then invoke __ipow__ with only one
> argument.
[Raymond]
>> Why would you change Py2.5? There is no bug here.
[MvL]
> There is: slot_nb_inplace has the signature
>
> st
[Jack Jansen]
> I like the functionality, but I don't like the syntax, to me it looks
> too much like a method call.
>
> To me self.[method_name] = self.metadata.[method_name] looks better:
> what we're doing here is more like dictionary lookup than calling
> functions.
I also like the functionali
[Raymond Hettinger]
>> Rather than munge existing syntaxes, an altogether new one would be
>> more clear:
>>
>>self->name = self.metadata->name
[Ben North]
> One thing which comes to mind about this one is that, for C/C++
> programmers, the difference bet
* Teach vars() to work with classes defining __slots__. Essentially, __slots__
are just an implementation detail designed to make instances a bit more compact.
* Make the docstring writable for staticmethods, classmethods, and properties.
We did this for function objects and it worked-out well.
> On 2/15/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> I would like to be the one to migrate it to Py3.0.
[Steve]
> No complaints here. Not that you need my permission of course. ;-)
Thanks, I had already started working on this one.
Of course, everyone is wel
[Raymond Hettinger]
>>> * Add a pure python named_tuple class to the collections module.
>>> I've been using the class for about a year and found that it greatly
>>> improves the usability of tuples as records.
>>> http://aspn.activestate.com/ASPN/Cookboo
[Martin v. Löwis]
>Why does this still need to support the
> tuple interface (i.e. indexed access)?
I used named tuples whereever I need a tuple but the number and meaning
of the fields starts to tax my memory. For doctests, I return a named
tuple like TestResults(failed=0, attempted=15). That n
> Raymond Hettinger schrieb:
>> d, g, v, t, r = model(somecontract)
[MvL]
> I find that line quite unreadable
Of course, I can't give you the fully spelled-out line from proprietary code.
But at this point we're just talking about the use cases for tuples with or
without n
that it is not part of the API.
Thanks for the accolades and the suggestions.
Raymond
- Original Message -
From: "Michele Simionato" <[EMAIL PROTECTED]>
To:
Sent: Monday, February 19, 2007 9:25 PM
Subject: Re: [Python-Dev] Py2.6 ideas
> Raymond Hettinger verizon.net
More thoughts on named tuples after trying-out all of Michele's suggestions:
* The lowercase 'namedtuple' seemed right only because it's a function, but
as a factory function, it is somewhat class-like. In use, 'NamedTuple' more
closely matches my mental picture of what is happening and distingui
>> * I remembered why the __repr__ function had a 'show' argument. I've
>> changed the name now to make it more clear and added a docstring.
>> The idea was the some use cases require that the repr exactly match
>> the default style for tuples and the optional argument allowed for that
>> possibli
After thinking more about Py_ssize_t, I'm surprised that we're not hearing
about
64 bit users having a couple of major problems.
If I'm understanding what was done for dictionaries, the hash table can grow
larger than the range of hash values. Accordingly, I would expect large
dictionaries to
> My suspicion is that building Python for an 64-bit address space is
> still a somewhat academic exercise. I know we don't do this at Google
> (we switch to other languages long before the datasets become so large
> we'd need a 64-bit address space for Python). What's your experience
> at EWT?
Tw
[Greg Ewing]
> Writing code that depends on long sequences having things
> in particular positions is an anti-pattern,
Seems like you're against positional parameters in general.
What makes argument unpacking in a function definition different
that other positional parameter use cases.
Until c
[Phil Thompson]
> I think a lot of people care, but many can't
> do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people who assert that they have good use for them.
Ask the Georg-bot how readily he was acce
[Scott Dial]
>While I understand that this tit-for-tat mechanism is meant to ensure
>participation, I believe in reality it doesn't, as the 400-some
>outstanding patches you referenced elswhere indicate.
. . .
>If nothing else, as an outsider there is no way to know why your patch
>gets ignored
[Collin Winter]>
>Could I be granted rights to the SF tracker?
Done.
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
[Collin Winter]
>> I don't suppose you've changed your mind about removing operator.truth
>> and operator.abs in the seven months since this discussion?
[GvR]
>No, though I think that operator.truth should be renamed to operator.bool.
>
>I like the idea that for each built-in op there's a callable
[Facundo]
>> Me, for example, has an actual question to this list: "How can I know,
>> if I change something in the doc's .tex files, that I'm not broking
>> the TeX document structure?".
[MvL]
>You don't have to know. As a general contributor, just submit your
>patch, and perhaps the reviewer wil
[Žiga Seilnacht]
>I have just accepted an invitation to become a Python
>developer, so I feel obliged to introduce myself.
Welcome aboard.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
What are the current thoughts on when Py2.5.1 will go out?
Do we need a bug-day beforehand?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
[Raymond]
>> What are the current thoughts on when Py2.5.1 will go out?
>> Do we need a bug-day beforehand?
[AMK]
>A bug day would be a great idea! I have a mailbox bug that'd
>greatly benefit from discussion about how to fix the problem.
How about Sunday, April 1st?
Raymond
_
The xxsubtype.c module gives an example of calling a parent method if it is in
a slot:
static int
spamlist_init(spamlistobject *self, PyObject *args, PyObject *kwds)
{
if (PyList_Type.tp_init((PyObject *)self, args, kwds) < 0)
return -1;
self->state = 0;
return 0;
}
How you c
Re: www.python.org/sf/1687163
I noticed that RO members raise a TypeError upon an attempted write. In
contrast, we get an AttributeError when writing to a readonly property or to a
readonly method (such as those for builtin types).
IMO, the TypeError should really be an AttributeError. Howev
[Stephen Hansen=
> I just wanted to offer a gentle prod to see if a decision can be made;
> if any decision requires an adjustment to patches, tests and documentation,
> I'm willing to do them.
We should get a pronouncement on this or else whatever goes out in Py2.5.1
becomes the de-facto decisi
> Guido van Rossum wrote:
>> Isn't this violating the rule that a try/except should only enclose
>> the smallest expression where the exception is expected?
>
> Yeah, and I keep finding myself wanting to hyperlink to that "rule" in
> the official docs, but it only seems to be written down in devel
I believe the failures started with Facundo Batista's checkin on April 4th:
-
Author: facundo.batista
Date: Wed Apr 4 16:10:40 2007
New Revision: 54681
Modified:
python/trunk/Lib/test/test_socket_ssl.py
Log:
Fixed the way that the .pem files are looked for
Instead of a separate function in collections, it may be sensible to stick with
the familiar and provide a dictionary contructor for the commonly encounter use
case of counting things:
@classmethod
def fromcount(cls, iterable):
d = cls()
for elem in iterable:
d[elem] = d.get(elem,
m usually available on
AOL instant messaging with the screename: raymondewt
Likewise, consider soliciting Tim's input on how to implement the ln()
operation. That one will be tricky to get done efficiently and correctly.
Raymond
--- Begin Message ---
2007/4/10, Raymond Hettinger <[EMAIL
It looks like the release candidate has been held-up for a bit. If it is going
to stay held-up for a few days, can we unfreeze it so some bugfixes can go in
(fixing the +0/-0 problem, eliminating some segfaults, and fixing some
exception code)?
Raymond
Do any of the Iceland sprinters (Fredrik or Andrew perhaps) know why the
USE_FAST section is segregated and whether it is supposed to be on or off by
default?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
ave to wait.
Raymond
--- Begin Message ---
Raymond Hettinger schrieb:
> It looks like the release candidate has been held-up for a bit. If
> it is going to stay held-up for a few days, can we unfreeze it so
> some bugfixes can go in (fixing the +0/-0 problem, eliminating some
> segfaul
[Facundo Batista]
>The names, as the new functions will be discussed here in the second
>step. For example, I'm not absolute sure that something like...
>
Decimal("1100").xor(Decimal("0110")
>Decimal("1010")
>
>...is actually needed.
>
It doesn't matter. We promise to offer a full impleme
The pickle issue may be related to revision 53655 fixing a psuedo-bug (it was
arguable whether current or prior behavior was most desirable). Will look at
this more and will report back.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http:
Ralf, your issue is arising because of revision 53655 which fixes SF 1615701.
Subclasses of builtins are pickled using obj.__reduce_ex__() which returns
a tuple with a _reconstructor function and a tuple of arguments to that
function.
That tuple of arguments include the subclass name, the base cl
[Collin Winter]
> This should be fixed in r54844. The problem was that the availability
> of the urlfetch resource wasn't being checked early enough and so
> test_support.run_suite() was converting the ResourceDenied exception
> into a TestError instance. This wasn't showing up on other machines
>
[Skip]
> I use it all the time. For example, to build up (what I consider to be)
>readable SQL queries:
>
> rows = self.executesql("select cities.city, state, country"
>"from cities, venues, events, addresses"
>"where cities.city like %s"
>
>Raymond> I find that style hard to maintain. What is the advantage over
>Raymond> multi-line strings?
>
>Raymond> rows = self.executesql('''
>Raymond> select cities.city, state, country
>Raymond> from cities, venues, events, addresses
>Raymond> where cities.
> I'd like to suggest that we remove all (or nearly all) uses of
> xrange from the stdlib. A quick scan shows that most of the usage
> of it is unnecessary. With it going away in 3.0, and it being
> informally deprecated anyway, it seems like a good thing to go away
> where possible.
>
>Any obj
I question the sanity of the spec writers in this case, I do trust that
overall, they have provided an extremely well thought-out spec, have gone
through extensive discussion/feedback cycles, and have provided a thorough
test-suite. It is as good as it gets.
Ray
> The only rationale I can think of for such a thing is
> that maybe they're trying to accommodate the possibility
> of a machine built entirely around a hardware implementation
> of the spec, that doesn't have any other way of doing
> bitwise logical operations. If that's the case, then Python
>
> The only rationale I can think of for such a thing is
> that maybe they're trying to accommodate the possibility
> of a machine built entirely around a hardware implementation
> of the spec, that doesn't have any other way of doing
> bitwise logical operations.
Nonsense. The logical operations
Here some ideas that have been proposed for sets:
* New method (proposed by Shane Holloway): s1.isdisjoint(s2). Logically
equivalent to "not s1.intersection(s2)" but has an early-out if a common member
is found. The speed-up is potentially large given two big sets that may
largely overlap or
501 - 600 of 1487 matches
Mail list logo
