Re: [Python-Dev] Bug in from __future__ processing?

[Anthony Baxter]

On Saturday 04 March 2006 15:34, Tim Peters wrote:
> Indeed!  But whose arm could we twist to get them to repair the
> compiler in 2.4?  I'd settle for a blurb in the next 2.4 NEWS just
> noting that 2.5 will follow the documented syntax.  That may even
> be desirable, to avoid breaking working (albeit by accident) code
> across a micro release.

I don't think a change like this should go into a 2.4.x release. It 
stands a very very high chance of breaking someone's code. I _could_ 
be convinced about a warning being emitted about it, though I'm not 
going to have the time to figure out the new compiler to do the work. 

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] __exit__ API?

[Nick Coghlan]

Guido van Rossum wrote:
> A few days ago there were rumbling noises that requiring __exit__ to
> re-raise the exception (as I amended PEP 343 at the time) could lead
> to easily-missed bugs in __exit__ handlers.
> 
> After thinking it over I think I agree and I think I'd like to change
> the API so that the exception is only ignored if __exit__ returns a
> "true" value.
> 
> The easiest implementation is probably to just let the WITH_CLEANUP
> opcode do everything. This becomes a rather heavy opcode then but the
> alternative is to generate very hairy code (like the original patch
> did, full of ROT 4 choruses).
> 
> Any objections? I probably won't get to this until Monday.

Sounds good to me - I believe the majority of explicit __exit__ handlers will 
be of a try/finally nature rather than try/except, and that situations where 
the exception is going to be suppressed are better handled using 
@contextmanager.

The solution you propose means that __exit__ methods *can* suppress exceptions 
if they want to, but their default behaviour will still do the right thing.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] FrOSCon 2006 - Call for {Papers|Projects}

[M.-A. Lemburg]

Is anyone interested in having a Python track at this conference ?

PS: The EuroPython conference takes place in Geneva, one week
later.

 Original Message 
Subject: FrOSCon 2006 - Call for {Papers|Projects}
Date: Fri, 03 Mar 2006 16:39:08 +0100
From: Sebastian Bergmann 
Organization: Free and Open Source Software Conference -
Bonn/Rhein-Sieg, Germany

FrOSCon is a two-day conference on free software and open source, which
takes place on 24th and 25th June 2006 at the University of Applied
Sciences Bonn-Rhein-Sieg, in St. Augustin near Bonn, Germany.

Focus of the conference is a comprehensive range of talks about current
topics in free software and open source. Furthermore, space will be
provided for developers of free software and open source projects to
organize their own developer meetings or even their own program.

FrOSCon is organized for the first time in 2006 by the department of
computer science in collaboration with the Linux/Unix User Group Sankt
Augustin, the student body and the FrOSCon e.V., and aims to establish
itself as the largest event of its kind in Rhineland.

=== Projects ===

Successful projects form the backbone of the open source and free
software movements. FrOSCon wants to acknowledge this important role of
projects for the community by offering special facilities to individual
projects.

=== Developer Rooms ===

Open source and free software projects are often coordinated primarily
via the internet, via email, the web and IRC. Nonetheless, personal
contact between members of the project is of paramount importance. A
conference like FrOSCon can serve as a meeting place, where distant
members of the project can come together and meet.

FrOSCon wants to offer dedicated developer rooms to individual
projects, which are organized by the projects themselves. Thereby, we
provide a space for projects to hold special-interest talks or
meetings, to congregate, exchange views and to socialize.

We have rooms in different sizes suitable for small developer meetings
up to sub-conferences. We offer Internet access in all developer rooms.
Besides tables and chairs, most rooms are or can be equipped with a
video beamer. If necessary, an additional lecture hall can be assigned
for talks or presentations where a larger audience is expected.

=== Application ===

Please send applications for a developer room via email to
[EMAIL PROTECTED] Please include at least the name of your project,
the URL of your website and the expected number of participants in your
email.

