On Mar 17, 2010, at 5:02 PM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> Python 3 doesn't need it because it is possible to not give a result
>> at all. Python 2 does need it because we have to give *some*
>> result.
>
> That's not true -- it's possible for comparisons to raise
> an exce
Raymond Hettinger wrote:
Python 3 doesn't need it because it is possible to not give a result
at all. Python 2 does need it because we have to give *some*
result.
That's not true -- it's possible for comparisons to raise
an exception in 2.x, and they sometimes do already:
Python 2.5.4 (r254:
Guido van Rossum wrote:
in some
"intuitive complexity" sense an int is a simpler type than a float and
a float is a simpler type than a Decimal
I don't think this analogy holds. In a mathematical sense,
ints are a subset of reals, but binary and decimal floats
are just alternative approximate r
Steven D'Aprano wrote:
More explicit than someDecimal == someFloat? Seems pretty explicit to
me.
Yes. I mean at least specifying either float(someDecimal) == someFloat
or someDecimal == Decimal(someFloat). Preferably also whether the
conversion is to be as exact as possible or on a minimum-d
On Wed, Mar 17, 2010 at 1:44 PM, Raymond Hettinger
wrote:
>
> 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
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 compare.
>
> Why is 3 the best? If there
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 compare.
>
> Why is 3 the best? If there is a right answer to give, sur
Martin v. Löwis v.loewis.de> writes:
>
> > As mentioned I have access to a 16GB machine which is able to run the
> > tests. The problem is that nobody seems interested in maintaining these
> > tests.
>
> So what do you propose to do?
Nothing. I was pointing out the issue here because it is not
Tim Lesher wrote:
> Now that Windows 9x is no longer supported (per PEP 11), would it be
> appropriate to replace the ANSI ("A") versions of Windows OS calls in
> posixmodule.c with their Unicode ("W") equivalents and remove the
> unicode_file_names() function that determines which version to call?
> As mentioned I have access to a 16GB machine which is able to run the
> tests. The problem is that nobody seems interested in maintaining these
> tests.
So what do you propose to do?
I personally don't see that as a problem. Many rarely-used features get
infrequent testing - that's the nature o
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 compare.
Why is 3 the best? If there is a right answer to give, surely giving the
right answer it i
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
Now that Windows 9x is no longer supported (per PEP 11), would it be
appropriate to replace the ANSI ("A") versions of Windows OS calls in
posixmodule.c with their Unicode ("W") equivalents and remove the
unicode_file_names() function that determines which version to call?
There are a number of pl
On 3/17/2010 1:09 PM, Guido van Rossum wrote:
Ok, I'll try to stay out of the discussion of which solution is best
of our users, and if the outcome is that mixed operations in general
are bad but mixed comparisons are good, I'll trust you. However I want
to reiterate that you really shouldn't im
Hello,
Le mercredi 17 mars 2010 à 11:58 -0700, C. Titus Brown a écrit :
> On Wed, Mar 17, 2010 at 06:54:33PM +, Antoine Pitrou wrote:
> > The title says it all. test_bigmem and test_bigaddrspace are partly
> > broken under py3k, and no buildbot ever tests that they run successfully.
> > As a
Hello,
The title says it all. test_bigmem and test_bigaddrspace are partly
broken under py3k, and no buildbot ever tests that they run successfully.
As an example, here is a test_bigmem run under a 16GB machine. It gets
"killed" at some point, probably by the Linux kernel's OOM killer,
althoug
On Wed, Mar 17, 2010 at 8:04 AM, Mark Dickinson wrote:
> On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum wrote:
>> Definitely some. Stricter comparison rules are a frequent cause of
>> problems when code is first ported to 3.x. While you'd think that code
>> comparing a float and a Decimal is *
On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum wrote:
> Definitely some. Stricter comparison rules are a frequent cause of
> problems when code is first ported to 3.x. While you'd think that code
> comparing a float and a Decimal is *already* broken, there's a
> surprising number of situations
On Wed, Mar 17, 2010 at 11:43 AM, Steven D'Aprano wrote:
> Having said all that, I've just re-read the PEP, and spotted a fly in
> the ointment... hash.
>
> If we allow Decimals to compare equal to floats, that presumably implies
> that they need to hash equal. That may be simple enough for intege
On Wed, Mar 17, 2010 at 12:36 AM, Raymond Hettinger
wrote:
>
> On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
>>
>> Also supporting comparisons but not other mixed operations is going to
>> be confusing. If you are sticking to that behavior I think mixed
>> comparisons should also be ruled o
On Tue, Mar 16, 2010 at 10:32 PM, Steven D'Aprano wrote:
> On Wed, 17 Mar 2010 03:23:30 am Mark Dickinson wrote:
>> On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson
>> wrote: [...]
>>
>> Decimal.from_float(1.1) == 1.1
>> >
>> > False
>>
>> Whoops. To clarify, this is the pre-patch behaviour;
On Tue, Mar 16, 2010 at 10:16 PM, Greg Ewing
wrote:
> Mark Dickinson wrote:
>>
>> On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby wrote:
>>
>>> If not, it might be confusing if a number that prints as '.1' compares
>>> unequal to Decimal('.1').
>>
>> Agreed, but this is just your everyday floating-poin
I'm not sure I see any inherent problem in putting all I/O bound threads in
some kind of FIFO queue. However, there still should be some mechanism that
gives those threads priority over a CPU-bound thread that never wants to give
up the GIL. A common OS solution is to simply have multiple FIF
On Wed, 17 Mar 2010 10:01:12 am Guido van Rossum wrote:
> On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano
wrote:
> > But mixed arithmetic runs into the problem, what do you want the
> > result type to be? Given (say) decimal+float, returning either a
> > Decimal or a float will be the wrong thin
> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
> Sent: 16. mars 2010 22:08
> To: Kristján Valur Jónsson
> Cc: Antoine Pitrou; python-dev@python.org
> Subject: Re: [Python-Dev] "Fixing" the new GIL
>
> Kristján Valur Jónsson wrote:
> > We have never had high priorit
I could also point you at EVE online, a large scale IO machine based on
stackless python. Our game proxies (front end servers) handle 30.000 client
connections each using tasklets. The problem is coarse grained scheduling of
IO and other tasks, same as with threads in regular Python. We have
On Wed, 17 Mar 2010 12:27:01 pm Raymond Hettinger wrote:
> 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.
>
27 matches
Mail list logo
