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

[Jeffrey Yasskin]

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 should return 1.0 for compatibility with 2.5. Jeffrey, can
> you fix this and similar incompatibilities you introduced?

Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if
you find any other problems. ... Hmm. I've also changed the behavior
of round(2.5). I'll change that back tomorrow morning.

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 be rare, it's
probably best to have it return floats too.

-- 
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Contributing to Python

[Brett Cannon]

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 development inquiries (or at least verify something is or is not a
> -> bug).
>
> Again, IMO as someone on the lunatic fringe of core development (i.e.
> I'm a happy spectator, but I'm too busy to actually get much done):
>
> Mentoring coders may not be a traditional route for hard-core OSS
> developers, but it sure can be effective, as I've found with GHOP.
>
> For example, many core Python developers can save an outsider hours of
> effort by simply and quickly outlining the issues involved in a
> particular patch or coding effort.  Having actual committers involved is
> especially good, because they can evaluate whether or not a patch is
> likely to be accepted, potentially cutting out more hours of effort; and
> they can directly commit patches, leading to the very important
> gratification of an actual commit.
>

I know I am happy to do stuff that way when I have time.  I know I am
just currently drowning under work for the first half of 2008 (PyCon,
my own Py3K stuff, and thesis).

> >From another angle, there are a lot of "easy" fixes/patches/updates to
> be done to Python, but I'll be damned if I can figure out which ones are
> easy meat, or complex, or likely to touch a nerve.  Having someone
> experienced to quickly give an opinion is invaluable.  (I'm an
> overconfident loudmouth, so I don't mind posting to this list, but I
> think python-dev is pretty intimidating for people new to the hurly
> burly of OSS development.)
>

I hope that when it comes time to change the issue tracker schema we
can have a reasonable difficulty rating.  That should also help for
Python bug days since we can say "look at easy bugs if you don't
really know C stuff, look at medium if you know C, and tackle hard if
you want to dive into the nitty-gritty".

> As I've said in other responses in this thread, I'm not sure how to make
> it happen, but I'm leaning towards asking the active GHOP mentors to try
> to extend the GHOP mentoring effort into a general python-love effort.
> We've got a good group of experienced people, and it's been a pretty
> friendly list IMO.

Could work.  Don't know if another list is really needed; couldn't
python-dev handle general questions?  But then again, that is what the
tracker is for.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Syntax suggestion for imports

[Jeroen Ruigrok van der Werven]

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

Because you would have to import it as well in order to use it? ;)

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Taxation without representation is tyranny...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Syntax suggestion for imports

[Scott Dial]

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 import_with_alternative function in the first place. 
> 
> Because you would have to import it as well in order to use it? ;)
> 

The keyphrase was "people whose codebases are 'filled' with ..." If they 
are maintaining a codebase, then I am sure adding one utility function 
to their library would be trivial. Or if you have enough of them in one 
file.. dedicating 7 lines of code for:

def import_any(*names):
 for name in names:
 try:
 return __import__(name)
 except StandardError:
 pass
 raise ImportError('no importable names')

, seems like a bargain for readability. Or to include the "None" case 
that people have brought up, we can spare 2 more lines:

def import_any(*names, **kwargs):
 required = kwargs.get('required', True)
 for name in names:
 try:
 return __import__(name)
 except StandardError:
 pass
 if required:
 raise ImportError('no importable names')

If nothing else, writing this email will remind me to avoid this 
try/except pattern in future codebases, if I have more than 1 instance 
of it (right about the break even point).

-Scott

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Syntax suggestion for imports

[Toby Dickenson]

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 help, does the need go away in Py3.0, what is the typical
> pattern?

I dont think I would use this based on a survey of 16 cases over 35k lines
here.

The proposed syntax could be easily used 11 times. 10 of those are the 'or
None' variant and account for platform-specific modules. 2 of those
currently issue a warning about the missing module in the exception branch,
but I guess I could live without that. 

Two other cases uses a different fallback value other than None; one a
string literal, and the other 'object'.

