[Python-Dev] Bug? syslog.openlog using ident "python" by default.
I'd appreciate some opinions on this. Personally, I'm in the "the current
code is buggy" camp. :-) I can code up the changes to the syslog module
if we decide that's the right way to go. Looks like Raymond, Guido, and I
are the last ones to do syslog-specific changes to this module in the last
15 years.
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 from
the C argv[0]. IMHO, what we really want is the Python sys.argv[0].
Because of this feature, I always have to do the following when I'm using
syslog:
openlog(os.path.basename(sys.argv[0]))
I would propose changing the Python syslog() call to do the C equivalent of:
if openlog_hasnt_been_called_before_now:
if sys.argv[0]:
syslog.openlog(os.path.basename(sys.argv[0]))
In other words, if there's a script name and openlog hasn't already been
called, call openlog with the basename of the script name.
This is effectively what happens in normal C code that calls syslog.
Note that the Python syslog.openlog says that the default for ident is
"(usually) 'syslog'".
The benefit of this change is that you get a more identifiable ident string
in Python programs, so when you look at the logs you can tell what script
it came from, not just that it came from some Python program. One way of
looking at it would be that the syslog module logging "python" as the
program name is a bug.
The downside I see is that there might be some users doing log scraping
depending on this (IMHO, buggy) log ident.
Something else just occurred to me though, a nice enhancement would be for
openlog() to have a "None" default for ident, something like:
orig_openlog = openlog
def openlog(ident = None, logopt = 0, facility = LOG_USER)
if ident == None:
if sys.argv[0]:
ident = os.path.basename(sys.argv[0])
else:
ident = 'python'
orig_openlog(ident, logopt, facility)
So you could call openlog and rely on the default ident (sys.argv[0]),
and set the logopt and facility.
The gory details of why this is occurring are: If you don't call
"openlog()" before "syslog()", the system syslog() function calls
something similar to: "openlog(basename(argv[0]))", which causes the
"ident" of the syslog messages to be "python" rather than the specific
program.
Thoughts?
Thanks,
Sean
--
"Every increased possession loads us with new weariness."
-- John Ruskin
Sean Reifschneider, Member of Technical Staff
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
> 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 is a right answer to give, surely
> > giving the right answer it is better than not?
>
> From the early days of the decimal module,
> we've thought that mixed float-decimal operations
> are 1) a bit perilous and 2) have few, if any good
> use cases.
When it comes to *arithmetic* operations, I agree. Is there anyone on
python-dev willing to argue the case for allowing implicit mixed
float/Decimal arithmetic operations? The arguments in the PEP seem
pretty convincing to me, and I'm not suggesting we change that.
But comparison operations are different. For starters, you don't need to
worry about whether to return a float or a Decimal, because you always
get a bool. In theory, both Decimals and floats are representations of
the same underlying thing, namely real numbers, and it seems strange to
me that I can't ask whether two such real numbers are equal just
because their storage implementation is different.
I can see three reasonable reasons for avoiding mixed comparisons:
(1) To avoid confusing float-naive users (but they're confused by pure
float comparisons too).
(2) To avoid mixed arithmetic operations (but comparisons aren't
arithmetic).
(3) If Decimals and floats compare equal, they must hash equal, and
currently they don't (but Mark Dickinson thinks he has a solution for
that).
> Accordingly, any mixed operations should be explicit
> rather than implicit:
>
> Decimal('1.1') + Decimal.from_float(2.2)
>
> is better than:
>
> Decimal('1.1') + 2.2
Agreed. The user should explicitly choose whether they want a float
answer or a Decimal answer.
> To help the user avoid confusion, we flag the latter with a
> TypeError: unsupported operand type(s) for +: 'Decimal' and 'float'.
>
> Unfortunately, in Py2.x, implicit mixed comparisons do not
> raise an exception, and instead will silently fail by giving
>
> an incorrect answer:
> >>> Decimal('1.1') < 2.2
> False
That is clearly the wrong thing to do.
Do you envisage any problems from allowing this instead?
>>> Decimal('1.1') < 2.2
True
> IMO, raising the exception is the right thing to do.
> Short of that though, if we're going to give a result,
> it should at least be a correct one.
+1
--
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On Mar 18, 2010, at 5:23 AM, Steven D'Aprano wrote: > On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote: >> 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 is a right answer to give, surely >>> giving the right answer it is better than not? >> >> From the early days of the decimal module, >> we've thought that mixed float-decimal operations >> are 1) a bit perilous and 2) have few, if any good >> use cases. > > When it comes to *arithmetic* operations, I agree. Is there anyone on > python-dev willing to argue the case for allowing implicit mixed > float/Decimal arithmetic operations? The arguments in the PEP seem > pretty convincing to me, and I'm not suggesting we change that. > > But comparison operations are different. For starters, you don't need to > worry about whether to return a float or a Decimal, because you always > get a bool. In theory, both Decimals and floats are representations of > the same underlying thing, namely real numbers, and it seems strange to > me that I can't ask whether two such real numbers are equal just > because their storage implementation is different. > > I can see three reasonable reasons for avoiding mixed comparisons: > > (1) To avoid confusing float-naive users (but they're confused by pure > float comparisons too). > > (2) To avoid mixed arithmetic operations (but comparisons aren't > arithmetic). > > (3) If Decimals and floats compare equal, they must hash equal, and > currently they don't (but Mark Dickinson thinks he has a solution for > that). Thanks for the thoughtful post. The question is which behavior is most useful, most of the time. If a person truly wants to do mixed comparisons, it's trivially easy to do so in a way that is explicit: somedecimal < Decimal.from_float(somefloat) My thought is that intentional mixed compares of float and decimal are very rare relative to unintentional cases. IOW, most of the time that xhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On 3/18/2010 5:23 AM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
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 is a right answer to give, surely
giving the right answer it is better than not?
From the early days of the decimal module,
we've thought that mixed float-decimal operations
are 1) a bit perilous and 2) have few, if any good
use cases.
When it comes to *arithmetic* operations, I agree. Is there anyone on
python-dev willing to argue the case for allowing implicit mixed
float/Decimal arithmetic operations? The arguments in the PEP seem
pretty convincing to me, and I'm not suggesting we change that.
But comparison operations are different. For starters, you don't need to
worry about whether to return a float or a Decimal, because you always
get a bool. In theory, both Decimals and floats are representations of
the same underlying thing, namely real numbers, and it seems strange to
me that I can't ask whether two such real numbers are equal just
because their storage implementation is different.
I can see three reasonable reasons for avoiding mixed comparisons:
(1) To avoid confusing float-naive users (but they're confused by pure
float comparisons too).
(2) To avoid mixed arithmetic operations (but comparisons aren't
arithmetic).
(3) If Decimals and floats compare equal, they must hash equal, and
currently they don't (but Mark Dickinson thinks he has a solution for
that).
Accordingly, any mixed operations should be explicit
rather than implicit:
Decimal('1.1') + Decimal.from_float(2.2)
is better than:
Decimal('1.1') + 2.2
Agreed. The user should explicitly choose whether they want a float
answer or a Decimal answer.
To help the user avoid confusion, we flag the latter with a
TypeError: unsupported operand type(s) for +: 'Decimal' and 'float'.
Unfortunately, in Py2.x, implicit mixed comparisons do not
raise an exception, and instead will silently fail by giving
an incorrect answer:
>>> Decimal('1.1')< 2.2
False
That is clearly the wrong thing to do.
Do you envisage any problems from allowing this instead?
Decimal('1.1')< 2.2
True
Yes.
As any non-naïve float user is aware, the proper form of float
comparisons is not to use < or > or == or !=, but rather, instead of
using < (to follow along with your example), one should use:
Decimal('1.1') - 2.2 < epsilon
However, while even this is only useful in certain circumstances as a
gross simplification [1], it immediately shows the need to do mixed
arithmetic to produce (sometimes) correct results. More correct
comparisons require much more code (even the 20-line C code in [1],
which understands the float format to some extent, admits to being
deficient in some circumstances).
For all the reasons that mixed decimal and float arithmetic is bad,
mixed decimal and float comparisons are also bad. To do proper
comparisons, you need to know the number of significant digits of both
numbers, and the precision and numeric ranges being dealt with by the
application.
For the single purpose of sorting, one could make an argument that not
knowing the significant digits, precision, and numeric ranges, that the
sort would probably produce results where floats and decimals that
should compare equal would be clustered similarly as they would if the
significant digits, precision, and numeric ranges were known, and that
would probably be close to truth, but only if the decimal vs float key
were the last in the composite sort key. I don't think Python informs
its comparison operations that it is being used as part of a sort, nor
would there be a way for user-written sorts to inform the comparison
operations of that fact.
Seems like it would be better to raise an exception, and in the
documentation for the exception point out that turning off the exception
(if it should be decided that that should be possible, which could be
good for compatibility), would regress to the current behavior, which
doesn't sort numerically, but by type.
[1]
http://www.cprogramming.com/tutorial/floating_point/understanding_floating_point_representation.html
Glenn
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On Thu, Mar 18, 2010 at 5:55 PM, Raymond Hettinger wrote: > My thought is that intentional mixed compares of float and decimal > are very rare relative to unintentional cases. IOW, most of the > time that x (or the user simply doesn't understand what his or her code is > actually doing). That user is best served by refusing the temptation > to guess that they really wanted to go down this path. In this case, could we consider again the idea of making these comparisons produce TypeErrors in 2.7? That's what's been requested or proposed multiple times on the tracker issue (by Imri Goldberg[1], Jeremy Dunck[2], Bert Hughes[3] and Stefan Krah[4]), and also by participants in this discussion (Greg Ewing). 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 post about lists containing ints, floats and Decimals), perhaps this is an acceptable risk. (2) A few of the posters here (Steven, Nick, and me) feel that it's slightly more natural to allow these comparisons; but I think the argument's fairly evenly balanced at the moment between those who'd prefer an exception and those who'd prefer to allow the comparisons. I'd really like to get this sorted for 2.7: as far as I'm concerned, either of the proposed behaviours (raise an exception, or allow comparisons) would be an improvement on the current 2.7 behaviour. Could everyone live with making float<->Decimal comparisons raise an exception in 2.7? Mark [1] http://bugs.python.org/issue2531#msg83691 [2] http://bugs.python.org/issue2531#msg83818 [3] http://bugs.python.org/issue2531#msg97891 [4] http://bugs.python.org/issue2531#msg98217 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
Glenn Linderman g.nevcal.com> writes: > > For all the reasons that mixed decimal and float arithmetic is bad, > mixed decimal and float comparisons are also bad. To do proper > comparisons, you need to know the number of significant digits of both > numbers, and the precision and numeric ranges being dealt with by the > application. What is a "proper comparison"? A comparison is a lossy operation by construction (it returns only 1 bit of output, or 2 bits for rich comparison), so the loss in precision that results from mixing float and decimal operands should not be a concern here. Unless there are situations where the comparison algorithm might return wrong results (are there?), I don't see why we should forbid such comparisons. > Seems like it would be better to raise an exception, and in the > documentation for the exception point out that turning off the exception > (if it should be decided that that should be possible, which could be > good for compatibility), would regress to the current behavior, which > doesn't sort numerically, but by type. Regressing to an useless behaviour sounds like a deliberate annoyance. I don't think this proposal should be implemented. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On 18/03/2010 18:44, Antoine Pitrou wrote: [snip...] Seems like it would be better to raise an exception, and in the documentation for the exception point out that turning off the exception (if it should be decided that that should be possible, which could be good for compatibility), would regress to the current behavior, which doesn't sort numerically, but by type. Regressing to an useless behaviour sounds like a deliberate annoyance. I don't think this proposal should be implemented. I agree, comparisons here have completely defined semantics - it sounds crazy not to allow it. (The argument 'because some programmers might do it without realising' doesn't hold much water with me.) Michael Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On Fri, 19 Mar 2010 05:41:08 am Mark Dickinson wrote: > I'd really like to get this sorted for 2.7: as far as I'm concerned, > either of the proposed behaviours (raise an exception, or allow > comparisons) would be an improvement on the current 2.7 behaviour. > > Could everyone live with making float<->Decimal comparisons raise an > exception in 2.7? Yes. I would far prefer an exception than the current incorrect results in 2.6. -- Steven D'Aprano ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On Fri, 19 Mar 2010 05:27:06 am Glenn Linderman wrote:
> > Do you envisage any problems from allowing this instead?
> >
> Decimal('1.1')< 2.2
> >
> > True
>
> Yes.
>
> As any non-naïve float user is aware, the proper form of float
> comparisons is not to use < or > or == or !=, but rather, instead of
> using < (to follow along with your example), one should use:
>
> Decimal('1.1') - 2.2 < epsilon
And yet we allow
1.1 < 2.2
instead of forcing users to do the "proper form". One can only wonder
why the various standards (actual and de-facto) for floating point
allows comparisons at all.
But they do, and so does Python, and frankly even if the only reason is
to satisfy lazy coders who don't have a requirement for high accuracy,
then that's a good reason in my book, and one equally applicable to
Decimal and float.
--
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On 2010-03-18 13:27 PM, Glenn Linderman wrote:
As any non-naïve float user is aware, the proper form of float
comparisons is not to use < or > or == or !=, but rather, instead of
using < (to follow along with your example), one should use:
Decimal('1.1') - 2.2 < epsilon
Not at all. This is quite incorrect for most use cases. Fuzzy comparisons are
sometimes useful for equality testing, but almost never for ordering.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On 3/18/2010 12:45 PM, Robert Kern wrote:
On 2010-03-18 13:27 PM, Glenn Linderman wrote:
As any non-naïve float user is aware, the proper form of float
comparisons is not to use < or > or == or !=, but rather, instead of
using < (to follow along with your example), one should use:
Decimal('1.1') - 2.2 < epsilon
Not at all. This is quite incorrect for most use cases. Fuzzy
comparisons are sometimes useful for equality testing, but almost
never for ordering.
I wondered if anyone would catch me on that! I did it mostly to keep
the same example going, but partly to see if there were any real
floating point experts in the discussion! You'll have noted my
reference was to using the technique for equality.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is Scala better than Python ???
To All, I have done some more review of python and Scala and I am very impressed with both languages. However, it seems as though that Scala is far more able to support parallel processing than Python ?? Is this true ?? O.R. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is Scala better than Python ???
Hello. We'are sorry but we cannot help you. This mailing list is for working on developing Python (fixing bugs and adding new features to Python itself); if you're having problems using Python, please find another forum. Probably python-list (comp.lang.python) news group/mailing list is the best place. See http://www.python.org/community/lists/ for other lists/news groups/forums. Thank you for understanding. On Thu, Mar 18, 2010 at 01:54:20PM -0700, OMEGA RED wrote: > To All, > > I have done some more review of python and Scala and I am very impressed with > both languages. However, it seems as though that Scala is far more able to > support parallel processing than Python ?? Is this true ?? > > O.R. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Joel Spolsky on Mercurial
In what might be his last Joel on Software post (for awhile, at least) http://www.joelonsoftware.com/items/2010/03/17.html Summary: Early 2009: Joel disses DVCSes. His programmers switch from subversion to hg. Joel grumbles. His programmers develop an hg-related product. Joel takes a better look. Joel sees the light: Subversion controls versions, hg controls changes; this make merging much easier. Joel flips (his opinion): Switch now! Joel write hg tutorial: http://hginit.com/ It starts with "Subversion Re-education" for existing version-oriented system users and continue with "Ground up Mercurial" where new vcs users can start. It has several simple examples. Having gotten that far, I think this might be worth referencing in new dev docs. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
Mark Dickinson wrote:
> Could everyone live with making float<->Decimal comparisons raise an
> exception in 2.7?
I could, with the caveat that *if* this causes problems for real world
code, then changing it to produce the correct answer (as per your patch)
should be applied as a bug fix in both 2.7 and 3.2.
Note that even in Py3k there are some fairly serious weirdnesses kicking
around due to the intransitive nature of numeric equality though:
>>> from decimal import Decimal as dec
>>> set((1, 1.0, dec("1.0")))
{1}
>>> set((1.0, dec("1.0")))
{1.0, Decimal('1.0')}
>>> d = {}
>>> from decimal import Decimal as dec
>>> d[1] = d[1.0] = d[dec("1.0")] = 42
>>> d
{1: 42}
>>> d[1.0] = d[dec("1.0")] = 42
>>> d
{1: 42}
>>> del d[1]
>>> d[1.0] = d[dec("1.0")] = 42
>>> d
{1.0: 42, Decimal('1.0'): 42}
When there is a clear, correct way (based on Decimal.from_float) to make
numeric comparison behave in accordance with the rules of mathematics,
do we really want to preserve strange, unintuitive behaviour like the above?
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On 3/18/2010 12:34 PM, Steven D'Aprano wrote:
On Fri, 19 Mar 2010 05:27:06 am Glenn Linderman wrote:
Do you envisage any problems from allowing this instead?
Decimal('1.1')< 2.2
True
Yes.
As any non-naïve float user is aware, the proper form of float
comparisons is not to use< or> or == or !=, but rather, instead of
using< (to follow along with your example), one should use:
Decimal('1.1') - 2.2< epsilon
And yet we allow
1.1< 2.2
instead of forcing users to do the "proper form". One can only wonder
why the various standards (actual and de-facto) for floating point
allows comparisons at all.
Hard to tell
1.1 < 2.2
from the second line of
diff = 1.1 - 2.2
diff < epsilon
Hard to enforce the "proper form", without being omniscient, and the
"proper form" isn't always as simple as my example, to be truly proper
often requires a lot more code (and a lot more omniscience).
I'm +1 on adding an exception for Decimal/float comparisons, -0 on
allowing it to be turned off to achieve compatible behavior, since
Raymond pointed out that the compatible sorting behavior isn't stable in
the presence of int, Decimal, and float.
But they do, and so does Python, and frankly even if the only reason is
to satisfy lazy coders who don't have a requirement for high accuracy,
then that's a good reason in my book, and one equally applicable to
Decimal and float.
A point well understood, but I personally would rather force
Decimal/float comparisons to be explicitly converted to be lazily
compared, if the arithmetic operations are forced to be explicit.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On 3/18/2010 2:48 PM, Nick Coghlan wrote: When there is a clear, correct way (based on Decimal.from_float) to make numeric comparison behave in accordance with the rules of mathematics, do we really want to preserve strange, unintuitive behaviour like the above? Cheers, Nick. I'm aware of nothing that prevents the lazy coder from having a class unifiedNumber in his toolbox that implements his favorite type of conversions from various numeric types to whatever he thinks is the "best" one for his application, and then using it places where sources might be of various other numeric types. I'm aware of nothing that would prevent the lazy coder from implement comparison operators and even arithmetic operators on such a class. I believe, but haven't proven, and haven't used Python long enough to "just know", that such class could even implement what would appear to be operators that would seem to provide implicit conversion from the various other numeric classes, as long as one item was of the class. So I think it would be possible, with such a class, to have one's cake (nothing implicit), and eat it too (providing a way do comparisons and numerical operations, mostly implicitly). Glenn ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On 3/18/2010 5:48 PM, Nick Coghlan wrote:
Mark Dickinson wrote:
Could everyone live with making float<->Decimal comparisons raise an
exception in 2.7?
I could, with the caveat that *if* this causes problems for real world
code, then changing it to produce the correct answer (as per your patch)
should be applied as a bug fix in both 2.7 and 3.2.
Note that even in Py3k there are some fairly serious weirdnesses kicking
around due to the intransitive nature of numeric equality though:
from decimal import Decimal as dec
set((1, 1.0, dec("1.0")))
{1}
set((1.0, dec("1.0")))
{1.0, Decimal('1.0')}
d = {}
from decimal import Decimal as dec
d[1] = d[1.0] = d[dec("1.0")] = 42
d
{1: 42}
d[1.0] = d[dec("1.0")] = 42
d
{1: 42}
del d[1]
d[1.0] = d[dec("1.0")] = 42
d
{1.0: 42, Decimal('1.0'): 42}
When there is a clear, correct way (based on Decimal.from_float) to make
numeric comparison behave in accordance with the rules of mathematics,
do we really want to preserve strange, unintuitive behaviour like the above?
I would still strongly prefer that equality intransitivity be fixed one
way or another (I suggested two on the tracker). The many ways it makes
sets misbehave was discussed in both of
http://mail.python.org/pipermail/python-list/2008-September/508859.html
http://bugs.python.org/issue4087
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
Glenn Linderman g.nevcal.com> writes: > > On 3/18/2010 2:48 PM, Nick Coghlan wrote: > > When there is a clear, correct way (based on Decimal.from_float) to make > > numeric comparison behave in accordance with the rules of mathematics, > > do we really want to preserve strange, unintuitive behaviour like the above? > > I'm aware of nothing that prevents the lazy coder from having a class > unifiedNumber in his toolbox [snip] Please stick to the topic. We are talking about Python's default behaviour here. Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal <-> float comparisons in py3k.
On 3/18/2010 6:18 PM, Antoine Pitrou wrote: Glenn Linderman g.nevcal.com> writes: On 3/18/2010 2:48 PM, Nick Coghlan wrote: When there is a clear, correct way (based on Decimal.from_float) to make numeric comparison behave in accordance with the rules of mathematics, do we really want to preserve strange, unintuitive behaviour like the above? I'm aware of nothing that prevents the lazy coder from having a class unifiedNumber in his toolbox [snip] Please stick to the topic. We are talking about Python's default behaviour here. Yes, I consider my comment relevant, and think that you should apologize for claiming it is off topic. There are two choices on the table -- doing comparisons implicitly between Decimal and float, and raising an exception. It seems the current behavior, sorting by type, is universally disliked, but doing nothing is a third choice. So if the default behavior is to raise an exception, my comment pointed out the way comparisons could be provided, for those that need them. This allows both behaviors to exist concurrently. Python developers could even consider including such a library in the standard library, although my suggestion didn't include that. 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. Glenn ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GSoC 2010 is on -- projects?
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. Please submit ideas for projects as soon as possible, as students will be able to start applying soon. You can add them to this page: http://wiki.python.org/moin/SummerOfCode/2010 You can subscribe to the mentors list here, http://mail.python.org/mailman/listinfo/soc2010-mentors and the general discussion list (students included) here: http://mail.python.org/mailman/listinfo/soc2010-general thanks, --titus -- C. Titus Brown, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC 2010 is on -- projects?
2010/3/18 C. Titus Brown : > 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. This is not completely to the exclusion of other, projects, though, correct? For example, I think building a 64 bit PyPy backend would be a very worthy task. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC 2010 is on -- projects?
On Thu, Mar 18, 2010 at 10:13:42PM -0500, Benjamin Peterson wrote: > 2010/3/18 C. Titus Brown : > > 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. > > This is not completely to the exclusion of other, projects, though, > correct? For example, I think building a 64 bit PyPy backend would be > a very worthy task. Right -- emphasize only ;). Good projects + good students + good mentors are always welcome (and, actually, we'd like to focus on good students -- better that something get done than that something particularly relevant get chosen but NOT done by a poor student). thanks, --titus -- C. Titus Brown, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.1.2 tagging delayed a little
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. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC 2010 is on -- projects?
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 python project could potentially see itself ported to Python 3 in the course of this SoC ? If so, can any project owner submit a request for help, or is there going to be a list of projects that would nice to port, or will a voting system of some sort be put in place ? Best, Laurent ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC 2010 is on -- projects?
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 tackled. Hi, Does this mean that any other python project could potentially see itself ported to Python 3 in the course of this SoC ? The theme should include both general porting tools and specific projects, especially infrastructure projects like numeric, which are blocking the porting of other projects. It would be nice if those doing specific projects contributed their experience/knowledge to a central pool. If so, can any project owner submit a request for help, Any project owner is *always* free to ask for help (on python-list, but now here in this thread). Those who can also mentor might be more likely to get it. If I were a student, I would consider serious interest from a project owner (and a promise to distribute a port, when ready), a prerequisite. > or is there going to be a list of projects that would nice to port, or will a voting system of some sort be put in place ? Like most contributors, students choose projects, within the limits of what they can get mentors for, that scratch their itches. They may or may not otherwise be swayed by requests and opinions. My views. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