The Call for Projects ends on March 31st.

=== Call for Papers ===

Please note that our Call for Papers is still open until March 15th.
Don't miss the chance to submit a talk.

You can find all the details about the Call for Papers here:

http://www.froscon.org/wiki/CallforPapers

=== Booth Space ===

If your project wants to man a booth at FrOSCon, feel free to contact
[EMAIL PROTECTED] as well.

We are looking forward to hearing from you.

Kind regards,
The FrOSCon Team

-- 
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69



-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 03 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Outdated Python Info on www.unicode.org (fwd)

[skip]

Someone here (Martin, MAL, /F?) would probably be able to write a short,
authoritative description of Python's Unicode powers.  Any takers?

Skip

--- Begin Message ---
The Unicode Consortium has a page about Unicode Enabled Products 
. This page contains 
some really outdated information about Python (like Python 2.3 will come 
out in a few months).

Could someone who knows the current state of Unicode support in Python 
update this information?


Thanks,
Dennis Benzinger
-- 
http://mail.python.org/mailman/listinfo/python-list
--- End Message ---
___
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] My buildbot host upgraded to OSX 10.4

[skip]

I upgraded my PowerMac G5 to OSX 10.4.  ZopeInterface isn't recompiling
after the upgrade to XCode 2.1.  You probably ought to just pull "g5 osx.3"
from the buildbot host list, certainly until I have time to figure this
problem out.  (Probably after as well.  My machine configuration is now not
substantially different from the loaner XServer.)

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] My buildbot host upgraded to OSX 10.4

[skip]

skip> I upgraded my PowerMac G5 to OSX 10.4.  ZopeInterface isn't
skip> recompiling after the upgrade to XCode 2.1.  

Okay, my buildbot slave is back online.  Still, feel free to kick it out if
you think it's not worth it to continue running it.

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] My buildbot host upgraded to OSX 10.4

[Martin v. Löwis]

[EMAIL PROTECTED] wrote:
> I upgraded my PowerMac G5 to OSX 10.4.  ZopeInterface isn't recompiling
> after the upgrade to XCode 2.1.  You probably ought to just pull "g5 osx.3"
> from the buildbot host list, certainly until I have time to figure this
> problem out.  (Probably after as well.  My machine configuration is now not
> substantially different from the loaner XServer.)

Ok, I have now removed your machine from the list of slaves. Thanks for
your contribution in getting this started!

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] iterator API in Py3.0

[Anna Ravenscroft]

On 3/3/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[Aahz]> * As a writer/teacher, I want to be able to say, "All Python special> methods have leading and trailing double-underscore."  Period, end of> story.When teaching your classes, do you sense an aversion to using double underscore
methods in regular code?  I sense an implied message that these methods are notintended to be called directly (i.e. the discomfort of typing x.__setitem__(k,v)serves as a cue to write x[k]=v instead; likewise, x.__int__() pushes towards
int(x) instead).If so, then that is a good reason to leave it.next() as-is.  Unlike __setitem__or __int__, the next() method is intended to be called directly in normal code.Of course, for-loops are the most common case and it makes no difference there;
however, in the rest of the cases where the iterator is accessed directly, thecurrent naming is clean, readable, and doesn't provide an aversive cue.The double underscore convention is appropriate where the method is always
invoked magically in normal code and not called directly.  The next() method isdifferenct because it is a mixed case, sometimes called magically and sometimescalled directly.  In the latter case, the name is highly visible and therefore
should not have double underscores.I suspect that those who feel differently are ones who usually avoid callingnext() directly.  That's okay, but we shouldn't muck-up the naming for the restof us who often do have a need to use next().
This is doubly important because we're now expanding the protocol to includesend() and throw().  Adding underscores around them too will only make thosemethods look harder to use than they actually are.  Don't underestimate the
psychological revulsion to calling code filled with piles of double underscores.