The remaining three cases do not really fit the proposed syntax. They are
currently in the form:
try:
import xxx
except ImportError:
recovery actions
else:
do something with xxx




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Isaac Morland]

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 (template):
 """Extract the variable names from a string.Template.

 Returns a tuple of all variable names found in the template, in the order
 in which they occur.  If an invalid escape sequence occurs, the same
 error will be raised as if an attempt was made to expand the template.
 """
 result = []
 for match in template.pattern.finditer (template.template):
 if match.group ('invalid') is not None:
 # Raises ValueError
 template._invalid (match)
 if match.group ('escaped') is not None:
 continue
 # The "or None" should be moot.  It is there to ensure equivalent
 # treatment for an empty 'named' and an empty 'braced'.
 result.append (match.group ('named') or match.group ('braced') or None)
 return tuple (result)

Note that almost all the work is actually done by calling in to parts of 
the template object, so I think this should work properly with subclasses 
and other less common cases.

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 patch.

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 than arbitrarily later when I try to 
.substitute with it.

Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Facundo Batista]

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 be rare, it's
> probably best to have it return floats too.

Sorry, I didn't understand this parragraph.

Do you mean that the response in the following case is of type "float"?:

>>> round(decimal.Decimal("2.5"))
3.0

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Christian Heimes]

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", "copyright", "credits" or "license" for more information.
>>> float('nan')
nan
>>> long(float('nan'))
0L

My patch to Python 2.6 adds an explicit check for NaNs to always return
0L. It did feel a bit strange but it's the default on some platforms.
Today an user pointed out that he doesn't like the patch, too.

How should the problem be solved? In my humble opinion
long(float('nan')) should return 0L in Python 2.5.2 for b/w
compatibility and raise a ValueError or OverflowError in Python 2.6+.

Christian

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Contributing to Python

[Facundo Batista]

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) relationship to work ok, you need
that both parties get interested on working on the same stuff.

For example, Mark has been working a lot on Decimal, and I have been a
merely supervisor and committer of his changes, and we could generate
successfully a good patch flow.

I don't think that this can be successful when both parties tries to
handle wide portions of Python, but I'd love to see a lot of this
small sparks of productivity.

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 better interaction on the mid/long term,
even if in the short it appears to increase the noise a little.

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Calvin Spealman]

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 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> float('nan')
> nan
> >>> long(float('nan'))
> 0L

I get even more fun results!

Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> l = long(float('nan'))
0L
>>> int(l)
0
>>> long(int(l))
0L

> My patch to Python 2.6 adds an explicit check for NaNs to always return
> 0L. It did feel a bit strange but it's the default on some platforms.
> Today an user pointed out that he doesn't like the patch, too.
>
> How should the problem be solved? In my humble opinion
> long(float('nan')) should return 0L in Python 2.5.2 for b/w
> compatibility and raise a ValueError or OverflowError in Python 2.6+.
>
> Christian
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com
>



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Calvin Spealman]

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.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", "copyright", "credits" or "license" for more information.
> > >>> float('nan')
> > nan
> > >>> long(float('nan'))
> > 0L
>
> I get even more fun results!
>
> Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
> [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> l = long(float('nan'))
> 0L
> >>> int(l)
> 0
> >>> long(int(l))
>
> 0L
>
> > My patch to Python 2.6 adds an explicit check for NaNs to always return
> > 0L. It did feel a bit strange but it's the default on some platforms.
> > Today an user pointed out that he doesn't like the patch, too.
> >
> > How should the problem be solved? In my humble opinion
> > long(float('nan')) should return 0L in Python 2.5.2 for b/w
> > compatibility and raise a ValueError or OverflowError in Python 2.6+.
> >
> > Christian
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: 
> > http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com
> >
>
>
>
> --
> Read my blog! I depend on your acceptance of my opinion! I am interesting!
> http://ironfroggy-code.blogspot.com/
>



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[A.M. Kuchling]

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 PyPy participants and the python-dev
participants available via IM/IRC all at one time.

January 12th or 13th would be an alternative date: less time to
prepare, but still overlapping with PyPy (they'll be starting instead
of winding down).

Does anyone feel strongly about the dates, or have other reasons to
choose one date or the other?  If not, I'll go with the 19th and
update the wiki page and send some announcements.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] siginterrupt on linux (issue1089358)

