[Mart Sõmermaa]
To provide total ordering without __cmp__ one has to implement all of
__lt__, __gt__, __le__, __ge__, __eq__ and __ne__. However, in all
but a few cases it suffices only to provide a "real" implementation for
e.g. __lt__ and define all the other methods in terms of it as follows
s of it as follows:
[Raymond Hettinger]
FWIW, I'm working on a solution for the problem using class decorators.
The idea is that it would scan a class and fill-in missing methods based
on the ones already there. That way, any one of the four ordering
relations can be provided as a starting poi
[Michael Foord]
> Is there something you don't like about this one:
http://code.activestate.com/recipes/576529/
[Mart Sõmermaa ]
Yes -- it is not in the standard library. As I said, eventually all the 15,000
matches
on Google Code need to update their code and copy that snippet to their
uti
The current formatting mini-language provisions left/right/center alignment, prefixes for 0b 0x 0o, and rules on when to show the
plus-sign. I think it would be far more useful to provision a simple way of specifying a thousands separator.
Financial users in particular find the locale approach
[James Y Knight]
You might be interested to know that in India, the commas don't come
every 3 digits. In india, they come every two digits, after the first
three. Thus one billion = 1,00,00,00,000. How are you gonna represent
*that* in a formatting mini-language? :)
It is not the goal to
[Guido van Rossum]
I suggest moving this to python-ideas and
writing a proper PEP.
Okay, it's moved.
Will write up a PEP, do research on what other languages
do and collect everyone's ideas on what to put in the shed.
(hundreds and ten thousands grouping, various choices of
decimal points
[Lie Ryan]
How about having a country code field, e.g. en-us would format according
to US locale, in to India, ch to China, etc... that way the format
string would become very simple (although the lib maintainer would need
to know customs from all over the world). Then have a special country
ed suggestions by Lie Ryan and Eric Smith
---
PEP: XXX
Title: Format Specifier for Thousands Separator
Version: $Revision$
Last-Modified: $Date$
Author: Raymond Hettinger
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-
Fixed typo in the example with spaces and commas.
Discussion draft at: http://www.python.org/dev/peps/pep-0378/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
Does anyone think it was not a good idea to put in-place operations in the operator module? For some objects, they don't map() as
well as their regular counterparts. Some in-place operations rely on the interpreter to take care of the actual assignment. I've
not yet seen good use cases for op
Right. Since Python doesn't have a notation like "operator +" for
turning operators into functions, the operator module provides this
functionality. Better safe than sorry.
It doesn't really expose this functionality because some of the functionality
is buried in ceval.c and is not exposed by op
Maybe someone somewhere has some interesting use for
these in-place operator function. I hope so.
It could be important if you want apply it to mutable objects, i.e.
where the assignment doesn't do anything.
I give up. My original question was whether anyone thought these
were a good idea.
[Martin v. Löwis]
I would object to their removal, though,
because it would hurt my sense of symmetry.
I wasn't going to propose removal. If everyone had
agreed that the operator in-place functions were
problematic, I was going to suggest moving their
docs to a second page and documenting th
As a project maintainer I wouldn't want an intern being the most familiar
person with our Py3 migration, I'd rather students stick with new features
or optimization and coordinate the migration process as a group-wide effort.
Without help, it is going to take a long time to get many packag
[Benjamin Peterson]
It seems Andrew will be doing "What's new in Python 2.7?" again, but
we don't seem to have a volunteer to do the 3.1 version? Would anyone
like to volunteer?
I'll pick-up this responsibility.
Raymond
___
Python-Dev mailing list
Another thought: it would be nice is pydoc were built-out with
an alternate html generator that emitted clean, simple html
with the appropriate div/span tags so that CSS can be used
to control formatting. Right now, all of the formatting and
color coding is in-line. If you don't like the appea
Agreed, and more importantly, I have yet to be convinced that those NULL
checks introduce a measurable slowdown. Daniel, have you tried
measuring the performance difference with only the NULL checks removed?
I think it highly unlikely that there is a performance difference.
These tend to branc
4% on a micro-micro-benchmark is hardly compelling...
I concur! This is utterly insignificant and certainly does
not warrant removing the checks.
-1 on these sort of fake optimizations. We should focus
on algorithmic improvements and eliminating redundant
work and whatnot. Removing checks
Does anyone remember the reason that most of the named methods were omitted from the ABC for mutablesets and sets? The update()
method in particular would be nice to have.
RAymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
4% on a micro-micro-benchmark is hardly compelling...
I concur! This is utterly insignificant and certainly does
not warrant removing the checks.
-1 on these sort of fake optimizations. We should focus
on algorithmic improvements and eliminating redundant
work and whatnot. Removing checks
John Ehresman wrote:
* To what extent should non-debugger code use the hook? At one end of
the spectrum, the hook could be made readily available for non-debug use
and at the other end, it could be documented as being debug only,
disabled in python -O, & not exposed in the stdlib to python cod
The measurements are just a distractor. We all already know that the hook is
being added to a critical path. Everyone will pay a cost for a feature that
few people will use. This is a really bad idea. It is not part of a thorough,
thought-out framework of container hooks (something that woul
hts on the subject bug you, I'll happily
withdraw from the thread. I don't aspire to be a
source of negativity. I just happen to think this
proposal isn't a good idea.
Raymond
- Original Message -
From: "Guido van Rossum"
To: "Raymond Hettinger
It seems weird to me that Collin's group can be working
so hard just to get a percent or two improvement in
specific cases for pickling while python-dev is readily
entertaining a patch that slows down the entire language.
[Antoine Pitrou]
I think it's really more than a percent or two:
ht
Iterators can implement a method called __length_hint__ that provides a hint
to certain internal routines (such as list.extend) so they can operate more
efficiently. As far as I can tell, __length_hint__ is currently
undocumented. Should it be?
This has been discussed, and no, it is a implemen
Hrvoje Niksic wrote:
I've stumbled upon an oddity using sets. It's trivial to test if a
value is in the set, but it appears to be impossible to retrieve a
stored value,
See: http://code.activestate.com/recipes/499299/
Raymond
___
Python-Dev ma
[Nick Coghlan]
It doesn't quite work the way RDM desribed it - he missed a step.
Thanks for the clarification. We ought to write-out the process somewhere in a
FAQ.
It may also be instructive to step through the recipe that answers the OP's
original request, http://code.activestate.com/reci
+1 for removing constant folding for floats (besides conversion
of -). There are just too many things to worry about:
FPU rounding mode and precision, floating-point signals and flags,
effect of compiler flags, and the potential benefit seems small.
If you're talking about the existing peepho
[Tennessee Leeuwenburg ]
Now, I know that sets aren't ordered, but...
foo = set([1,2,3,4,5])
bar = [1,2,3,4,5]
foo.pop() will reliably return 1
while bar.pop() will return 5
discuss :)
If that's what you need:
http://code.activestate.com/recipes/576694/
Raymond
__
We're in the process of forward-porting the recent (massive) json updates to
3.1, and we are also thinking of dropping remnants of support of the bytes type
in the json library (in 3.1, again). This bytes support almost didn't work at
all, but there was a lot of C and Python code for it neverthe
[Antoine Pitrou]
Besides, Bob doesn't really seem to care about
porting to py3k (he hasn't said anything about it until now, other than that he
didn't feel competent to do it).
His actual words were: "I will need some help with 3.0 since I am not well versed in the changes to the C API or Pyth
Does anyone have any ideas about what to do with issue 5830 and handling the
problem in a general way (not just for sched)?
The basic problem is that decorate/compare/undecorate patterns no longer work when the primary sort keys are equal and the secondary
keys are unorderable (which is now the
Would it make sense to provide a default ordering whenever the types are
the same?
This doesn't work when they are not the same :-)
_ ~
@ @
\_/
Instead, you could make the decorating a bit more sophisticated:
decorated = [(key, id(value), value) for key, value in blah(values)]
or even:
I would discourage use of the decorate/sort/undecorate pattern,
and encourage use of the key= argument. Or, if you really need
to decorate into a tuple, still pass a key= argument.
The bug report was actually about the sched module which used
heapq to prioritize tuples consisting of times, pri
it would make more sense to me if it
stayed fixed at 56 sig digits for numbers larger than 1e50.
So I agree with this, even if the default # of sig digits were less.
Several reasons to accept Mark's proposal:
* It matches what C does and many languages tend to copy the
C standards with
In http://bugs.python.org/issue3959 , Clay McClure is raising some objections to the new ipaddr.py module. JP Calderone shares his
concerns. I think they were the only commenters not directly affiliated with one of the competing projects. The issues they've
raised seem serious, but I don't kno
We could remove it, but then what we have wouldn't really be a release
candidate anymore, so the release would get delayed.
Not true. There is a second release candidate scheduled on June 13th.
Removing the module involves doing "svn remove" on two files and
updating Misc/NEWS. Yesterday, ther
[GvR]
Whoa. Are you all suddenly trying to turn Python into a democracy?
Arthur: I am your king!
Woman: Well I didn't vote for you!
Arthur: You don't vote for kings.
Woman: Well how'd you become king then?
[Angelic music plays...]
Arthur: The Lady of the Lake, her arm clad in the purest s
[GvR]
Benjamin, what would be involved in removing it? I suppose there's the
module itself, some unit tests, and some docs. (I'm not asking you to
remove it yet -- but I'm asking to look into the consequences, so that
we can be sure to do the right thing before releasing 3.1 final.)
[Benjamin P
How about we just continue to improve both branches, doing forward or backports
as appropriate. No need to develop a policy of crippling one branch on the
theory that it will make the other seem more attractive.
Besides, if 2.7 and 3.2 get released within a few months of each other, any
inver
[David A. Barrett]
I propose adding the key parameter
to the bisect.bisect routines. This
would allow it to be used on lists with
an ordering other than the one "natural"
to the contained objects.
Algorithmically, the bisect routines are the wrong place to do key lookups.
If you do many calls
[Matthew Wilkes]
Oh, I didn't mean they should use proprietary software, just that in
my experience the kind of people who are active in open source are
quite anti-war, green, etc. There are notable exceptions, but I know
people who worry that their work will have military applications, an
FWIW, I think resurrecting contextlib.nested() is a bad idea.
Part of the justification for the new with-statement syntax was
that nested() doesn't have a way to finalize the constructors
if one of them fails. It is a pitfall for the unwary. And now
that we have the new with-statement syntax, i
I don't consider changing a DeprecationWarning to a
PendingDeprecationWarning "resurrecting" its target.
Seems like resurrection to me. Pending warnings are hidden
by default, so someone has to go look for it (and no one does this).
The problem with the nested() construct is not so much that
i
Not sure why we need yet another pep on the subject. Just update PEP 5 if
needed.
Also, I think there is a certain amount of wishful thinking here. Ideally, we could approve a tiny PEP with just a few bullet
points and it would eliminate the need for all of the complicated decision making tha
On behalf of the Python development team, I'm thrilled to announce the first
production release of Python 3.1.
Sweet!
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
[Jeffrey E. McAninch, PhD]
I very often want something like a try-except conditional expression similar
to the if-else conditional.
An example of the proposed syntax might be:
x = float(string) except float('nan')
or possibly
x = float(string) except ValueError float('nan')
+1
I've l
[Scott David Daniels]
I find I have a need in randomized testing for a shorter version
of getstate, even if it _is_ slower to restore. When running
exhaustive tests, a failure report should show the start state
of the generator. Unfortunately, our current state includes a
625-element array. I
[Antoine Pitrou]
I also think it would be a nice addition.
(but someone has to propose a patch :-))
I agree with Martin's reasons for rejecting the feature request
(see the bug report for his full explanation). IIRC, the compose()
idea had come-up and been rejected in previous discussions as
I was just wondering if a bytecode for a superinstruction of the common
sequence:
6 POP_TOP
7 LOAD_CONST 0 (None)
10 RETURN_VALUE
might be worth it.
[Collin Winter]
I doubt it. You'd save a bit of stack manipulation, but since this
will only appear at the end of a function, I'd be skeptica
I fail to understand this crude logic.
If a function contains any looping (C or otherwise) or does much in
the way of meaningful work, then it's unlikely that the single POP_TOP
associated with an implied "return None" is taking much of the total
runtime.
Raymond
On Sep 1, 2009, at 2:54 PM, Benjamin Peterson wrote:
2009/9/1 Brett Cannon :
On Tue, Sep 1, 2009 at 07:21, Benjamin
Peterson wrote:
2009/8/31 xiaobing jiang :
My idea is: here, the two functions (or maybe classes) should
have the
same behavior).
so is this a bug or something I missing ?
I concur. Numbers are naturally right aligned.
On Sep 7, 2009, at 2:46 PM, Eric Smith wrote:
The default string formatting alignment for all types, according to
PEP 3101, is left aligned. Issue 6857 (http://bugs.python.org/issue6857
) points out that for numeric types (int, float, and decim
And I sort of disagree with saying it's naturally left- or right-
aligned; as numbers are naturally (decimal) dot-aligned (if you use dot
to separate the whole and fractional part of your number).
How about, "naturally aligned by place value".
Raymond
__
On Sep 17, 2009, at 10:59 AM, Brett Cannon wrote:
On Thu, Sep 17, 2009 at 10:38, Georg Brandl wrote:
R. David Murray schrieb:
I floated a proposal on stdlib-sig to create a file named
Misc/maintainers.rst. The purpose of this file is to collect
knowledge
about who knows which modules well
[Michael Foord]
Are we definitely decided that 2.7 will be the last major release in the
2.x cycle?
ISTM, that would depend on the uptake for 3.2.
The users get a say in the matter.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://m
The positional parameter would also mean dicttemplate, and
would be deprecated (eventually requiring a keyword-only
parameter).
Although I hate the name 'dicttemplate', this seems like the best solution
to me. Maybe it's good that 'dicttemplate' is so ugly though so that people
will naturally
[Terry Reedy]
However it is done, I think someone (like new Python programmers) should
be able to program in Python3, and use everything in the stdlib, without
ever learning % formatting -- and that I should be able to forget about
it ;-).
+10 on the goal.
If that were possible, it would b
[Sridhar Ratnakumar]
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows
32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.
Did the test suite pass too?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
I don't know -- this is (from what Peter told me) a common use case so
he (and presumably others) would from time to time have to write
extra code to keep track of that IP address in a new app.
[MvL]
I, and probably others, would really, REALLY like to see one such
"common use case". I do fi
[Vinay Sajip]
And the special wrappers needn't be too intrusive:
__ = BraceMessage
logger.debug(__("Message with {0} {1}", 1, "argument"))
It looks like the BraceMessage would have to re-instantiate on every invocation.
Raymond
___
Python-Dev mai
[Steven Bethard]
. Just saying "ok, switch your format strings
from % to {}" didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.
Do the users get any say in this?
I imagine that some people are heavily invested in
[Terry Reedy]
I would agree, for instance, that an auto-translation
tool is needed.
We should get one written. ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.
Raymond
___
Python-Dev mailing list
Pyt
[Christian Tanzer]
How do you suppose that maintainers could ever do the transition from
%- to {}-formatting manually?
[Guido van Rossum]
This is pretty much the situation with integer division (you can only
recognize it by running the code),
Do you think there may be some possible parallel
[Mark Dickinson]
- string to float *and* float to string conversions are both guaranteed
correctly rounded in 3.x: David Gay's code implements the conversion
in both directions, and having correctly rounded string -> float
conversions is essential to ensure that eval(repr(x)) recovers x ex
[Glyph Lefkowitz ]
> This reasoning definitely makes sense to me; with all the
> dependency-migration
> issues 3.x could definitely use some carrots. However, I don't think I agree
> with it,
> because this doesn't feel like a big new feature, just some behavior which
> has changed.
The c
[John Arbash Meine]
So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
faster than (iter(s).next()).
The first version uses direct calls for the for-loop opcodes.
The other two have to do functions/method look-up and
make a pure python function call (neither is very fast).
FW
Chris Bergstresser]
I like the proposed set.get() method, personally.
Sets have been implemented in many languages, but I've only
seen one that implemented this functionality (the "arb" function
in SETL). For the most part, it seems that this is an uncommon need.
Also consider that th
[GvR]
I still wish we could go back in time and unify sets and dicts, if
only to find out how that experiment would turn out.
I'm curious about the outcome of another experiment along those lines.
Is anyone seeing uptake for the set methods on mapping views in Py3.x?
I haven't seen any code us
I'm curious about the outcome of another experiment along those lines.
Is anyone seeing uptake for the set methods on mapping views in Py3.x?
Next version of Graphine will use them heavily for graph
merges and set operations on graphs.
That's great! Thanks for the data point.
I look forwar
[Chris Bergstresser]
Still, I think my
point stands--it's a clear extrapolation from the existing dict.get().
Not really. One looks-up a key and supplies a default value if not found.
The other, set.get(), doesn't have a key to lookup.
A dict.get() can be meaningfully used in a loop (becaus
[geremy condra]
Was it ever decided whether this would fall under the moratorium?
Decided isn't the right word:
http://mail.python.org/pipermail/python-dev/2009-October/093373.html
FWIW, I'm a strong -1 on both proposals.
Just add a short get_one() function and a get_equivalent() recipe
to y
[Steven D'Aprano]
The suggested
semantics for set.get() with no arguments, as I understand them, are:
(1) it will only fail if the set is empty;
Just like next() except that next() gives you the option to supply a default
and can be used on any iterator (perhaps iter(s) or itertools.cycle(s)
As I said: Python 2 support is not only about supporting old versions of Python,
but also supporting users of Python2-only modules. So 2.7 support will
for the most part be a case not of supporting Python versions, but
Python *users*. And contrary to what Antoine said, that *is* a good
reason to b
[Guido van Rossum]
I'm -0 on backporting nonlocal to 2.7. I could be +0 if we added "from
__future__ import nonlocal_keyword" (or some such phrasing) to enable
it.
With the "from __future__" option, what keeps you from being
a full +1 on nonlocal? Is there something that makes it a better
so
[Michael Foord]
What will it take to *start* the port? (Or is it already underway?) For many projects I fear that it is only the impending
obsolescence (real rather than theoretical) of Python 2 that will convince projects to port.
FWIW, I do not buy into the several premises that have arisen
Personally, I have found it useful in doco I write to have a section on
"Common Tasks", with recommended/suggested examples of how to do them and
short rationale for the chosen method. It seems to me that if .pick()
is frequently desired and "None of the standard solutions are obvious
or easily di
[Steven D'Aprano]
Anyway, given the level of opposition to the suggestion, I'm no longer
willing to carry the flag for it. If anyone else -- perhaps the OP --
feels they want to take it any further, be my guest.
[geremy condra]
I've said before that I'd like there to be one, standard way of
[GvR]
I haven't seen substantial opposition against the PEP -- in fact I
can't recall any, and many people have explicitly posted in support of
it. So unless opposition suddenly appears in the next few days, I'll
move it to the Accepted state next Monday.
But it would have been so much fun to
[Chris Bergstresser]
> Clearly, I'll need to write up the PEP.
Why not write a short, fast get_first() function for your utils directory and
be done with it?
That could work with sets, mappings, generators, and other containers and
iterators.
No need to fatten the set/frozenset API for somethi
[me]
Why not write a short, fast get_first() function for your utils directory and
be done with it?
That could work with sets, mappings, generators, and other containers and
iterators.
No need to fatten the set/frozenset API for something so trivial and so rarely
needed.
Forgot to post the c
[Stefan Krah]
in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
questioning the reasons for allowing NaN comparisons with == and !=
rather than raising InvalidOperation.
Do you have any actual use case issues or are these theoretical musings?
I ask only because a good use cas
[Guido van Rossum]
. We used to have releases once a year and
we got really big serious feedback from our biggest users that the
release cycle was going too fast. We discussed it amply and agreed on
a minimum time of 18 months between releases.
If the language moratorium goes into effect, wou
[MvL]
I personally think that decoupling the releases would be best, i.e.
not start thinking about 3.2 for another 6 months.
[Benjamin]
The problem with that is that there is a period of time where 2.x has
features which 3.x doesn't. My preference is to move back the whole
schedule 6 months.
[Jacob Kaplan-Moss]
I've already started on a patch to make comments an option that
package maintainers could turn on or off, but I don't want to waste
any more time fighting this code unless I have some assurance it'll be
checked in.
I support your efforts.
Raymond
_
On Jan 25, 2010, at 11:22 AM, Steve Howell wrote:
> I am interested in creating a patch to make deleting elements from the front
> of Python list work in O(1) time by advancing the ob_item pointer.
+1 on doing whatever experiments you feel like doing
-1 on putting something like this in the cor
On Jan 25, 2010, at 12:36 PM, Steve Howell wrote:
>
> Deque does not support all the operations that list does. It is also roughly
> twice as slow for accessing elements (I've measured it).
ISTM that apps that want to insert or pop from the front of list are also apps
that don't care about
>>
>> Ah, but that applies for *large* lists. Adding 8 bytes to
>> each list
>> object applies to *all* lists. I betcha that many programs
>> use many
>> tiny lists.
>>
>
> Even most tiny-ish lists are wasting memory, though, according to this
> sequence:
>
> 4, 8, 16, 25, ...
>
That is onl
On Jan 27, 2010, at 11:38 AM, Martin v. Löwis wrote:
>> Lists are indeed used *everywhere* and *vast* quantities, which is
>> why optimizations on list operations are worthwhile to pursue.
>
> Unfortunately, the proposed change is a pessimisation, not an
> optimisation. We probably shouldn't dis
Are you free to chat about this in IRC?
I completely unconvinced that there are use cases for
wanting face random access to the i-th element of a large deque
that is changing sizes on each end. The meaning of the
20th index changes as the data moves. It becomes pointless
to store indices to movi
On Jan 27, 2010, at 2:56 PM, Steve Howell wrote:
>
> --- On Wed, 1/27/10, Raymond Hettinger wrote:
>
>> From: Raymond Hettinger
>> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
>> To: "Martin v. Löwis"
>> Cc: "Steve Ho
On Jan 27, 2010, at 3:55 PM, Maciej Fijalkowski wrote:
>>
>> FWIW, deque indexing for small deques is already O(1)
>> and somewhat fast. You only get O(n) degradation
>> (with a small contant factor) on large deques.
>>
>
> Hi.
>
> For small dequeues (smaller than a constant), you have to ha
On Jan 30, 2010, at 4:00 PM, Barry Warsaw wrote:
> Abstract
>
>
> This PEP describes an extension to Python's import mechanism which
> improves sharing of Python source code files among multiple installed
> different versions of the Python interpreter.
+1
> It does this by
> allowin
+1
On Feb 2, 2010, at 10:08 AM, Barry Warsaw wrote:
> I'm thinking about doing a Python 2.6.5 release soon. I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on
On Feb 9, 2010, at 9:54 PM, anatoly techtonik wrote:
>
> Is it possible to make exploits out of crashers?
The crashers involve creating convoluted python code,
but then if you're in a position to execute arbitrary
Python code, then you don't have to resort to any
tricks to do something nasty wit
>
> On Tue, Mar 2, 2010 at 15:55, Florent Xicluna
> wrote:
> Hello,
>
> I would like to open a discussion on the meaning of deprecation warnings in
> 2.7.
> I assume, but I may be wrong, that 2.7 will be the last version in the 2.x
> branch. With this assumption, we should not find many thin
On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
> I'd say if you're not going to forward-port this to Python 3, it
> shouldn't go into Python 2 -- in that case it would make more sense to
> me to back-port the exception-raising behavior.
Python 3 doesn't need it because it is possible to
On Mar 16, 2010, at 3:16 PM, Greg Ewing wrote:
>
> Seems to me that this education would mostly consist of saying
> "don't compare floats and decimals", which is why I think that
> disallowing them in the first place would be better.
That makes sense.
I do worry that 2.x currently does make the
On Mar 17, 2010, at 12:34 PM, Terry Reedy wrote:
>
> I agree. Improving 2.7 and not 3.2+ would give people a reason to not move to
> 3.x.
>
FWIW, I think this is mischaracterizing the proposal.
The spectrum of options from worst to best is
1) compare but give the wrong answer
2) compare but g
On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
> On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
>> The spectrum of options from worst to best is
>> 1) compare but give the wrong answer
>> 2) compare but give the right answer
>> 3) refuse to com
301 - 400 of 1487 matches
Mail list logo