I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand
the desire for both forms, although that seems it would clutter things
up unnecessarily - particularly if the two do the same thing. 

Anna

___
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] iterator API in Py3.0

[Phillip J. Eby]

At 09:34 AM 3/4/2006 -0800, Anna Ravenscroft wrote:
>I think this is a really good point. next() is supposed to get used, by 
>coders, in regular code - so it shouldn't be __next__. I can understand 
>the desire for both forms, although that seems it would clutter things up 
>unnecessarily - particularly if the two do the same thing.

By this argument, we should be using ob.len() instead of len(ob), and 
ob.iter() instead of iter(ob).

___
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] iterator API in Py3.0

[Oleg Broytmann]

On Sat, Mar 04, 2006 at 03:45:03PM -0500, Phillip J. Eby wrote:
> At 09:34 AM 3/4/2006 -0800, Anna Ravenscroft wrote:
> >I think this is a really good point. next() is supposed to get used, by 
> >coders, in regular code - so it shouldn't be __next__. I can understand 
> >the desire for both forms, although that seems it would clutter things up 
> >unnecessarily - particularly if the two do the same thing.
> 
> By this argument, we should be using ob.len() instead of len(ob), and 
> ob.iter() instead of iter(ob).

   Yes, I think it'd be more consistent and more object-oriented. After all
we've switched from string.split(x, y) to x.split(y)...

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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] iterator API in Py3.0

[Raymond Hettinger]

[Anna Ravenscroft]
>>I think this is a really good point. next() is supposed to get used, by 
>>coders, in regular code - so it shouldn't be __next__. I can understand the 
>>desire for both forms, although that seems it would clutter things up 
>>unnecessarily - particularly if the two do the same thing.

[Phillip Eby]
> By this argument, we should be using ob.len() instead of len(ob), and 
> ob.iter() instead of iter(ob).

Hey, no fair misstating her argument and then reducing it to the absurd.  We're 
all aware that __len__ and __iter__ are supported by a wide variety of object 
types and are accessed through builtin functions provided expressly for that 
purpose.  In contrast, we're all aware that next() applies only iterator 
objects, that it was designed for both direct and magic invocation, and that 
there is no corresponding builtin.

This conversation is getting goofy.  There is no underlying problem to be 
solved.  Essentially, a couple of developers feel irritated by a perceived 
aberration from a naming convention.  To assuage that irritation, they are 
willing to either 1) inflict pain on direct callers by cluttering the calling 
code with pairs of double underscores, or 2) add yet another builtin 
(needlessly 
bloating the namespace, adding another level of indirection, and burdening 
execution with an unnecessary global lookup).  The cure is worse than the 
disease.

IMO, the appropriate solution is to amend your understanding of the naming 
convention to only apply to methods whose normal invocation is exclusively 
magic 
and not called directly.



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] iterator API in Py3.0

[Phillip J. Eby]

At 04:11 PM 3/4/2006 -0500, Raymond Hettinger wrote:
>[Anna Ravenscroft]
>>>I think this is a really good point. next() is supposed to get used, by 
>>>coders, in regular code - so it shouldn't be __next__. I can understand 
>>>the desire for both forms, although that seems it would clutter things 
>>>up unnecessarily - particularly if the two do the same thing.
>
>[Phillip Eby]
>>By this argument, we should be using ob.len() instead of len(ob), and 
>>ob.iter() instead of iter(ob).
>
>Hey, no fair misstating her argument and then reducing it to the 
>absurd.  We're all aware that __len__ and __iter__ are supported by a wide 
>variety of object types and are accessed through builtin functions 
>provided expressly for that purpose.  In contrast, we're all aware that 
>next() applies only iterator objects, that it was designed for both direct 
>and magic invocation, and that there is no corresponding builtin.