[Ralf Schmitt]

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 mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Bug day tasks

[A.M. Kuchling]

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 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
setup.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ralf Schmitt]

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 issue (which ofcourse didn't apply).
I've updated that patch and added an example regular expression, which
'hangs' the python interpreter.
I think this issue should be handled.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug day tasks

[Facundo Batista]

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/PythonBugDay

The URL...

  http://moin.pocoo.org/Python25a

..., from the Question section, appears to be dead.


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

As this bug days are spurious, I think that just list them in the wiki
page is ok.

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 a problem. Right now, in the trunk, math.float(1) returns 1,
> > where it should return 1.0 for compatibility with 2.5. Jeffrey, can
> > you fix this and similar incompatibilities you introduced?
>
> Whoops! I've committed r59707 to fix math.{floor,ceil}. Let me know if
> you find any other problems. ... Hmm. I've also changed the behavior
> of round(2.5). I'll change that back tomorrow morning.

Looks like in Python 2.6, round(0.5) right now returns 0.0, whereas in
2.5, it returns 1.0.

I think it should return 1.0, for best compatibility with Python 2.5.

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

Right.

> Rational, being a completely new type, is up to you guys, but because
> new support for the conversion routines seems to be rare, it's
> probably best to have it return floats too.

I think the pre-3.0 rule should be: round(), math.floor(), math.ceil()
*always* return a float.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mark Dickinson]

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 it be more natural to have
round(Decimal_instance) return another Decimal?

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Facundo Batista]

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

This doc says that round() "Return the floating point value x rounded
to n digits after the decimal point.".

It don't specify if its binary or decimal floating point, ;)

Feel free to create an issue and assign to me if you think that this
should be done.

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Aahz]

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 patch.

Make a patch regardless of whether you get any approval -- someone may
later have a different opinion, and writing a patch records your work.

> 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 than arbitrarily
> later when I try to .substitute with it.

No, create an is_valid() method at best.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug day tasks

[Christian Heimes]

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
> setup.

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.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jeffrey Yasskin]

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 you guys, but because
> > new support for the conversion routines seems to be rare, it's
> > probably best to have it return floats too.
>
> Sorry, I didn't understand this parragraph.
>
> Do you mean that the response in the following case is of type "float"?:
>
> >>> round(decimal.Decimal("2.5"))
> 3.0

Yes.

-- 
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug day tasks

[Jean-Paul Calderone]

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 logging
>> bot?  Maybe someone could just add #python-dev to their existing
>> setup.
>
>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.

The trac integration is entirely optional, so don't let that discourage
you.

If anyone wants to investigate setting this up,

  svn://divmod.org/svn/Divmod/sandbox/exarkun/commit-bot

The code has no unit tests and there is no documentation.  Also notice
"sandbox" in the SVN URL.

The only real advantage that it has over CIA that I can point out is that
you don't have to write an XML or have a SQL server running in order to use
it.

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[skip]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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
> > spurious tracebacks when daemon threads die. We're running some 2.4
> > apps with (a variant of) this at Google that get many 1000s of
> > invocations a day, so I'm pretty confident that it works.
> >
>
> I'm also pretty confident it works, although it isn't really guaranteed to
> catch *all* such situations. No reason not to backport it, just a remark
> about how it checks to see if Python is shutting down. It is, however,
> incredibly unlikely '_sys' won't be gone when we check for it if the
> exception is indeed a spurious one. What could happen is that a legitimate
> exception happens right before interpreter shutdown, then a thread switch
> occurs before Python tries to report the exception, the interpreter exits,
> and then the daemonic thread starts to report its exception. The only way to
> catch that is to do the 'are we exiting' check in the C code that does the
> actual thread-exception reporting. I'm not sure if it's worth it, as the
> timing has to be pretty exact for that to happen, and you wouldn't want to
> introduce a bug there; could be years before someone figures it out :P
>
> --
> Thomas Wouters <[EMAIL PROTECTED]>
>
> Hi! I'm a .signature virus! copy me into your .signature file to help me
> spread!



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 everything else! <0.5 wink>

