On 3/19/10 3:36 AM, C. Titus Brown wrote:
Hi all,
once again, the PSF has been accepted as a mentoring foundation for the Google
Summer of Code! This year, we're going to emphasize python 3 porting, so
please think of projects you'd like to see tackled.
Hi,
Does this mean that any other
On 3/19/2010 2:23 AM, Laurent Gautier wrote:
On 3/19/10 3:36 AM, C. Titus Brown wrote:
Hi all,
once again, the PSF has been accepted as a mentoring foundation for
the Google
Summer of Code! This year, we're going to emphasize python 3 porting, so
please think of projects you'd like to see
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
On Thu, Mar 18, 2010 at 22:38, Terry Reedy tjre...@udel.edu 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.
On Thu, Mar 18, 2010 at 9:48 PM, Nick Coghlan ncogh...@gmail.com 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,
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson dicki...@gmail.com 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
Glenn Linderman glenn at 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.
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
On Fri, Mar 19, 2010 at 4:52 PM, Nick Coghlan ncogh...@gmail.com wrote:
Dirkjan Ochtman wrote:
On Thu, Mar 18, 2010 at 22:38, Terry Reedy tjre...@udel.edu wrote:
Having gotten that far, I think this might be worth referencing in new
dev
docs.
Will do. I finally read hginit yesterday,
Mark Dickinson wrote:
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson dicki...@gmail.com 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,
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.
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 12:46 PM, Alex A. Naanou alex.na...@gmail.com 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.' %
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 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 TypeError here, as
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 ;
Thanks!
On Fri, Mar 19, 2010 at 16:05, Michael Foord fuzzy...@voidspace.org.uk 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__
...
a, b, c = A(),
On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson dicki...@gmail.com wrote:
Making hashes of int,
float, Decimal *and* Fraction all compatible with one another,
efficient for ints and floats, and not grossly inefficient
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 03:09, anatoly techtonik techto...@gmail.comwrote:
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
On Fri, 19 Mar 2010 10:09:16 +0200, anatoly techtonik techto...@gmail.com
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.
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
On Thu, Mar 18, 2010 at 12:41, Mark Dickinson dicki...@gmail.com 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
On Mar 19, 2010, at 4:50 AM, Antoine Pitrou wrote:
Glenn Linderman glenn at 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
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 means to
On 3/19/2010 5:00 AM, Dirkjan Ochtman wrote:
On Thu, Mar 18, 2010 at 22:38, Terry Reedytjre...@udel.edu 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
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
Raymond Hettinger raymond.hettinger at 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
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
On Mar 19, 2010, at 11:11 AM, Antoine Pitrou wrote:
Raymond Hettinger raymond.hettinger at 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
On 3/19/2010 4:50 AM, Antoine Pitrou wrote:
Glenn Lindermanglennat 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
On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
Raymond Hettingerraymond.hettingerat 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
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.
Glenn Linderman v+python at 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
Raymond Hettinger raymond.hettinger at 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
On 3/19/2010 11:43 AM, Terry Reedy wrote:
On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
Raymond Hettingerraymond.hettingerat 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
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
On Thu, Mar 18, 2010 at 20:20, Benjamin Peterson benja...@python.org 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
On Fri, 19 Mar 2010 14:09:28 -0400, Zvezdan Petkovic zvez...@zope.com 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
On Fri, 19 Mar 2010 12:39:58 -0400, A.M. Kuchling a...@amk.ca 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
On Fri, Mar 19, 2010 at 6:43 PM, Terry Reedy tjre...@udel.edu wrote:
On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
Raymond Hettingerraymond.hettingerat gmail.com writes:
The reason to prefer an exception is that decimal/float comparisons
are more likely to be a programmer error than an
On Fri, Mar 19, 2010 at 7:50 PM, Mark Dickinson dicki...@gmail.com 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 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,
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 Fri, 19 Mar 2010 12:16:35 -0700, Glenn Linderman v+pyt...@g.nevcal.com
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
2010/3/19 Brett Cannon br...@python.org:
On Thu, Mar 18, 2010 at 20:20, Benjamin Peterson benja...@python.org 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
Antoine, I think your email client turns replies whose subject
contains '' into new subjects containing sequences like this:
amp;amp; amp; lt; -amp;amp; 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
Guido van Rossum guido at python.org writes:
Antoine, I think your email client turns replies whose subject
contains '' into new subjects containing sequences like this:
amp;amp; amp; lt; -amp;amp; amp; gt;
There's a number of new threads with ever-more occurrences of amp in
the
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
Glenn Linderman v+python at 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.
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
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
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 increase
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
On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum gu...@python.org 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
Glenn Linderman v+python at 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
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
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.
On 3/19/2010 4:58 PM, Antoine Pitrou wrote:
Glenn Lindermanv+pythonat 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
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 20/03/2010 00:15, Glenn Linderman wrote:
On 3/19/2010 4:58 PM, Antoine Pitrou wrote:
Glenn Lindermanv+pythonat 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
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
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
Greg Ewing greg.ewing at 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
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
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
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
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
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
--
2010/3/19 Sean Reifschneider j...@tummy.com:
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
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 of Python
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
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 kinds of
73 matches
Mail list logo
