Re: [Python-Dev] Contributing to Python

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 i

Re: [Python-Dev] Repeatability of looping over dicts

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 t

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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 >cho

Re: [Python-Dev] Repeatability of looping over dicts

>> 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:

Re: [Python-Dev] Repeatability of looping over dicts

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 http://www.google.com/cod

Re: [Python-Dev] Extracting variables from string.Template objects

On Fri, 4 Jan 2008, Aahz wrote: >> Also, on a related issue, does it make sense to scan the template >> string for invalid escape sequences in Template.__init__? For the >> applications I can imagine of string.Template, I would prefer to get >> an error upon creating the Template object rather th

Re: [Python-Dev] Repeatability of looping over dicts

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

Re: [Python-Dev] Contributing to Python

> 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

Re: [Python-Dev] Repeatability of looping over dicts

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 J

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

[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

Re: [Python-Dev] function call syntax oddity

[Paul Moore] > 1 .__str__() > This one is a number "1" followed by > the operator "." followed by "__str__". FWIW, I would avoid the odd spacing and write this as: (1).__str__() Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] function call syntax oddity

On 04/01/2008, Joseph Armbruster <[EMAIL PROTECTED]> wrote: > Cool I suppose, except here's an odd man out: > > >>> 1.__str__() >File "", line 1 > 1.__str__() > ^ > SyntaxError: invalid syntax It's parsed a floating point number - "1." - followed by the keyword "__str__". Th

[Python-Dev] function call syntax oddity

All, I was showing a co-worker some python today (using the trunk) when I stumbled upon this. I was not sure what to think since I have never really experimented with using spaces like this. So here tis. Be careful to notice the spaces as they are significant here. >>> 1.3.__str__() '1.3' >>>

Re: [Python-Dev] Repeatability of looping over dicts

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 footno

Re: [Python-Dev] Repeatability of looping over dicts

On Jan 4, 2008, at 3:05 PM, Tim Delaney wrote: > As I just posted to the blog, yes. Look at section 3.8 of the > reference > manual > (Mapping Types), specifically footnote 3: You type faster than I do. :-) This guarantee has been in place for about a decade, as I recall. -Fred -- Fred

Re: [Python-Dev] Repeatability of looping over dicts

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: http://docs.python.org/lib/typesmapping.ht

Re: [Python-Dev] Repeatability of looping over dicts

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: http://docs.python.org/lib/typesmapping.ht

[Python-Dev] Repeatability of looping over dicts

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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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

Re: [Python-Dev] [Python-3000] Need closure on __cmp__ removal

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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

[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

[Python-Dev] Need closure on __cmp__ removal

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 mon

Re: [Python-Dev] Bug day tasks

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 hoo

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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 calcula

Re: [Python-Dev] Bug day tasks

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

[Python-Dev] Summary of Tracker Issues

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 durati

Re: [Python-Dev] long(float('nan')) conversion

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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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.

Re: [Python-Dev] long(float('nan')) conversion

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 200

Re: [Python-Dev] Backport threading.py fix to 2.5.2?

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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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 compatibilit

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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.

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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

Re: [Python-Dev] Bug day tasks

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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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 pe

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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,

Re: [Python-Dev] Bug day tasks

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 >

Re: [Python-Dev] Extracting variables from string.Template objects

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

Re: [Python-Dev] Bug day tasks

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 (!)). > http://wiki.python.org/moin/Python

[Python-Dev] Bug day tasks

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 task

[Python-Dev] Check for signals during regular expression matches (issue846388)

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 is

[Python-Dev] siginterrupt on linux (issue1089358)

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 m

Re: [Python-Dev] long(float('nan')) conversion

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 http://bugs.pytho

Re: [Python-Dev] long(float('nan')) conversion

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) > [GC

[Python-Dev] Extracting variables from string.Template objects

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 (templat

[Python-Dev] Bug day proposal: January 19th

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 Py

[Python-Dev] long(float('nan')) conversion

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", "co

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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 see

Re: [Python-Dev] Contributing to Python

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)

Re: [Python-Dev] Syntax suggestion for imports

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 > propos

Re: [Python-Dev] Syntax suggestion for imports

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 ha

Re: [Python-Dev] Syntax suggestion for imports

[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 fun

Re: [Python-Dev] Contributing to Python

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 > -> answe

Re: [Python-Dev] Return type of round, floor, and ceil in 2.6

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, >