On Jan 3, 2008 10:37 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on
rev 5967 [2], so this is the time to understand if we want this or
not.
This is a problem. Right now, in the trunk, math.float(1) returns 1,
where it
On Jan 3, 2008 5:24 PM, Titus Brown [EMAIL PROTECTED] wrote:
On Thu, Jan 03, 2008 at 03:24:16PM -0500, Joseph Armbruster wrote:
- Having a core mentor would be great but do they really have time for
- that? I've been lucky at finding people in #python / #python-dev) that can
- answer
[Half tongue-in-cheek]
-On [20080104 08:04], Drew Perttula ([EMAIL PROTECTED]) wrote:
When I saw the OP, I actually wondered why people whose codebases are
filled with the same try/except block over and over hadn't just
written their own import_with_alternative function in the first place
Jeroen Ruigrok van der Werven wrote:
[Half tongue-in-cheek]
-On [20080104 08:04], Drew Perttula ([EMAIL PROTECTED]) wrote:
When I saw the OP, I actually wondered why people whose codebases are
filled with the same try/except block over and over hadn't just
written their own
Raymond Hettinger wrote:
[Jeroen Ruigrok van der Werven]
On the Trac project using your grep gives me 203 lines, if we take ~2
lines for and after in consideration, it still means 203/5 ~= 40
occurences.
Thanks. I'm more curious about the content of those lines. Does the
proposed syntax
I found myself wanting to obtain the variables from a string.Template
object. The situation is that part of input consists of a filename
template, and I want to make sure that all the parameter values I have are
actually represented in the filename template. So:
def templateVariables
2008/1/4, Jeffrey Yasskin [EMAIL PROTECTED]:
I haven't seen any answers to the original question. It looks like
Decimal is decided by 2.5 too: return a float from everything.
Rational, being a completely new type, is up to you guys, but because
new support for the conversion routines seems to
Hello!
Bug http://bugs.python.org/issue1481296 describes a problem where
long(float('nan')) causes a seg fault on Mac OS X. On other platforms it
returns 0L, e.g.
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type help,
2008/1/3, Titus Brown [EMAIL PROTECTED]:
The question is, is reviewing patches a good place to contribute? Also,
if I (and others) could have a core mentor with commit access, that
might streamline things. As it is, I am worried that patch reviews will
For a core_mentor/padawan (wink)
On Jan 4, 2008 8:07 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Hello!
Bug http://bugs.python.org/issue1481296 describes a problem where
long(float('nan')) causes a seg fault on Mac OS X. On other platforms it
returns 0L, e.g.
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3
Yes, I realize now that I was on the wrong box running the wrong
version, so ignore me if I'm stupid and its irrelevant!
On Jan 4, 2008 9:02 AM, Calvin Spealman [EMAIL PROTECTED] wrote:
On Jan 4, 2008 8:07 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Hello!
Bug
A while ago Georg suggested holding a bug day some time soon. I
suggest Saturday January 19th. It's a weekend day; it gives us two
weeks to prepare by drawing up bug lists; there's a PyPy sprint
January 12-19 (http://codespeak.net/pypy/dist/pypy/doc/news.html), so
it may be helpful to have the
Hi all,
I've added a patch implementing a wrapper for siginterrupt on linux/unix
like platforms and attached it to
http://bugs.python.org/issue1089358 (which mentions a need for
siginterrupt).
Any chance to get this in?
Regards,
- Ralf
___
Python-Dev
I've updated the bug day pages in the wiki:
http://wiki.python.org/moin/PythonBugDay
http://wiki.python.org/moin/PythonBugDayStatus
How do we want to flag good candidate bugs? Should we add a keyword
to Roundup, or just list them on the PythonBugDayStatus wiki page?
Another
Hi all,
Currently the re module does not handle signals. I've been once a victim of
such a case in a real world setup (i.e. the python interpreter seems to hang
at 100% CPU and is not interuptible with control c)
http://bugs.python.org/issue846388 opened 4 years ago contained a patch for
this
2008/1/4, A.M. Kuchling [EMAIL PROTECTED]:
I've updated the bug day pages in the wiki:
This one should be also updated:
http://wiki.python.org/moin/MissingFromDocumentation
All the issues pointed by it are already closed (or don't exist (!)).
On Jan 4, 2008 12:13 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 3, 2008 10:37 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Well, as issue 1689 states, the backporting was commited by Jeffrey on
rev 5967 [2], so this is the time to understand if we want this or
not.
This is
On Jan 4, 2008 11:14 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 4, 2008 4:40 AM, Facundo Batista [EMAIL PROTECTED] wrote:
Do you mean that the response in the following case is of type float?:
round(decimal.Decimal(2.5))
3.0
Yes.
That seems a little peculiar to me: wouldn't
2008/1/4, Mark Dickinson [EMAIL PROTECTED]:
That seems a little peculiar to me: wouldn't it be more natural to have
round(Decimal_instance) return another Decimal?
Yes.
Now I find that now round() delegates its work to __round__:
http://docs.python.org/dev/library/functions.html#round
On Fri, Jan 04, 2008, Isaac Morland wrote:
I would like to add this as a method of string.Template, which I think
amounts to changing template to self and putting it in the Template
class in string.py rather than on its own. If the general idea is
approved I would be happy to make a
A.M. Kuchling wrote:
Another task is to get logging set up for the #python-dev IRC channel.
Searching didn't find any existing archive; we could run it on
python.org somewhere, but does anyone here already run an IRC logging
bot? Maybe someone could just add #python-dev to their existing
On Jan 4, 2008 4:40 AM, Facundo Batista [EMAIL PROTECTED] wrote:
2008/1/4, Jeffrey Yasskin [EMAIL PROTECTED]:
I haven't seen any answers to the original question. It looks like
Decimal is decided by 2.5 too: return a float from everything.
Rational, being a completely new type, is up to
On Fri, 04 Jan 2008 16:53:46 +0100, Christian Heimes [EMAIL PROTECTED] wrote:
A.M. Kuchling wrote:
Another task is to get logging set up for the #python-dev IRC channel.
Searching didn't find any existing archive; we could run it on
python.org somewhere, but does anyone here already run an IRC
Guido Looks like in Python 2.6, round(0.5) right now returns 0.0,
Guido whereas in 2.5, it returns 1.0.
Guido I think it should return 1.0, for best compatibility with Python
Guido 2.5.
And for best compatibility with everything else! 0.5 wink
Skip
OK, I'll backport it.
On Jan 4, 2008 4:49 AM, Thomas Wouters [EMAIL PROTECTED] wrote:
On Jan 4, 2008 2:46 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
See http://bugs.python.org/issue1731. Should we consider it safe to
backport r57216 to 2.5.2? This is Thomas Wouters's code to disable
On Jan 4, 2008 8:58 AM, [EMAIL PROTECTED] wrote:
Guido Looks like in Python 2.6, round(0.5) right now returns 0.0,
Guido whereas in 2.5, it returns 1.0.
Guido I think it should return 1.0, for best compatibility with Python
Guido 2.5.
And for best compatibility with
On Jan 4, 2008 5:07 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Bug http://bugs.python.org/issue1481296 describes a problem where
long(float('nan')) causes a seg fault on Mac OS X. On other platforms it
returns 0L, e.g.
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3 20070929
Guido Rounding 0.5 to 0 is a new fad, called round-to-even, or
Guido statistician's rounding. Read
Guido http://en.wikipedia.org/wiki/Rounding . It's a standard, and
Guido more correct when doing statistical calculations. That's why
Guido we've chosen it for Python 3.0. But
On Jan 4, 2008 8:37 AM, Facundo Batista [EMAIL PROTECTED] wrote:
2008/1/4, Mark Dickinson [EMAIL PROTECTED]:
That seems a little peculiar to me: wouldn't it be more natural to have
round(Decimal_instance) return another Decimal?
Yes.
Now I find that now round() delegates its work to
ACTIVITY SUMMARY (12/28/07 - 01/04/08)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1371 open (+15) / 11849 closed (+16) / 13220 total (+31)
Open issues with patches: 430
Average
On Jan 4, 2008 9:19 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
We should make sure inf and nan are treated correctly by the new
round(), floor() and ceil() in 3.0 -- it looks like right now
round(nan) returns 0, but it should raise ValueError. (Also, Jeffrey,
I thought math.floor() was to
On Fri, Jan 04, 2008 at 04:53:46PM +0100, Christian Heimes wrote:
It'd be nice if we can also get a bot into #python-dev to broadcast svn
commits and bug tracker changes. The Twisted guys have good bot with
decent msg coloring but IIRC it's tight into TRAC. For svn we could
probably use CIA
In the past some folks have been pushing for the resurrection of (some
form of) __cmp__, which is currently removed from Py3k (except for
some remnants which we'll clean up in due time).
I'd like to get closure on this issue. If someone volunteers within a
week to write a PEP, I'll give them a
Christian Heimes wrote:
It'd be nice if we can also get a bot into #python-dev to broadcast svn
commits and bug tracker changes. The Twisted guys have good bot with
decent msg coloring but IIRC it's tight into TRAC. For svn we could
probably use CIA bot and tie it into a svn post commit hook.
On Jan 4, 2008 12:18 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
In the past some folks have been pushing for the resurrection of (some
form of) __cmp__, which is currently removed from Py3k (except for
some remnants which we'll clean up in due time).
I'd like to get closure on this issue.
[EMAIL PROTECTED]
Thanks for the pointer. Given that it's [round-to-even[ been an ASTM
standard since 1940 and apparently in fairly common use since the
early 1900s, I wonder why it's not been more widely used in the past
in programming languages.
Because add a half and chop was also in wide
On Jan 4, 2008 9:25 AM, [EMAIL PROTECTED] wrote:
Guido Rounding 0.5 to 0 is a new fad, called round-to-even, or
Guido statistician's rounding. Read
Guido http://en.wikipedia.org/wiki/Rounding . It's a standard, and
Guido more correct when doing statistical calculations.
On Jan 4, 2008 11:31 AM, Tim Peters [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]
Thanks for the pointer. Given that it's [round-to-even[ been an ASTM
standard since 1940 and apparently in fairly common use since the
early 1900s, I wonder why it's not been more widely used in the past
in
This post describes work aimed at getting Django to run on Jython:
http://zyasoft.com/pythoneering/2008/01/django-on-jython-minding-gap.html
One outstanding issue is whether to use Java's ConcurrentHashMap type
to underly Jython's dict type. See
A.M. Kuchling wrote:
So, do Python implementations need to guarantee that list(dict_var) ==
a later result from list(dict_var)?
As I just posted to the blog, yes. Look at section 3.8 of the reference
manual
(Mapping Types), specifically footnote 3:
On Sat, Jan 05, 2008 at 07:05:55AM +1100, Tim Delaney wrote:
So, do Python implementations need to guarantee that list(dict_var) ==
a later result from list(dict_var)?
As I just posted to the blog, yes. Look at section 3.8 of the reference
manual
(Mapping Types), specifically footnote 3:
A.M. Kuchling wrote:
So, do Python implementations need to guarantee that list(dict_var) ==
a later result from list(dict_var)?
As I just posted to the blog, yes. Look at section 3.8 of the reference
manual
(Mapping Types), specifically footnote 3:
On 04/01/2008, Joseph Armbruster [EMAIL PROTECTED] wrote:
Cool I suppose, except here's an odd man out:
1.__str__()
File stdin, line 1
1.__str__()
^
SyntaxError: invalid syntax
It's parsed a floating point number - 1. - followed by the keyword
__str__. That's not
[GvR to Tim]
Do you have an opinion as to whether we should
adopt round-to-even at all (as a default)?
For the sake of other implementations (Jython, etc) and for ease of reproducing
the results with other tools (Excel, etc), the simplest choice is int(x+0.5).
That works everywhere, it is
Now thinking of how to produce this relationships, I think that I will
change my approach to the issues. I'll start to be more aggressive
when reviewing a patch or bug. Aggressive in the sense of
asking/commenting/proposing even if I don't get the full grasp of the
issue. This could lead to a
On Jan 4, 2008, at 5:54 PM, Guido van Rossum wrote:
What code would break if we loosened this restriction? I guess
defining d.items() as zip(d.keys(), d.values()) would no longer fly,
but does anyone actually depend on this?
I don't know what code would break today; this was initially added to
On Jan 4, 2008 11:50 AM, A.M. Kuchling [EMAIL PROTECTED] wrote:
This post describes work aimed at getting Django to run on Jython:
http://zyasoft.com/pythoneering/2008/01/django-on-jython-minding-gap.html
One outstanding issue is whether to use Java's ConcurrentHashMap type
to underly
ConcurrentHashMap scales better in the face of threading
.. .
So, do Python implementations need to guarantee that list(dict_var) ==
a later result from list(dict_var)?
What code would break if we loosened this restriction?
I can imagine someone has code like this:
for k in d:
On Fri, Jan 04, 2008 at 02:54:49PM -0800, Guido van Rossum wrote:
What code would break if we loosened this restriction? I guess
defining d.items() as zip(d.keys(), d.values()) would no longer fly,
but does anyone actually depend on this? Just like we changed how we
On 4 Jan, 10:45 pm, [EMAIL PROTECTED] wrote:
[GvR to Tim]
Do you have an opinion as to whether we should
adopt round-to-even at all (as a default)?
For the sake of other implementations (Jython, etc) and for ease of
reproducing the results with other tools (Excel, etc), the simplest
choice is
On 1/4/08, A.M. Kuchling [EMAIL PROTECTED] wrote:
This post describes work aimed at getting Django to run on Jython:
http://zyasoft.com/pythoneering/2008/01/django-on-jython-minding-gap.html
One outstanding issue is whether to use Java's ConcurrentHashMap type
to underly Jython's dict type.
On 3-Jan-08, at 1:07 PM, Guido van Rossum wrote:
On Jan 3, 2008 11:49 AM, Fred Drake [EMAIL PROTECTED] wrote:
Python 2.6 seems to be entirely targeted at people who really want to
be on Python 3, but have code that will need to be ported. I
certainly don't view it as interesting in it's own
52 matches
Mail list logo