Should I round that to 0 whole winks or 1 whole wink?

Rounding 0.5 to 0 is a new fad, called round-to-even, or
statistician's rounding. Read http://en.wikipedia.org/wiki/Rounding .
It's a standard, and more correct when doing statistical calculations.
That's why we've chosen it for Python 3.0. But it should not bleed
into Python 2.6.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> float('nan')
> nan
> >>> long(float('nan'))
> 0L
>
> My patch to Python 2.6 adds an explicit check for NaNs to always return
> 0L. It did feel a bit strange but it's the default on some platforms.
> Today an user pointed out that he doesn't like the patch, too.
>
> How should the problem be solved? In my humble opinion
> long(float('nan')) should return 0L in Python 2.5.2 for b/w
> compatibility and raise a ValueError or OverflowError in Python 2.6+.

If long(nan) or int(nan) returns 0 on most platforms in 2.5, we should
fix them to always return 0 in 2.5 *and* 2.6. In 3.0 they should raise
ValueError.

It looks like long(inf) and int(inf) already raise OverflowError and
that should stay.

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 return an int? Or do I misremember?)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[skip]

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 it should not bleed into
Guido> Python 2.6.

Thanks for the pointer.  Given that it's 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.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 __round__:
>
>   http://docs.python.org/dev/library/functions.html#round
>
> This doc says that round() "Return the floating point value x rounded
> to n digits after the decimal point.".
>
> It don't specify if its binary or decimal floating point, ;)
>
> Feel free to create an issue and assign to me if you think that this
> should be done.

In 3.0, round() of a Decimal should return an int if invoked with 1
arg, a Decimal if invoked with 2. Similar for round() of a float.
round() of an int can always return an int.

In 2.6, round() should always return a float, regardless of the type
of the first arg or the arg count, for best compatibility with 2.5.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Tracker Issues

[Tracker]

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 duration of open issues: 687 days.
Median duration of open issues: 947 days.

Open Issues Breakdown
   open  1359 (+15)
pending12 ( +0)

Issues Created Or Reopened (32)
___

urllib* 20x responses not OK?01/02/08
CLOSED http://bugs.python.org/issue1177reopened kbk  
   patch   

probable bug in code.py with Python 3.0a212/29/07
CLOSED http://bugs.python.org/issue1707created  aroberge 
   

improvements for linecache   12/30/07
   http://bugs.python.org/issue1708created  umaxx
   patch   

logging: log actual function name12/30/07
CLOSED http://bugs.python.org/issue1709created  umaxx
   

Pypi's  "score" column is not explained  12/30/07
CLOSED http://bugs.python.org/issue1710created  giampaolo.rodola 
   

socket functions that should return unsigned int return signed i 12/30/07
   http://bugs.python.org/issue1711created  mthibaut 
   

Small errors in new-style classes doc12/30/07
   http://bugs.python.org/issue1712created  salty-horse  
   

posixpath.ismount() claims symlink to a mountpoint is a mountpoi 12/31/07
CLOSED http://bugs.python.org/issue1713created  drougge  
   

ConfigParser.py do not allow leading (and trailing) space in val 12/31/07
   http://bugs.python.org/issue1714created  msuchy   
   

Make pydoc list submodules   12/31/07
   http://bugs.python.org/issue1715created  gustavo  
   patch   

String format operator '%i' fails for large floats   01/01/08
   http://bugs.python.org/issue1716created  ctl  
   

Get rid of more refercenes to __cmp__01/01/08
   http://bugs.python.org/issue1717created  gvanrossum   
   patch   