I didn't misstate her argument or reduce it to the absurd.  I simply 
applied that argument consistently to similar features of Python.  It's you 
who is concluding that this results in absurdity; I made no such 
conclusion.  I'm simply pointing out that in 3.0 we should be 
consistent.  Either we should have ob.iter() and ob.len(), or else we 
should have a builtin next().


>This conversation is getting goofy.  There is no underlying problem to be 
>solved.  Essentially, a couple of developers feel irritated by a perceived 
>aberration from a naming convention.  To assuage that irritation, they are 
>willing to either 1) inflict pain on direct callers by cluttering the 
>calling code with pairs of double underscores, or 2) add yet another 
>builtin (needlessly bloating the namespace, adding another level of 
>indirection, and burdening execution with an unnecessary global lookup).

You have it backwards.  If those things are so important as to be the 
deciding factor, we should add .len() and .iter() methods in 3.0 and use 
them instead of the len() and iter() functions.

Personally, I prefer functions to methods for these kinds of 
language-defined operations, but that has nothing to do with the issue of 
consistency.  As far as I can understand your position, you seem to be 
arguing that whatever we have now is correct, and therefore changing it 
would be wrong.  That is, since we use .next() now, this is correct by 
definition and a change to next() + __next__ would therefore be wrong.  And 
*that* is the only "goofy" thing I see going on here.  :)

___
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] iterator API in Py3.0

[Phillip J. Eby]

At 12:05 AM 3/5/2006 +0300, Oleg Broytmann wrote:
>On Sat, Mar 04, 2006 at 03:45:03PM -0500, Phillip J. Eby wrote:
> > At 09:34 AM 3/4/2006 -0800, Anna Ravenscroft wrote:
> > >I think this is a really good point. next() is supposed to get used, by
> > >coders, in regular code - so it shouldn't be __next__. I can understand
> > >the desire for both forms, although that seems it would clutter things up
> > >unnecessarily - particularly if the two do the same thing.
> >
> > By this argument, we should be using ob.len() instead of len(ob), and
> > ob.iter() instead of iter(ob).
>
>Yes, I think it'd be more consistent and more object-oriented.

I'm not sure that "more object-oriented" should be equated with "good" in 
this context, or indeed any context.  :)  A function is no more or less 
polymorphic than a method in any case, especially if the function is 
normally delegating to a slot or special method in any case.

___
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] Another Windows buildbot slave

[Josiah Carlson]

It took me a while to get it set up, but we've got another Windows XP
buildbot slave running.

 - Josiah

___
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] Another Windows buildbot slave

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> wrote:
> It took me a while to get it set up, but we've got another Windows XP
> buildbot slave running.

Spoke too soon, not quite ready yet.

 - Josiah

___
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] iterator API in Py3.0

[Phillip J. Eby]

At 04:44 PM 3/4/2006 -0500, Raymond Hettinger wrote:
>>  As far as I can understand your position, you seem to be arguing that 
>> whatever we have now is correct, and therefore changing it would be wrong.
>
>Yes, that's pretty much it.  IMO, introducing __builtin__.next() would 
>suck. The sublime feeling of consistency isn't worth the cost of an extra 
>builtin and adding an unnecessary global lookup to an otherwise 
>lightweight inner-loop construct.

You mean, versus an unnecessary attribute lookup?  :)  Guido has stated 
many times that future versions of Python should be able to optimize 
references to builtins so that the global cost isn't 
required.  Optimization of attribute lookups is a bit more speculative at 
this point, and can currently involve *more* dictionary lookups than a 
global lookup, depending on the inheritance depth.  IIRC, looking for a 
'next' method on a new-style object requires a minimum of two dictionary 
accesses already: one to look in the class, and one in the instance to make 
sure it's not shadowed.  In contrast, __next__() could be a fast slot 
access, since slots are copied directly to subclasses.

(But neither the performance argument nor the "extra builtin" argument make 
sense to me anyway, since they would both apply equally to len() and iter().)

___
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