On 3/19/2010 9:20 PM, Nick Coghlan wrote:
Glenn Linderman wrote:
> The same person that would expect both
>
> 0 == "0"
> 0.0 == "0.0"
>
> to be False... i.e. anyone that hasn't coded in Perl for too many years.
Completely different - that is comparing numbers to strings.
On
Glenn Linderman wrote:
> The same person that would expect both
>
> 0 == "0"
> 0.0 == "0.0"
>
> to be False... i.e. anyone that hasn't coded in Perl for too many years.
Completely different - that is comparing numbers to strings. What this
discussion is about is comparison between the different
I am generally happy with the tracker workflow and in my experience,
issues that are lingering are lingering for a good reason.
I've decided to add my two cents to this thread because I've just had
a negative experience with how issue 8154 and my input to it were
handled.
I will not go into detai
On Sat, Mar 20, 2010 at 12:00:48AM +0100, "Martin v. L?wis" wrote:
> > Whether this is worth weeks of work or not will depend on a given
> > student's knowledge about Python 3, and I'd suspect that the GSoC would
> > be an opportunity for a number of applicant to actually learn the
> > intricacies
2010/3/19 Sean Reifschneider :
> Issue 2356 ( http://bugs.python.org/issue2356 ) looks like it has a patch
> candidate, but just needs review to put in place. Seems like it may be
> low hanging fruit critical that just needs a quick review to either apply
> or at least get back to the folks who ar
Issue 2356 ( http://bugs.python.org/issue2356 ) looks like it has a patch
candidate, but just needs review to put in place. Seems like it may be
low hanging fruit critical that just needs a quick review to either apply
or at least get back to the folks who are working on a patch.
Thanks,
Sean
--
On Sat, 20 Mar 2010 08:50:04 am Guido van Rossum wrote:
> I'd like to reboot this thread. I've been spinning this topic in my
> head for most of the morning, and I think we should seriously
> reconsider allowing mixed arithmetic involving Decimal, not just
> mixed comparisons. [Quick summary: embed
On 3/19/2010 5:20 PM, Michael Foord wrote:
On 20/03/2010 00:19, Glenn Linderman wrote:
On 3/19/2010 5:18 PM, Michael Foord wrote:
will probably get you buggy results, somehow or another. That's what
> design, code reviews, and testing are for.
We'll have to "agree to disagree" then. If you want
Glenn Linderman wrote:
In order to do
implicit comparisons, one must do an implicit coercion. Hence the PEP
actually already prohibits implicit comparisons, as well as implicit
arithmetic.
Not necessarily -- you could compare them as though they
had both been converted to the equivalent rati
Glenn Linderman wrote:
Sounds to me like containment checking is wrong; that if it gets an
exception during the comparison that it should assume unequal, rather
than aborting, and continue to the next entry.
What exception would it catch, though? Catching something as
generic as TypeError wou
Greg Ewing canterbury.ac.nz> writes:
>
> So do you think that float("0.1") and Decimal("0.1") should be
> equal or not, and why?
Given that float("0.1") is not the mathematical 0.1, while Decimal("0.1") is,
I'd say no.
___
Python-Dev mailing list
Pyt
On 20/03/2010 00:19, Glenn Linderman wrote:
On 3/19/2010 5:18 PM, Michael Foord wrote:
will probably get you buggy results, somehow or another. That's what
> design, code reviews, and testing are for.
We'll have to "agree to disagree" then. If you want error silencing
by default,
Python is not
On 3/19/2010 5:18 PM, Michael Foord wrote:
will probably get you buggy results, somehow or another. That's what
> design, code reviews, and testing are for.
We'll have to "agree to disagree" then. If you want error silencing
by default,
Python is not the language you are looking for.
We can a
On 20/03/2010 00:15, Glenn Linderman wrote:
On 3/19/2010 4:58 PM, Antoine Pitrou wrote:
Glenn Linderman g.nevcal.com> writes:
> > If there's a bug in your __eq__ method, it may or may not raise an
> exception, which may or may not get you wrong containment results.
But
> it will probably get y
Antoine Pitrou wrote:
We forbid comparisons when there is a real danger or ambiguity, such as unicode
vs. bytes. There is no such danger or ambiguity when comparing a decimal with a
float.
So do you think that float("0.1") and Decimal("0.1") should be
equal or not, and why?
--
Greg
__
On 3/19/2010 4:58 PM, Antoine Pitrou wrote:
Glenn Linderman g.nevcal.com> writes:
>
> If there's a bug in your __eq__ method, it may or may not raise an
> exception, which may or may not get you wrong containment results. But
> it will probably get you buggy results, somehow or anoth
On 3/19/2010 2:50 PM, Guido van Rossum wrote:
I'd like to reboot this thread.
I'll go along with that idea!
I've been spinning this topic in my
head for most of the morning, and I think we should seriously
reconsider allowing mixed arithmetic involving Decimal, not just mixed
comparisons.
Nick Coghlan wrote:
Mark Dickinson wrote:
It seems to me that given the existing conflation of numeric equivalence
and containment testing, going the whole hog and fixing the set
membership problem for all of our rational types would be the right
thing to do.
Isn't this only solving half the
Glenn Linderman g.nevcal.com> writes:
>
> If there's a bug in your __eq__ method, it may or may not raise an
> exception, which may or may not get you wrong containment results. But
> it will probably get you buggy results, somehow or another. That's what
> design, code reviews, and testing
On 3/19/2010 3:02 PM, Antoine Pitrou wrote:
Glenn Linderman g.nevcal.com> writes:
>
> Sounds to me like containment checking is wrong; that if it gets an
> exception during the comparison that it should assume unequal, rather
> than aborting, and continue to the next entry.
Wel
On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum wrote:
> As a downside, there is the worry that inadvertent mixing of Decimal
> and float can compromise the correctness of programs in a way that is
> hard to detect. But the anomalies above indicate that not fixing the
Decimal already has somet
Just a couple of quick side comments on this; I haven't got my head
around the whole mixed-operations idea yet.
On Fri, Mar 19, 2010 at 9:50 PM, Guido van Rossum wrote:
> There is one choice which I'm not sure about. Should a mixed
> float/Decimal operation return a float or a Decimal?
I'll jus
On 3/19/2010 3:16 PM, Glenn Linderman wrote:
I perceive that the whole thread is about _all_ comparison operators with
one float and one decimal operand currently producing an exception (3.x)
Not true for equality comparison. That returns False regardless of
value, just as order comparisons r
> Whether this is worth weeks of work or not will depend on a given
> student's knowledge about Python 3, and I'd suspect that the GSoC would
> be an opportunity for a number of applicant to actually learn the
> intricacies of Python 3.
> Developing Python 3-specific features could be used to incre
On behalf of the Python community, I'm happy to announce the availability of
Python 2.6.5 final. This is the latest production-ready version in the Python
2.6 series.
Python 2.6.5 fixes dozens of issues in the core, built-in modules, libraries,
and documentation since Python 2.6.4 was released ba
On Mar 19, 2010, at 2:50 PM, Guido van Rossum wrote:
> I'd like to reboot this thread. I've been spinning this topic in my
> head for most of the morning, and I think we should seriously
> reconsider allowing mixed arithmetic involving Decimal, not just mixed
> comparisons. [Quick summary: embed
Glenn Linderman g.nevcal.com> writes:
>
> Sounds to me like containment checking is wrong; that if it gets an
> exception during the comparison that it should assume unequal, rather
> than aborting, and continue to the next entry.
Well as the Zen says:
Errors should never pass silently.
Unless
I'd like to reboot this thread. I've been spinning this topic in my
head for most of the morning, and I think we should seriously
reconsider allowing mixed arithmetic involving Decimal, not just mixed
comparisons. [Quick summary: embed Decimal in the numeric tower but
add a context flag to disallow
Guido van Rossum python.org> writes:
>
> Antoine, I think your email client turns replies whose subject
> contains '&' into new subjects containing sequences like this:
>
> & amp; lt; -& amp; gt;
>
> There's a number of new threads with ever-more occurrences of "amp" in
> the subject,
I found an old thread on Python-Dev that suggested replacing the error
"TypeError: expected a character buffer object" with something more helpful
for non-experts like "expected a string or character buffer". Here's the
thread: http://mail.python.org/pipermail/python-dev/2006-May/065301.html
I thi
Antoine, I think your email client turns replies whose subject
contains '&' into new subjects containing sequences like this:
& amp; lt; -& amp; gt;
There's a number of new threads with ever-more occurrences of "amp" in
the subject, and you are the first poster in each thread (and the
f
2010/3/19 Brett Cannon :
> On Thu, Mar 18, 2010 at 20:20, Benjamin Peterson wrote:
>> Pending the resolution of a few Mac OS issues (#8068, #8069, and
>> #8133), I'm not going to tag the release at the moment. Hopefully,
>> we'll still be able to have a release in the next week.
>
> Do you want is
On Fri, 19 Mar 2010 12:16:35 -0700, Glenn Linderman
wrote:
> On 3/19/2010 11:43 AM, Terry Reedy wrote:
> > It still strikes me as a bit crazy for Python to say that 0.0 == 0 and
> > 0 == Decimal(0) but that 0.0 != Decimal(0). Who would expect such a
> > thing?
>
> The same person that would ex
On 19/03/2010 18:58, Pascal Chambon wrote:
Hello
I've already crossed a bunch of articles detailing python's attribute
lookup semantic (__dict__, descriptors, order of base class
traversing...), but I have never seen, so far, an explanation of WHICH
method did waht, exactly.
I assumed that
On 3/19/2010 12:50 PM, Mark Dickinson wrote:
Hah. This is a very good point, and one I'd somehow missed up until
now. I don't think we*can* reasonably make equality comparisons
raise NotImplemented (in either 2.x or 3.x), since that messes up
containment tests: something like "1.0 in {2, Deci
On Fri, Mar 19, 2010 at 7:50 PM, Mark Dickinson wrote:
> So the patch
> I've put on the issue tracker is wrong, since it does raise TypeError ...
s/I've put/I have yet to put/
I really shouldn't admit to errors in things that I haven't even been
made public yet. :)
Mark
___
On Fri, Mar 19, 2010 at 6:43 PM, Terry Reedy wrote:
> On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
>>
>> Raymond Hettinger gmail.com> writes:
>>>
>>> The reason to prefer an exception is that decimal/float comparisons
>>> are more likely to be a programmer error than an intended behavior.
>
> If
On Fri, 19 Mar 2010 12:39:58 -0400, "A.M. Kuchling" wrote:
> On Fri, Mar 19, 2010 at 10:22:05AM -0400, R. David Murray wrote:
> > > Real world example with issue8151. It is an issue with a trivial patch
> > > in it. Everything what is needed is to dispatch it to stable `commit
> > > queue` and por
On Fri, 19 Mar 2010 14:09:28 -0400, Zvezdan Petkovic wrote:
> On Mar 19, 2010, at 1:15 PM, Terry Reedy wrote:
> > On 3/19/2010 10:22 AM, R. David Murray wrote:
> >> This can be done by anyone just by saying, eg: 'see issue 1234' (roundup
> >> turns that into a link),
> >
> > That should be 'see i
On Thu, Mar 18, 2010 at 20:20, Benjamin Peterson wrote:
> Pending the resolution of a few Mac OS issues (#8068, #8069, and
> #8133), I'm not going to tag the release at the moment. Hopefully,
> we'll still be able to have a release in the next week.
Do you want issue8133 to be a release blocker?
Hello
I've already crossed a bunch of articles detailing python's attribute
lookup semantic (__dict__, descriptors, order of base class
traversing...), but I have never seen, so far, an explanation of WHICH
method did waht, exactly.
I assumed that getattr(a, b) was the same as a.__getattribu
On 3/19/2010 11:43 AM, Terry Reedy wrote:
On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
Raymond Hettinger gmail.com> writes:
The reason to prefer an exception is that decimal/float comparisons
are more likely to be a programmer error than an intended behavior.
If you really believe that, the
Raymond Hettinger gmail.com> writes:
>
> The conversion of a float to a decimal is not as straight-forward
> (most people don't even know that an exact conversion is possible).
I still don't follow you. You are saying that an exact conversion is possible,
but don't want it to be done because it
Glenn Linderman g.nevcal.com> writes:
>
> So when a coder choose to use Decimal, it is because float is
> inappropriate. Because float is inappropriate, mixing Decimal and float
> is inappropriate. Having the language coerce implicitly, is
> inappropriate.
I'm sorry but this is very dogmati
On Mar 19, 2010, at 11:42 AM, Glenn Linderman wrote:
>>
>
> The whole point of providing Decimal is for applications for which float is
> inappropriate. I didn't think I needed to reproduce PEP 327 in my email.
>
> So when a coder choose to use Decimal, it is because float is inappropriate.
On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
Raymond Hettinger gmail.com> writes:
The reason to prefer an exception is that decimal/float comparisons
are more likely to be a programmer error than an intended behavior.
If you really believe that, then equality comparisons should also be
disa
On 3/19/2010 4:50 AM, Antoine Pitrou wrote:
Glenn Linderman nevcal.com> writes:
On the other hand, if the default behavior is to do an implicit
conversion, I don't know of any way that that could be turned into an
exception for those coders that don't want or don't like the particular
type
On Mar 19, 2010, at 11:11 AM, Antoine Pitrou wrote:
> Raymond Hettinger gmail.com> writes:
>>
>> The reason to prefer an exception is that decimal/float comparisons
>> are more likely to be a programmer error than an intended behavior.
>
> Not more so than float/int or decimal/int or bool/int
On Mar 19, 2010, at 1:15 PM, Terry Reedy wrote:
> On 3/19/2010 10:22 AM, R. David Murray wrote:
>
>> This can be done by anyone just by saying, eg: 'see issue 1234' (roundup
>> turns that into a link),
>
> That should be 'see issue #1234' to get the autolink.
> From http://wiki.python.org/moin/
Raymond Hettinger gmail.com> writes:
>
> The reason to prefer an exception is that decimal/float comparisons
> are more likely to be a programmer error than an intended behavior.
Not more so than float/int or decimal/int or bool/int comparisons, which all
work.
We forbid comparisons when there
On 3/19/2010 8:46 AM, Alex A. Naanou wrote:
A friend of mine stumbled upon the following behavior:
[snip]
Questions like this are more appropriately posted to python-list, where
you would have gotten the same answer.
tjr
___
Python-Dev mailing li
On 3/19/2010 5:00 AM, Dirkjan Ochtman wrote:
On Thu, Mar 18, 2010 at 22:38, Terry Reedy wrote:
Having gotten that far, I think this might be worth referencing in new dev
docs.
Will do. I finally read hginit yesterday, after having seen people
rave about it on twitter for a few weeks, and it's
On 3/19/2010 10:22 AM, R. David Murray wrote:
This can be done by anyone just by saying, eg: 'see issue 1234' (roundup
turns that into a link),
That should be 'see issue #1234' to get the autolink.
From http://wiki.python.org/moin/TrackerDocs/
The tracker converts some specially formatted wor
On Fri, Mar 19, 2010 at 10:22:05AM -0400, R. David Murray wrote:
> > Real world example with issue8151. It is an issue with a trivial patch
> > in it. Everything what is needed is to dispatch it to stable `commit
> > queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
> > have no me
On Mar 19, 2010, at 4:50 AM, Antoine Pitrou wrote:
> Glenn Linderman nevcal.com> writes:
>>
>> On the other hand, if the default behavior is to do an implicit
>> conversion, I don't know of any way that that could be turned into an
>> exception for those coders that don't want or don't like t
On Thu, Mar 18, 2010 at 12:41, Mark Dickinson wrote:
> I'm only seeing two arguments against this at the moment: (1) it has
> the potential to break code that relies on being able to sort
> heterogeneous lists. But given that heterogeneous lists can't be
> sorted stably anyway (see my earlier pos
On 3/19/10 12:57 PM, Arc Riley wrote:
Hi Laurent
If your community project would like help porting to Python 3, and you
feel this work is enough for a student to work full time for several
weeks on, then please do add it to the GSoC ideas page on the wiki.
Whether this is worth weeks of work o
On Fri, 19 Mar 2010 10:09:16 +0200, anatoly techtonik
wrote:
> I want to push some of my patches before 2.7 and use 5-1 rule for
> that, but I can't come up with any review workflow other than mailing
> status of my comments to the issues here. I can't mark issues in any
> way. How about giving u
On Fri, Mar 19, 2010 at 03:09, anatoly techtonik wrote:
> I want to push some of my patches before 2.7 and use 5-1 rule for
> that, but I can't come up with any review workflow other than mailing
> status of my comments to the issues here. I can't mark issues in any
> way. How about giving users a
Sean Reifschneider wrote:
If you call:
from syslog import syslog, openlog
syslog('My error message')
Something like the following gets logged:
Mar 18 05:20:22 guin python: My error message
^^
Where I'm annoyed by the "python" in the above. This is pulled
On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson wrote:
> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
>> Making hashes of int,
>> float, Decimal *and* Fraction all compatible with one another,
>> efficient for ints and floats, and not grossly inefficient for
>> Fractions and Decimals, i
Thanks!
On Fri, Mar 19, 2010 at 16:05, Michael Foord wrote:
> On 19/03/2010 12:46, Alex A. Naanou wrote:
>>
>> [snip...]
>
> class C(object):
>
>>
>> ... def __radd__(self, other):
>> ... print 'C: adding C and %s objects.' % other.__class__.__name__
>> ...
>>
>
>
M> Is Python-dev going to consider shifting their repo to mercurial/git
M> instead of SVN? :)
Yes, Dirkjan has been working on it. My initial experience with hg as a
quick way to revision control anything anywhere on a small scale ("hmmm, I
should track changes to /etc/hosts... cd /etc ;
On Fri, Mar 19, 2010 at 03:46:07PM +0300, Alex A. Naanou wrote:
> >>> class C(object):
> ... def __radd__(self, other):
> ... print 'C: adding C and %s objects.' % other.__class__.__name__
> ...
> >>> 1 + c
> C: adding C and int objects.
>
> My first expectation would be to get a TypeE
On 19/03/2010 12:46, Alex A. Naanou wrote:
[snip...]
class C(object):
... def __radd__(self, other):
... print 'C: adding C and %s objects.' % other.__class__.__name__
...
a, b, c = A(), B(), C()
1 + c
C: adding C and int objects.
That is the whole
On Fri, Mar 19, 2010 at 12:46 PM, Alex A. Naanou wrote:
> A friend of mine stumbled upon the following behavior:
>
>
> ---cut---
>
class A(object): pass
> ...
class B(object):
> ... def __add__(self, other):
> ... print 'B: adding B and %s objects.' % other.__class__.__name__
Hi,
A friend of mine stumbled upon the following behavior:
---cut---
>>> class A(object): pass
...
>>> class B(object):
... def __add__(self, other):
... print 'B: adding B and %s objects.' % other.__class__.__name__
...
>>> class C(object):
... def __radd__(self, other):
...
On Fri, Mar 19, 2010 at 04:59:38PM +0500, M. Shuaib Khan wrote:
> Is Python-dev going to consider shifting their repo to mercurial/git instead
> of SVN? :)
http://mail.python.org/pipermail/python-dev/2009-March/087931.html
The decision was made about a year ago.
http://www.python.org/dev/peps
Mark Dickinson wrote:
> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
> For ints, this hash function is almost identical to what Python
> already has, except that the current int hash does a reduction modulo
> 2**32-1 or 2**64-1 rather than 2**31-1. For all small ints, hash(n)
> == n, as
On Fri, Mar 19, 2010 at 4:52 PM, Nick Coghlan wrote:
> Dirkjan Ochtman wrote:
> > On Thu, Mar 18, 2010 at 22:38, Terry Reedy wrote:
> >> Having gotten that far, I think this might be worth referencing in new
> dev
> >> docs.
> >
> > Will do. I finally read hginit yesterday, after having seen peo
Hi Laurent
If your community project would like help porting to Python 3, and you feel
this work is enough for a student to work full time for several weeks on,
then please do add it to the GSoC ideas page on the wiki.
There will be another program running for high school students which is more
s
Dirkjan Ochtman wrote:
> On Thu, Mar 18, 2010 at 22:38, Terry Reedy wrote:
>> Having gotten that far, I think this might be worth referencing in new dev
>> docs.
>
> Will do. I finally read hginit yesterday, after having seen people
> rave about it on twitter for a few weeks, and it's a very frie
Glenn Linderman nevcal.com> writes:
>
> On the other hand, if the default behavior is to do an implicit
> conversion, I don't know of any way that that could be turned into an
> exception for those coders that don't want or don't like the particular
> type of implicit conversion chosen.
You s
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
> Making hashes of int,
> float, Decimal *and* Fraction all compatible with one another,
> efficient for ints and floats, and not grossly inefficient for
> Fractions and Decimals, is kinda hairy, though I have a couple of
> ideas of how it cou
On Thu, Mar 18, 2010 at 9:48 PM, Nick Coghlan wrote:
> Note that even in Py3k there are some fairly serious weirdnesses kicking
> around due to the intransitive nature of numeric equality though:
Yep. My personal favourite is:
>>> from decimal import Decimal as dec
>>> set((1, 1.0, dec(1))) ==
On Thu, Mar 18, 2010 at 22:38, Terry Reedy wrote:
> Having gotten that far, I think this might be worth referencing in new dev
> docs.
Will do. I finally read hginit yesterday, after having seen people
rave about it on twitter for a few weeks, and it's a very friendly
introduction.
Cheers,
Dirk
I want to push some of my patches before 2.7 and use 5-1 rule for
that, but I can't come up with any review workflow other than mailing
status of my comments to the issues here. I can't mark issues in any
way. How about giving users ability to set flags or keywords? Maybe
entering a separate field
77 matches
Mail list logo