Tarfile fails to fully extract tar.bz2/tar.gz package01/01/08
CLOSED http://bugs.python.org/issue1718created  cartman  
   

Cosmetic patch for doc/code mismatch (msilib.UuidCreate) 01/02/08
   http://bugs.python.org/issue1719created  ocean-city   
   

VC6 build patch for release-maint25  01/02/08
   http://bugs.python.org/issue1720created  ocean-city   
   patch   

_tkinter.c:903: AsObj: Assertion `size < size * sizeof(Tcl_UniCh 01/02/08
CLOSED http://bugs.python.org/issue1721created  tiran
   py3k

Undocumented urllib functions01/02/08
   http://bugs.python.org/issue1722created  barry
   

Respuesta automática de Yahoo!  01/02/08
CLOSED http://bugs.python.org/issue1723created  gagenellina  
   

Py_SIZE() macro used as an lvalue01/02/08
CLOSED http://bugs.python.org/issue1724created  rhettinger   
   

-1e-1000 converted incorrectly   01/03/08

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

[Jeffrey Yasskin]

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 return an int? Or do I misremember?)

That's correct. It's currently broken, but I was waiting to push on
http://bugs.python.org/issue1656 until the backport was figured out.

-- 
Namasté,
Jeffrey Yasskin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug day tasks

[A.M. Kuchling]

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 bot and tie it into a svn post commit hook.

I'm thinking more about something to log all messages, so that participants 
can say "go see Raymond's explanation around 9AM".

For whoever's set up the CIA bot on python-dev: it seems to broadcast
messages twice.

(01:26:10 PM) amk_: I've just made a commit to the Python repository; we'll see 
if the CIA bot does anything.
(01:26:36 PM) CIA-35: andrew.kuchling * r59722 Doc/whatsnew/2.6.rst: Fix markup
(01:26:36 PM) CIA-35: andrew.kuchling * r59723 Doc/library/math.rst: Fix markup
(01:26:43 PM) amk_: Aha!
(01:26:45 PM) CIA-35: andrew.kuchling * r59722 Doc/whatsnew/2.6.rst: Fix markup
(01:26:46 PM) CIA-35: andrew.kuchling * r59723 Doc/library/math.rst: Fix markup

The commits also showed up twice in #commits:

(01:26:35 PM) CIA-9: merb: [EMAIL PROTECTED] * r1164 
/trunk/app_generators/merb/templates/Rakefile: core_ext/string is not loaded at 
this point, and there for the String#/ alias to File.join is not available. 
Rather than load that largish dep at this point, just change to File.join. 
resolves #395
(01:26:36 PM) CIA-9: python: andrew.kuchling * r59722 Doc/whatsnew/2.6.rst: Fix 
markup
(01:26:36 PM) CIA-9: python: andrew.kuchling * r59723 Doc/library/math.rst: Fix 
markup
(01:26:45 PM) CIA-9: python: andrew.kuchling * r59722 Doc/whatsnew/2.6.rst: Fix 
markup
(01:26:46 PM) CIA-9: python: andrew.kuchling * r59723 Doc/library/math.rst: Fix 
markup
(01:27:02 PM) CIA-9: jmol: nicove * r8906 /trunk/Jmol-FAH/projects/ 
(p3060.xyz.gz p3061.xyz.gz p3062.xyz.gz p3906.xyz.gz): [EMAIL PROTECTED]

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Need closure on __cmp__ removal

[Guido van Rossum]

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 month to write the PEP, and then
I'll review it. The PEP better come with a patch implementing
(roughly) the desired behavior as well, relative to the 3.0 branch.

If I don't hear from a committed volunteer within a week, I'll drop
this and start removing __cmp__ references aggressively (starting with
issue #1717). Saying "if no-one else volunteers, I can give it a shot"
is not sufficient commitment. Saying "I will give it a shot" is. If
someone commits but no PEP+patch is in my possession by February 4
(and no attenuating circumstances have been brought to my attention),
I will assume the PEP won't happen and will start removing __cmp__
references. Once a PEP and patch are presented, I'll review them and
make a decision.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug day tasks

[Christian Heimes]

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.

I've written a CIA notification extension for Roundup:
http://pastebin.ca/841568

It works standalone but I haven't been able to enable email and CIA
notifications in my local demo of Roundup. The output could probably use
some adjustments, too.

Can somebody please test it and integrate it into the bug tracker?

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Adam Olsen]

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. If someone volunteers within a
> week to write a PEP, I'll give them a month to write the PEP, and then
> I'll review it. The PEP better come with a patch implementing
> (roughly) the desired behavior as well, relative to the 3.0 branch.
>
> If I don't hear from a committed volunteer within a week, I'll drop
> this and start removing __cmp__ references aggressively (starting with
> issue #1717). Saying "if no-one else volunteers, I can give it a shot"
> is not sufficient commitment. Saying "I will give it a shot" is. If
> someone commits but no PEP+patch is in my possession by February 4
> (and no attenuating circumstances have been brought to my attention),
> I will assume the PEP won't happen and will start removing __cmp__
> references. Once a PEP and patch are presented, I'll review them and
> make a decision.


I can't speak for the others, but I know I've decided not to pursue it.

-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Peters]

[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 use for even longer, is
also (Wikipedia notwithstanding) part of many standards (for example,
the US IRS requires it if you do your taxes under the "round to whole
dollars" option), and-- probably the real driver --is a little cheaper
to implement for "normal sized" floats.  Curiously, round-to-nearest
can be unboundedly more expensive to implement in some obscure
contexts when floats can have very large exponents (as they can in
Python's "decimal" module -- this is why the proposed decimal standard
allows operations like "remainder-near" to fail if applied to inputs
that are "too far apart":

http://www2.hursley.ibm.com/decimal/daops.html#footnote.8

The "secret reason" is that it can be unboundedly more expensive to
determine the last bit of the quotient (to see whether it's even or
odd) than to determine an exact remainder).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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.  That's why
> Guido> we've chosen it for Python 3.0. But it should not bleed into
> Guido> Python 2.6.
>
> Thanks for the pointer.  Given that it's 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 programming language designers rarely are statisticians?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 programming languages.
>
> Because "add a half and chop" was also in wide use for even longer, is
> also (Wikipedia notwithstanding) part of many standards (for example,
> the US IRS requires it if you do your taxes under the "round to whole
> dollars" option), and-- probably the real driver --is a little cheaper
> to implement for "normal sized" floats.  Curiously, round-to-nearest
> can be unboundedly more expensive to implement in some obscure
> contexts when floats can have very large exponents (as they can in
> Python's "decimal" module -- this is why the proposed decimal standard
> allows operations like "remainder-near" to fail if applied to inputs
> that are "too far apart":
>
> http://www2.hursley.ibm.com/decimal/daops.html#footnote.8
>
> The "secret reason" is that it can be unboundedly more expensive to
> determine the last bit of the quotient (to see whether it's even or
> odd) than to determine an exact remainder).

Wow. Do you have an opinion as to whether we should adopt
round-to-even at all (as a default)?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Repeatability of looping over dicts

[A.M. Kuchling]

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
.

ConcurrentHashMap scales better in the face of threading because it
doesn't lock the whole table when updating it, but iterating over the
map can return elements in a different order each time.  This would
mean that list(dict_var) doesn't return values in the same order as a
later call to list(dict_var), even if dict_var hasn't been modified.

Why?  Under the hood, there are 32 different locks, each guarding a
subset of the hash buckets, so if there are multiple threads iterating
over the dictionary, they may not go through the buckets in order.
 discusses
the implementation, at least in 2003.

So, do Python implementations need to guarantee that list(dict_var) ==
a later result from list(dict_var)?

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Delaney]

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.html

(3) Keys and values are listed in an arbitrary order which is non-random,
varies across Python implementations, and depends on the dictionary's
history of insertions and deletions. If items(), keys(), values(),
iteritems(), iterkeys(), and itervalues() are called with no intervening
modifications to the dictionary, the lists will directly correspond.
This allows the creation of (value, key) pairs using zip(): "pairs =
zip(a.values(), a.keys())". The same relationship holds for the
iterkeys() and itervalues() methods: "pairs = zip(a.itervalues(),
a.iterkeys())" provides the same value for pairs. Another way to create
the same list is "pairs = [(v, k) for (k, v) in a.iteritems()]".

Tim Delaney 

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 Drake   




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[A.M. Kuchling]

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:

Ah, thanks!  I guess that rules out using ConcurrentHashMap, short of
materializing the entire list and sorting it in some way.  Oh well.

--amk


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Delaney]

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.html

(3) Keys and values are listed in an arbitrary order which is non-random,
varies across Python implementations, and depends on the dictionary's
history of insertions and deletions. If items(), keys(), values(),
iteritems(), iterkeys(), and itervalues() are called with no intervening
modifications to the dictionary, the lists will directly correspond.
This allows the creation of (value, key) pairs using zip(): "pairs =
zip(a.values(), a.keys())". The same relationship holds for the
iterkeys() and itervalues() methods: "pairs = zip(a.itervalues(),
a.iterkeys())" provides the same value for pairs. Another way to create
the same list is "pairs = [(v, k) for (k, v) in a.iteritems()]".

Tim Delaney 

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] function call syntax oddity

[Paul Moore]

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__". That's not valid.

>  >>> 1 .__str__()
>  '1'

This one is a number "1" followed by the operator "." followed by "__str__".

The lexer reads the longest valid token each time.
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] function call syntax oddity

[Joseph Armbruster]

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'

>>> 1.3.__str__()
'1.3'

>>> a = " somestring   "

>>> a  .split()
['somestring']

>>> a. split()
['somestring']


Cool I suppose, except here's an odd man out:

>>> 1.__str__()
  File "", line 1
1.__str__()
^
SyntaxError: invalid syntax

>>> 1 .__str__()
'1'

Joseph Armbruster
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Raymond Hettinger]

[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 easy to explain, it runs fast, and it is not hard 
to get right.

my two cents,

Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Contributing to Python

[Martin v. Löwis]

> 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 better interaction on the mid/long term,
> even if in the short it appears to increase the noise a little.

I think this is exactly right. If you don't understand a certain aspect,
don't hesitate to ask. Maybe the submitter doesn't understand either,
and it was a flaw in the patch, or maybe there is a real issue, and
the submitter forgot to comment it properly - it's always the
submitter's fault if you don't understand :-)

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Isaac Morland]

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 than arbitrarily
>> later when I try to .substitute with it.
>
> No, create an is_valid() method at best.

I'm curious as to why.  Is it to avoid changing the behaviour of existing 
code (i.e., backwards compatibility), or do you see a design problem with 
having the Template constructor reject invalid template strings?

Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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  
the set of promises made by the dict methods a decode ago, but it was  
in response to a need in the software I was working on at the time  
(possibly Grail, for which 2.6/3.0 isn't an issue).

That question should probably be addressed to a fairly wide audience  
(comp.lang.python) since the promise has been there for so long.


   -Fred

-- 
Fred Drake   




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] function call syntax oddity

[Raymond Hettinger]

[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.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 Jython's dict type.  See
> .
>
> ConcurrentHashMap scales better in the face of threading because it
> doesn't lock the whole table when updating it, but iterating over the
> map can return elements in a different order each time.  This would
> mean that list(dict_var) doesn't return values in the same order as a
> later call to list(dict_var), even if dict_var hasn't been modified.
>
> Why?  Under the hood, there are 32 different locks, each guarding a
> subset of the hash buckets, so if there are multiple threads iterating
> over the dictionary, they may not go through the buckets in order.
>  discusses
> the implementation, at least in 2003.
>
> 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 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
think about auto-closing files once Jython came along, I think this is
at least worth considering.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Raymond Hettinger]

>> 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:
   print '%5s' % k
   for k in d:
   print '-'
   for v in d.values():
   print '%5s' % v

It seems likely to me that a lot of code using d.values() would care about the 
order of the values and the only order that matters is corresponding to some 
set of keys.  There are probably a lot of functions that take keys and values 
separately, so it would not be uncommon to call those with a pattern like: 
save_config(configfile, d.keys(), d.values()).

In the OP's context where multiple threads are running, it may be fair to say 
that all bets are off.


Raymond

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[A.M. Kuchling]

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/codesearch?hl=en&q=+lang:python+zip+keys&start=10&sa=N
turns up a few pieces of code that would break:

trac-0.10.3/trac/versioncontrol/cache.py 
Twisted-2.2.0/twisted/pb/test/test_banana.py 
Mattricks-0.7/Mattricks/MatchPrediction.py 
FlickrUploadr-1.0.0/src/xmltramp.py 

Projects trying to stay compatible with Python versions that don't
have .items() may be more likely to use this idiom.  Some classes may
do this to implement .items(); openbabel-2.1.1/scripts/python/pybel.py
does this.  So some code will break, and I don't see a way to warn
about this problem before breaking compatibility.

--amk

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[glyph]

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 int(x+0.5).  That works everywhere, it is easy to explain, it 
>runs fast, and it is not hard to get right.

I agree for the default.  Except the part where Excel, Jython, and 
Python's current round, actually use sign(x) * int(abs(x)+0.5), so maybe 
it's not *completely* easy to get right ;-).

Having other rounding methods *available*, though, would be neat.  The 
only application I've ever worked on where I cared about the difference, 
the user had to select it (since accounting requirements differ by 
jurisdiction and, apparently, by bank preference).  Having a standard 
way to express this (especially if it worked across different numeric 
types, but perhaps I digress) would be pleasant.  Implementing 
stochastic rounding and banker's rounding oneself, while not exactly 
hard, is a drag.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Gregory P. Smith]

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.  See
> .
>

As a side note, you may also want to consider using a
NonBlockingHashMap as implemented by Cliff Click instead of
ConcurrentHashMap:

 http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.html
 http://blogs.azulsystems.com/cliff/2007/03/talking_with_go.html
 http://video.google.com/videoplay?docid=2139967204534450862
 http://sourceforge.net/projects/high-scale-lib

I haven't looked to see if it has the same issues repeatability issues
but it does scale even better.

Anyways, could you not use something with repeatability issues with a
wrapper that caches lists of keys to satisfy the repeatability?
(don't lock and maintain the list, just regenerate the list on demand
when a caller needs it and discard the cached list anytime a key is
added or deleted)

Also, should we drop this guarantee in py3k to give future
implementations more flexibility?

-gps

> ConcurrentHashMap scales better in the face of threading because it
> doesn't lock the whole table when updating it, but iterating over the
> map can return elements in a different order each time.  This would
> mean that list(dict_var) doesn't return values in the same order as a
> later call to list(dict_var), even if dict_var hasn't been modified.
>
> Why?  Under the hood, there are 32 different locks, each guarding a
> subset of the hash buckets, so if there are multiple threads iterating
> over the dictionary, they may not go through the buckets in order.
>  discusses
> the implementation, at least in 2003.
>
> So, do Python implementations need to guarantee that list(dict_var) ==
> a later result from list(dict_var)?
>
> --amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Contributing to Python

[Mike Klaas]

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 right.
>
> It will be though -- it will have genuine new features -- yes,
> backported from 3.0, but new features nevertheless, and in a
> compatible fashion.

I think that there are still tons of people like me for whom 3.0 is  
still a future concern that is too big to devote cycles to at the  
moment, but are still very much interested in improving the 2.x  
series (which improves 3.0) at the same time.

I've been inspired by this thread to start working on a few 2.6 items  
that I had in mind, starting with http://bugs.python.org/ 
issue1663329 , which mostly just needed documentation and cleanup  
(now done).

Question: should patches include edits to whatsnew.rst, or is the  
committer responsible for adding a note?

-Mike 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com