Re: [Python-Dev] GeneratorExit inheriting from Exception

[Giovanni Bajo]

Nick Coghlan <[EMAIL PROTECTED]> wrote:

> Rather than trying to change course midstream, I *like* the fact that
> the PEP 352 hierarchy introduces BaseException to bring the language
> itself into line with what people have already been taught. Breaking
> things in Py3k is all well and good, but breaking them gratuitously
> is something else entirely :)

I really like this too, but Barry's proposal doesn't really *break* anything.
Existing Python code that creates a FooBar(Exception) and then catches it with
either "except FooBar:" or "except Exception, e:" + check for FooBar, will
still work as expected. At *worse*, it would be catching too much, like
SystemExit or GeneratorExit, which are still pretty uncommon exception.

OTOH, I also understand that people have been told that deriving from Exception
is the right thing to do forever now.

Giovanni Bajo

___
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] buildbot failure in sparc solaris10 gcc trunk

[python-dev]

The Buildbot has detected a new failure of sparc solaris10 gcc trunk.
Full details are available at:
 http://www.python.org:9010/sparc%20solaris10%20gcc%20trunk/builds/68

Buildbot URL: http://www.python.org:9010/

Build Reason: The web-page 'rebuild' button was pressed by '': Force compile 
error

Build Source Stamp: [branch trunk] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
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] Test

[python-dev]

Testing submission from dinsdale.
___
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] Patch or feature? Tix.Grid working for 2.5

[Christos Georgiou]

"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
On 3/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Christos Georgiou wrote:

> > I would like to know if supplying a patch for it sometime in the next 
> > couple
> > of weeks would be considered a patch (since the widget currently is not
> > working at all, its class in Tix.py contains just a pass statement) or a
> > feature (ie extra functionality) for the 2.5 branch...

[Martin]
> I wouldn't object to including it before beta 1.

Good to have a general deadline (ObRef Douglas Adams: ""I like deadlines; I 
especially like the whooshing sound they make as they go flying by.")

[Neal]
> Nor would I.  I'm not sure if this helps or not, but a general rule of
> thumb is if it's 100 lines it's probably a patch.  If it's 1000 lines,
> it's probably a major feature.  Given such a patch is pure python and
> probably much closer to 100 lines, this should be ok.

It should amount to 100-200 lines as far as I can see, I'm just playing with 
.tk.call and writing down how to do stuff, and trying to grok the general 
style of classes interfacing to Tkinter/Tix.  DisplayStyle is already there, 
which is good.  Thankfully the tix docs seem to be complete, so it should be 
only a matter of time.  I will try to update tixwidgets.py with a demo page 
too.

[Neal]
> BTW, have you contacted the Tix people?  It is a separate project and
> looks like people are working on it.  http://tix.sourceforge.net/

That's where I got the documentation.  I haven't contacted them, though, 
because I saw that Tix.py hasn't been modified for 4 years now.  I will 
offer the patch both to the Python and the Tix Tix.py though, thanks for the 
suggestion. 


___
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] buildbot failure in sparc solaris10 gcc trunk

[Terry Reedy]

 wrote in message 
news:[EMAIL PROTECTED]
> The Buildbot has detected a new failure of sparc solaris10 gcc trunk.
> Full details are available at:
> http://www.python.org:9010/sparc%20solaris10%20gcc%20trunk/builds/68
>
> Buildbot URL: http://www.python.org:9010/

Both links failed with Cannot Find Server (Winxp/IE).
 Removed :9010 and latter worked fine.
By now, Sparc is green and Winxp has compile failure

tjr



___
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] buildbot failure in sparc solaris10 gcc trunk

[Martin v. Löwis]

Terry Reedy wrote:
>> Buildbot URL: http://www.python.org:9010/
> 
> Both links failed with Cannot Find Server (Winxp/IE).

Right. Buildbot doesn't know what its URL is; it is
http://www.python.org/dev/buildbot/

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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c

[Ronald Oussoren]

On 18-mrt-2006, at 10:28, M.-A. Lemburg wrote:

> Ronald Oussoren wrote:
>> On 17-mrt-2006, at 22:14, M.-A. Lemburg wrote:
>>
>>> Martin v. Löwis wrote:
 Thomas Heller wrote:
> I'm not sure if this is what Marc-Andre means, but maybe these
> definitions
> could go into a new include file:
 How would that include file be used? You would have to copy it
 into your
 own source base, and include it, right?
>>> We could put it into a b/w compatibility header file, e.g.
>>>
>>> #include "pycompat.h"
>>
>> But wouldn't this header be needed on versions of python before 2.5?
>
> Yes. Ideally it should work on more Python versions than just
> Python 2.5.
>
> I have such a compatibility header file for the mx Extensions
> (called mxpyapi.h and included in egenix-mx-base).
>
> It includes #defines such as the one Thomas proposed for
> Python back to version 1.5.
>
>> That
>> would make inclusion of a pycompat.h header with python 2.5 less  
>> useful.
>
> Why is that ? For older versions you can copy it into your
> extension's include directory. With the usual #ifdef PYCOMPAT_H
> wrapper this won't get included if Python already includes
> the header file via  #include "Python.h".

The actual contents of the file would be useful, but having a
header file should be copied into your own projects seems odd
to me. I'd expect information like this to be in the documentation
(either the size_t PEP or the extending & embedding document).

Ronald

___
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] Py3K timescale and stdlib philosophy (was: Re: Py3K thought: use...)

[John J Lee]

On Fri, 17 Mar 2006, Brett Cannon wrote:

> On 3/17/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>> Thought: We should drop all of httplib, urllib, urllib2, and ftplib,
>> and instead adopt some third-party library for HTTP/FTP/whatever,
>> write a Python wrapper, and use it instead.  (The only such library I
[...]
> But maybe this also poses a larger question of where for Py3K we want
> to take the stdlib.  Ignoring its needed cleanup and nesting of the
> namespace, do we want to try to use more external tools by importing
> them and writing a Pythonic wrapper?  Or do we want to not do that and
> try to keep more things under our control and go with the status quo?
> Or do we want to really prune down the stdlib and use more dynamic
> downloading ala Cheeseshop and setuptools?
[...]

Do we have any idea yet what sort of timescale we're talking about for 
Python 3.0 (or should I call it Py3K still)?

I have a personal interest in these particular modules, but the questions 
that seem to need answering first are more general ones about the stdlib 
post-3.0.  Brett asks some good questions.

ISTM that another important question must be: What do each of the small 
set of people like yourself (Brett), Andrew, Martin, Georg, Raymond 
(etc.!) who bear most of the burden of maintaining the stdlib at present, 
intend to do after Python 3.0 is out?  I assume that it would only be 
useful to drop parts of the stdlib in this way if that group of people 
were then to stop working on them.  That makes sense, but I don't want to 
make assumptions about what each of the group of people referred to above 
intend to do post-3.0:

  a. Drop 2.x right away to concentrate on developing and maintaining the
 3.0 stdlib (and/or the 3.0 interpreter)?

  b. Spend at least some effort maintaining 2.x for a few years?

  c. Carry on maintaining 2.x for a few years?

  d. Ignore 3.x and continue with 2.x indefinitely?

  e. Watch and see how the Python community at large responds to 3.0?

  f. Wait and see what you feel like doing at the time?

  g. Some combination of the above?

  h. Quit Python to take up pig farming?


These sorts of questions are often quite hard to answer, I understand, 
because many people often want to see what everybody else will do before 
making up their minds.  But I guess people who post here frequently are 
less likely to do that than are the rest of us sheep ;-)

[BTW, I assume much of the stdlib will remain essentially the same (if not 
without backwards-incompatibilities), one hopes people will step in to 
backport 3.0 fixes (and perhaps forward-port: I make no judgement about 
which of 2.x and 3.x will have the larger user community in the short or 
long term).  People will presumably be more motivated to do that than 
currently, since I assume many people will not port all (or any) of their 
code to 3.0.]


John
___
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] __dict__ strangeness

[Armin Rigo]

Hi,

On Sat, Mar 18, 2006 at 06:57:12PM +0100, Georg Brandl wrote:
> >> >>> class D(object):
> >> ... __dict__ = {}
> >> ...
> >> >>> d = D()
> >> >>> d.a = 1
> >> >>> d.__dict__
> >> {}
> >> >>> d.__dict__ = {}
> >> >>> d.a
> >> 1
> > 
> > Yep, that's the bug, fully reproducible in 2.3 and 2.4.

IMHO this is not a bug, it's expected behavior.  I don't see what you
could "fix" without hacking the Python 2.2 descriptor model -- which is
possible, but probably not what we *should* do.  See zseil's
explanations on the SF tracker.


A bientot,

Armin
___
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] dealing with decorators hiding metadata of decorated functions

[Brett Cannon]

On 3/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > "Brett Cannon" <[EMAIL PROTECTED]> wrote:
> >> With the discussion of a possible @decorator to help set the metadata
> >> of the decorator to that of what the wrapped function has, I had an
> >> idea that I wanted to toss out there (this dicussion stems from a blog
> >> post I made: 
> >> http://sayspy.blogspot.com/2006/03/how-to-handle-object-identity-issues.html).
> >
> > [snip]
> >
> > Edward Loper suggested this way back on September 5, 2004.
> >
> > http://mail.python.org/pipermail/python-dev/2004-September/048626.html
> >
> > I was and continue to be +1 on this,
>
> +1 here, too. Unlike Brett, though, I have no problem with overwriting
> __name__ and updating __dict__ unconditionally, and overwriting __doc__ if it
> hasn't already been set.
>

I have no problem with updating __dict__ since decorators that just 
do annotations will need to have that information passed forward.  But
if Josiah's suggestion is taken and decorators are just part of a
lookup chain of attributes and they just fall through then this would
not be needed.

> The first two are needed if we expect "print f" and "f.a" to work properly.

I don't know if having ``print f`` work like that is important.  And
if it is print can be tweaked to follow __decorates__ properly.

> The function's name is set on the 'def' line, and I'd be much happier seeing
> that at all levels of the decorator chain, rather than seeing something like
> "wrapper", "wrapper", ... "wrapper", "f". Annotating decorators will modify
> the functions' attributes, and this needs to be visible in the final
> function's dictionary.
>
> If a wrapper doesn't set a docstring explicitly, it makes a lot more sense to
> me to re-uses the original function's docstring rather than leave it at None.
>

But this is still a loss of information since you will no longer know
that the decorator had no docstring.

> My real interest is that it should be possible to get at all the details of
> the original function (such as its code object), and the obvious way to do
> that is with a standard attribute that links to the original.
>

Exactly.  __decorates__ would provide this.  Otherwise the last key
piece of information I think missing that decorators cannot copy from
the decorated function is the function parameters, and that is where
my __signature__ object proposal (I think Philip proposed the main
idea originally) steps in if the __decorates__ idea doesn't go
anywhere.

> > though I would go farther and state,
> > like I did at the time, that one shouldn't copy any of the function
> > attributes, they should come 'free', similar to the way that class
> > attributes are 'free' on subclasses.
>
> Well, that's the idea behind the decorator decorator - simply put @decorator
> on your decorator function and it will automatically do the right thing.
>
> > http://mail.python.org/pipermail/python-dev/2004-September/048631.html
> >
> > What would make this _really_ nice is if one didn't need to do anything
> > manually; that the attribute that pointed to the decorated
> > function/object would be automatically applied - though I realize that
> > this may not be generally possible.
>
> A slight problem is that not all decorators will wrap the function they
> decorate - some will only annotate it.
>
> However, here's an idea for the @decorator decorator that would make it pretty
> much automatic, leaves the docstring alone if the decorator has already set it
> on the wrapper, and builds up a record of the decorators that are wrapping the
> the original function:
>
> def _link_decorated(decorated, orig, decorator):
>"""Link a decorated function with the original"""
>decorated.__name__ = orig.__name__
>decorated.__dict__.update(orig.__dict__)
>if decorated.__doc__ is None:
>decorated.__doc__ = orig.__doc__
>decorated.__decorates__ = orig
>decorated.__decorator__ = decorator
>
> def decorator(orig_decorator):
>"""Decorator to create a well-behaved decorator"""
># Wrapper function that links a decorated function
># to the original function if necessary
>def wrapper(f):
>decorated = orig_decorator(f)
>if decorated is not f:
># Link wrapper function to the original
>_link_decorated(decorated, f, wrapper)
>return decorated
>_link_decorated(wrapper, orig_decorator, decorator)
>return wrapper
>
> Decorators that only do annotations aren't recorded because there isn't
> anywhere to record them. Wrapping decorators, on the other hand, allow the
> references to both the decorated function and the applied decorator to be
> stored on the new function object.
>

If you do the copying of data and provide a __signature__ object you
have 90% of the metadata one would want for introspection on a
decorated function, so I don't know if __decorates__ wi

Re: [Python-Dev] dealing with decorators hiding metadata of decorated functions

[Aahz]

On Sun, Mar 19, 2006, Brett Cannon wrote:
>
> I guess we need to decide if we want to promote the copying of
> metadata from the decorated function into the decorator or not.

Short answer: absolutely yes

I had to deal with a related issue recently, where embedded doctests no
longer worked on the decorated function.  There were two separate
problems: the first was non-copying of __doc__, which was easy enough to
fix; the second (which I still haven't fixed) is the fact that __name__
wasn't set, so doctest didn't auto-find the function.  (The decorator
came from a different module.)

(This was Python 2.2/2.3, so decorators weren't actually involved, but I
think it's the same problem.)

I don't understand decorators well enough to propose a good solution
given the other constraints, but it seems clear to me that we need a good
solution of some kind.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
___
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] Py3K timescale and stdlib philosophy (was: Re: Py3K thought: use...)

[Brett Cannon]

On 3/19/06, John J Lee <[EMAIL PROTECTED]> wrote:
> On Fri, 17 Mar 2006, Brett Cannon wrote:
>
> > On 3/17/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> >> Thought: We should drop all of httplib, urllib, urllib2, and ftplib,
> >> and instead adopt some third-party library for HTTP/FTP/whatever,
> >> write a Python wrapper, and use it instead.  (The only such library I
> [...]
> > But maybe this also poses a larger question of where for Py3K we want
> > to take the stdlib.  Ignoring its needed cleanup and nesting of the
> > namespace, do we want to try to use more external tools by importing
> > them and writing a Pythonic wrapper?  Or do we want to not do that and
> > try to keep more things under our control and go with the status quo?
> > Or do we want to really prune down the stdlib and use more dynamic
> > downloading ala Cheeseshop and setuptools?
> [...]
>
> Do we have any idea yet what sort of timescale we're talking about for
> Python 3.0 (or should I call it Py3K still)?
>

Py3K.  It's shorter and since Python 3.0 is still just a PEP and
Guido's neurons it really has not materalized yet to be an upcoming
version of Python yet.  =)

> I have a personal interest in these particular modules, but the questions
> that seem to need answering first are more general ones about the stdlib
> post-3.0.  Brett asks some good questions.
>
> ISTM that another important question must be: What do each of the small
> set of people like yourself (Brett), Andrew, Martin, Georg, Raymond
> (etc.!) who bear most of the burden of maintaining the stdlib at present,
> intend to do after Python 3.0 is out?  I assume that it would only be
> useful to drop parts of the stdlib in this way if that group of people
> were then to stop working on them.  That makes sense, but I don't want to
> make assumptions about what each of the group of people referred to above
> intend to do post-3.0:
>
>   a. Drop 2.x right away to concentrate on developing and maintaining the
>  3.0 stdlib (and/or the 3.0 interpreter)?
>
>   b. Spend at least some effort maintaining 2.x for a few years?
>
>   c. Carry on maintaining 2.x for a few years?
>
>   d. Ignore 3.x and continue with 2.x indefinitely?
>
>   e. Watch and see how the Python community at large responds to 3.0?
>
>   f. Wait and see what you feel like doing at the time?
>
>   g. Some combination of the above?
>
>   h. Quit Python to take up pig farming?
>

Py3K will most likely be just another release of Python with a lot of
changes.  The final 2.x release will be maintained for a while just
because we always maintain the last stable release while the next
version is being developed.  But since the 2.x series will be depended
upon by people for quite a while I suspect we will continue to patch
it and release it as long as Anthony is willing to do micro releases
and developers plan to continue to backport fixes.

Personally, I plan to help to maintain the 2.x series, but once Python
3.0 becomes a reality, it won't be my focus.  One would hope that bugs
in the 2.x series will get closed up over time and will require less
and less maintenance.  But backporting might be a problem from 3.x to
2.x because of fundamental differences of how things are structured on
top of people just losing interest in 2.x since it isn't bleeding
edge.

>
> These sorts of questions are often quite hard to answer, I understand,
> because many people often want to see what everybody else will do before
> making up their minds.  But I guess people who post here frequently are
> less likely to do that than are the rest of us sheep ;-)
>
> [BTW, I assume much of the stdlib will remain essentially the same (if not
> without backwards-incompatibilities), one hopes people will step in to
> backport 3.0 fixes (and perhaps forward-port: I make no judgement about
> which of 2.x and 3.x will have the larger user community in the short or
> long term).  People will presumably be more motivated to do that than
> currently, since I assume many people will not port all (or any) of their
> code to 3.0.]
>

Well, I don't know if the stdlib will stay the same.  It will
definitely get pruned down and cleaned up (wouldn't be shocked if we
have a Great Renaming like the C codebase did way back in the day). 
So I have no clue where the stdlib will go compared to 2.x .

-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] Py3K timescale and stdlib philosophy

[Martin v. Löwis]

John J Lee wrote:
>   a. Drop 2.x right away to concentrate on developing and maintaining the
>  3.0 stdlib (and/or the 3.0 interpreter)?

I expect the same to happen as with all previous releases: the
current and the previous release (say, 3.0 and 2.5) are maintained;
anything older is unmaintained. So when 3.1 is released, 2.x is
dead.

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] Py3K timescale and stdlib philosophy (was: Re: Py3K thought: use...)

[Bill Janssen]

I was sort of hoping that Python would approach Py3K asymptotically... :-).

PEP 328, for instance, talks about Python 2.5, 2.6, 2.7.

Bill
___
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] Expose the array interface in Python 2.5?

[Greg Ewing]

Travis E. Oliphant wrote:

> The purpose of the C-object would be so that all extension writers to 
> Python can rely on a simple but general-purpose description of an array 
> that Numeric has established over the past decade.

I'm not sure that this is the right direction to approach
things from. It might be all right for writers of new
extensions, but there are existing modules (PIL, ctypes, etc.)
that already have their own way of storing data, and it
seems to me it would be easier for the maintainers of
those modules to add a new interface to the existing
data than to rearrange their internal structure to use
this new C-object.

So I still think the standardised interface is more
important and should have a higher priority than the
new object.

Greg
___
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] GeneratorExit inheriting from Exception

[Greg Ewing]

Just van Rossum wrote:
> Greg Ewing wrote:
>
> > Also maybe start issuing warnings whenever you inherit
> > directly from Exception.
> 
> Ugh. I hate it when it's made (virtually) impossible to write code that
> runs warnings-free on both Python X.Y and X.(Y+1).

Yes, that could be a problem. Maybe there could be a
__future__ import which says "I know about the new
exception scheme, trust me when I inherit from
Exception."

Greg
___
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-time shy failure in test_socket_ssl

[Tim Peters]

[Tim Peters]
>> ...
>> test_socket_ssl
>> test test_socket_ssl crashed --
>> exceptions.TypeError: 'NoneType' object is not callable

[Neal Norwitz]
> For closure, I believe this problem was addressed by revs 42842 and
> 42844 to Lib/test/test_importhooks.py.

Amazingly, the same thing popped up 3(!) times today in the 2.4
buildbot slaves (on two Windows boxes, and the "amd64 gentoo 2.4"
box).  I merged those revs to the 2.4 branch.

> If anyone sees spurious failures with the buildbot (one time failures,
> crashes, etc), please report the problems to python-dev.  It would be
> great to see if you can reproduce the results with the same tests that
> failed.  We need to determine if it is architecture specific,
> test-order related, or something else.

One-shot segfaults are still common enough on the Mac box, like the very recent:


___
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] GeneratorExit inheriting from Exception

[Guido van Rossum]

Sigh. Enough already. PEP 352 was chosen to minimize incompatibilities
and maximize gain with minimal changes in the tree. Also note that
Warnings can sometimes be raised and should then treated as errors, so
Warning would have to inherit from Error.

I vote for the status quo in HEAD, except I've got to think more about
the pros and cons of making GeneratorExit as special as
KeyboardInterrupt.

--
--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] GeneratorExit inheriting from Exception

[Greg Ewing]

Giovanni Bajo wrote:

> OTOH, I also understand that people have been told that deriving from 
> Exception
> is the right thing to do forever now.

Have we really being telling them to derive *directly*
from Exception, or just that deriving somehow from
Exception will become mandatory?

For the purpose of minimising bare-except problems,
recommending direct derivation from Exception seems
like a particularly bad idea, whether the exception
hierarchy is changed or not.

Greg
___
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-time shy failure in test_socket_ssl

[Neal Norwitz]

On 3/19/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> > If anyone sees spurious failures with the buildbot (one time failures,
> > crashes, etc), please report the problems to python-dev.  It would be
> > great to see if you can reproduce the results with the same tests that
> > failed.  We need to determine if it is architecture specific,
> > test-order related, or something else.
>
> One-shot segfaults are still common enough on the Mac box, like the very 
> recent:
> 

Most of the recent failures seem to be related to threads.  the most
recent info is below.  There's a lot more in case if it can help
someone debug.  It seems that one thread is in pthread_cond_wait and
another thread is in PyObject_Call.

n
--

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_INVALID_ADDRESS (0x0001) at 0xdbdbdc23

Thread 0:
0   libSystem.B.dylib   0x9002b8a8 semaphore_wait_signal_trap + 8
1   libSystem.B.dylib   0x9003001c pthread_cond_wait + 488
2   python.exe  0x0010a778 PyThread_acquire_lock + 240
(thread_pthread.h:416)
3   python.exe  0x000cdb84 PyEval_RestoreThread + 116 (ceval.c:306)
4   python.exe  0x000e0d58 file_dealloc + 160 (fileobject.c:310)
5   python.exe  0x00030b10 _Py_Dealloc + 68 (object.c:1872)
6   python.exe  0x000a02a4 tupledealloc + 348 (tupleobject.c:168)
7   python.exe  0x00030b10 _Py_Dealloc + 68 (object.c:1872)
8   python.exe  0x000dcb04 call_function + 1912 (ceval.c:3565)
9   python.exe  0x000d681c PyEval_EvalFrame + 34752 (ceval.c:2163)
10  python.exe  0x000dcfe0 fast_function + 464 (ceval.c:3645)
11  python.exe  0x000dccb0 call_function + 2340 (ceval.c:3584)
12  python.exe  0x000d681c PyEval_EvalFrame + 34752
(ceval.c:2163)
13  python.exe  0x000d9680 PyEval_EvalCodeEx + 4480 (ceval.c:2736)
14  python.exe  0x00118114 function_call + 556 (funcobject.c:548)
15  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
16  python.exe  0x000ddd24 ext_do_call + 764 (ceval.c:3840)
17  python.exe  0x000d6b10 PyEval_EvalFrame + 35508 (ceval.c:2203)
18  python.exe  0x000d9680 PyEval_EvalCodeEx + 4480 (ceval.c:2736)
19  python.exe  0x00118114 function_call + 556 (funcobject.c:548)
20  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
21  python.exe  0x000cadd4 instancemethod_call + 736
(classobject.c:2447)
22  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
23  python.exe  0x0005681c slot_tp_call + 112 (typeobject.c:4533)
24  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
25  python.exe  0x000dd90c do_call + 168 (ceval.c:3771)
26  python.exe  0x000dccd0 call_function + 2372 (ceval.c:3586)
27  python.exe  0x000d681c PyEval_EvalFrame + 34752 (ceval.c:2163)
28  python.exe  0x000d9680 PyEval_EvalCodeEx + 4480 (ceval.c:2736)
29  python.exe  0x00118114 function_call + 556 (funcobject.c:548)
30  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
31  python.exe  0x000ddd24 ext_do_call + 764 (ceval.c:3840)
32  python.exe  0x000d6b10 PyEval_EvalFrame + 35508 (ceval.c:2203)
33  python.exe  0x000d9680 PyEval_EvalCodeEx + 4480 (ceval.c:2736)
34  python.exe  0x00118114 function_call + 556 (funcobject.c:548)
35  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
36  python.exe  0x000cadd4 instancemethod_call + 736
(classobject.c:2447)
37  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
38  python.exe  0x0005681c slot_tp_call + 112 (typeobject.c:4533)
39  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
40  python.exe  0x000dd90c do_call + 168 (ceval.c:3771)
41  python.exe  0x000dccd0 call_function + 2372 (ceval.c:3586)
42  python.exe  0x000d681c PyEval_EvalFrame + 34752 (ceval.c:2163)
43  python.exe  0x000d9680 PyEval_EvalCodeEx + 4480 (ceval.c:2736)
44  python.exe  0x00118114 function_call + 556 (funcobject.c:548)
45  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
46  python.exe  0x000ddd24 ext_do_call + 764 (ceval.c:3840)
47  python.exe  0x000d6b10 PyEval_EvalFrame + 35508 (ceval.c:2203)
48  python.exe  0x000d9680 PyEval_EvalCodeEx + 4480 (ceval.c:2736)
49  python.exe  0x00118114 function_call + 556 (funcobject.c:548)
50  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
51  python.exe  0x000cadd4 instancemethod_call + 736
(classobject.c:2447)
52  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
53  python.exe  0x0005681c slot_tp_call + 112 (typeobject.c:4533)
54  python.exe  0x00028e18 PyObject_Call + 96 (abstract.c:1795)
55  python.exe  0x000dd90c do_call + 168 (ceval.c:3771)
56  python.exe 

Re: [Python-Dev] PySet API

[Barry Warsaw]

On Sat, 2006-03-18 at 19:22 -0500, Raymond Hettinger wrote:
> > [Barry Warsaw]
> >> Oh, also, we have a couple of additions to the PySet C API.
> >> I'll work on putting together an SF patch for them over the weekend.
> 
> What are you proposing to add to the PySet API?

PySet_Clear(), PySet_Next(), PySet_Update(), and PySet_AsList().

> I designed an API that was both minimal and complete.  The idea was to 
> provide 
> direct access to fined grained functions and access the rest through the 
> existing abstract API for PyObject and PyNumber as detailed in the Set API 
> docs. 

We use the above functions quite a bit in our embedded app, so we want
them to be as efficient as possible.  They should also be obvious to C
programmers (e.g. using PyNumber_InPlaceSubtract() is much less obvious
than PySet_Clear()).

> I tried out the API to translate  a number of set algorithms and found that 
> the 
> API was easy-to-use and sufficient as-is.  There may be room for variants of 
> the 
> type checking macros, but I would like the rest of the C API to remain as-is 
> unless some compelling deficiency can be shown.  It is easy to expand the API 
> later but almost impossible to take anything back once in the field.

The above mirrors what's available for dict objects, and if you are
using sets for collections of objects, I believe they make the most
sense.

> IOW, if I have I still have a say in the matter, the patch will most likely 
> not 
> be accepted.

Can you explain why the additions above would not be obvious
improvements?

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] GeneratorExit inheriting from Exception

[Guido van Rossum]

On 3/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Have we really being telling them to derive *directly*
> from Exception, or just that deriving somehow from
> Exception will become mandatory?

It doesn't matter. Most code that tries to be a good citizen today
derives its exceptions from Exception.

> For the purpose of minimising bare-except problems,
> recommending direct derivation from Exception seems
> like a particularly bad idea, whether the exception
> hierarchy is changed or not.

Why? With PEP 352 (== HEAD status quo) this works just fine.

I have a problem with using Error as the focal point since so many
exceptions (user-defined or otherwise) aren't errors. Not to mention
the Warnings which sometimes can be raised as Errors (but without
changing their type).

--
--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] Py3k: Except clause syntax

[Guido van Rossum]

On 3/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The comma and "as" have different precedence in your proposed except clause
> than they currently do in the import statement.  I think that can lead to
> confusion.  In particular, if someone is used to
>
> from foo import bar, baz as flurp
>
> I think they might expect that in this try/except statement:
>
> try:
> something()
> except E1, E2 as e
> print "something bad happened"
>
> if E1 is raised, e will not be (re)bound, but if E2 is raised, then it will
> be.  I know Python is not as heavily an operator-oriented language as C or
> Perl, but I think it makes sense to maintain the same relative binding
> precedence between operators in different contexts wherever possible.

This is as good a point as any to explain that 'as' is not an
operator. It's a piece of syntax. It behaves different in each context
where it is used -- because the context determines what it does. The
parallel you suggest simply doesn't make sense: 'as' in the import
context causes a simple renaming, and the name should be different for
each renamed module, of course. But 'as' in an except clause is not a
renaming -- it simply separates the exception "matching pattern" from
the variable that is to receive the exception *value*. Having
different exceptions bind different variables doesn't make sense --
how would the code know which variable to use?

> There seem to be other places where Python is beginning to require parens
> even though they aren't strictly necessary to resolve syntactic ambiguity.

In the style guide only, I hope. The parens that are mandatory in a
few places *are* necessary to resolve ambiguity.

> This might be one of them.

No, the original proposal (which was already in PEP 3000 anyway) is fine.

--
--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] Python 2.5 Schedule

[Guido van Rossum]

On 3/18/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Fri, 2006-03-17 at 23:48 -0800, Neal Norwitz wrote:
>
> > Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
> > real quick, hopefully within a couple of weeks.  If you have any
> > *major* features (particularly implemented in C) that you want to see
> > in 2.5, bring it up now.  I want to strive for feature completeness by
> > alpha 1.  I know we will have some .py modules that won't make it into
> > alpha 1, but they really should make it in by alpha 2 or be deferred
> > to 2.6.
>
> I'd like to get some feedback on my PEP 352 comments, and if there's
> general agreement on the hierarchy I proposed (so far so good :), then
> I'd like to take a crack at implementing them.

-1. See my response in the other thread. The focus on 'Error' is
mistaken, and we have a large body of existing code that derives from
Exception.

--
--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] Python 2.5 Schedule

[Barry Warsaw]

On Sun, 2006-03-19 at 19:45 -0800, Guido van Rossum wrote:

> -1. See my response in the other thread. The focus on 'Error' is
> mistaken, and we have a large body of existing code that derives from
> Exception.

Just to be clear, are you saying -1 only for Python 2.5 or -1 also for
Python 3.0?  If the former, as I mentioned before, that would be fine
with me.  If the latter too, then I won't waste my time following up on
the thread or writing a PEP.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] Py3k: Except clause syntax

[Alex Martelli]

On Mar 19, 2006, at 7:42 PM, Guido van Rossum wrote:
...
>> There seem to be other places where Python is beginning to require  
>> parens
>> even though they aren't strictly necessary to resolve syntactic  
>> ambiguity.
>
> In the style guide only, I hope. The parens that are mandatory in a
> few places *are* necessary to resolve ambiguity.

Technically, I believe the first place where this did not apply was  
list comprehensions, back in 2.2, since (for example) [x, y for y, x  
in whatever] could have been syntactically disambiguated but (quite  
reasonably, IMHO) [(x,y) for y,x in whatever] was mandated instead.


Alex

___
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] Python 3000 Process

[Guido van Rossum]

I see increased activity related to Python 3000. This is great, but
there is some danger involved. Some of the dangers are: overloading
developers; setting unrealistic expectations for what can be
accomplished; scaring the more conservative user community; paralyzing
developers who can't decide whether to wait for Python 3000 or not.

I'd like to address all these issues, but it may be better to first
spend some time on creating a more streamlined process. Perhaps it's
finally time to introduce a separate mailing list? If people agree,
let's call it [EMAIL PROTECTED] For many developers this won't
make much of a difference (since they'll subscribe to both lists), but
it will give people who are only concerned with Python 2.x a way to
opt-out, and perhaps more importantly, it will make it clear whether
any particular proposal is intended for Python 3000 or for Python 2.x.

I don't want to encourage people who are only interested in Python
3000 to opt-out from the 2.5 python-dev list, since Python 3000 is not
being developed in a vacuum. It must be "a better Python" and that
means it is informed to a large extent by recurring issues on
python-dev (and c.l.py!).

The mailing list is only a small part of the new strategy. We need to
start deciding on important meta-issues like:

- What's the timeline? I don't expect to be setting a schedule now and
sticking to it for the next five years. But we owe everybody out there
who is watching some clarity about when Python 3000 can be expected,
and how we plan to get there; there are widely differing estimates of
how long it will take, and I don't want to scare users away or cause
developers to hold their breath waiting for it (some of which I
imagine is happening with Perl 6).

- What's the upgrade path? Do we provide a conversion tool, or a
compatibility mode, or both, or what? Will it be at all possible to
write code that runs in Python 2.x (for large enough values of x) as
well as in 3.0? This also touches upon the issue of parallel releases
of Python 2.x and 3.x. My personal expectation (contrary to what MvL
said recently) is that there will be several 2.x releases issued even
after 3.0 is out; possibly 3.0 and 2.6 may coexist, and 2.7-2.9 may
continue to evolve 2.x while 3.x is maturing. I've seen this used
successfully in Perl (with 4->5) and Apache, and closer to home in
Zope. Again, this is important in the light of how the transition is
perceived in the world outside python-dev.

- Will we do a grand library reform at the same time? Personally I see
that as quite a separate issue; apart from some specific things like
the stdio redesign, we could start the library reform in 2.6, or
post-3.0, depending on how much energy there it.

- What's the implementation strategy? I've started a branch where I
plan to do some weeding out;  but I've already found that the large
amount of legacy code makes the weeding difficult. I may yet decide to
switch to a sandbox model where only new code or carefully modernized
old code is added (this is how Zope 3 was developed).

- What's the procedure for proposing and new features? It may be time
to start a new series of PEPs that focus exclusively on Python 3000.
I'd like to reserve the numbers 3000-3099 for meta-PEPs (e.g.
addressing the above questions) and 3100-3999 for feature PEPs.

Please don't respond with answers to these questions -- each of them
is worth several threads. Instead, ponder them, and respond with a +1
or -1 on the creation of the python-3000 mailing list. We'll start
discussing the issues there -- or here, if the general sense is not to
split the list.

--
--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] Python 2.5 Schedule

[Guido van Rossum]

On 3/19/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-03-19 at 19:45 -0800, Guido van Rossum wrote:
>
> > -1. See my response in the other thread. The focus on 'Error' is
> > mistaken, and we have a large body of existing code that derives from
> > Exception.
>
> Just to be clear, are you saying -1 only for Python 2.5 or -1 also for
> Python 3.0?  If the former, as I mentioned before, that would be fine
> with me.  If the latter too, then I won't waste my time following up on
> the thread or writing a PEP.

I'm -0 for changing this in 3.0; a larger-scale reorganization could
be undertaken but it's not a big priority.

Before you spend more energy on this, I'd like to address the process
for Python 3000, which is too chaotic right now. See my new thread
titled "Python 3000 Process".

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

[Jeremy Hylton]

On 3/15/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Neil Schemenauer wrote:
> > I think it would be a good idea to follow the Plone project and try
> > to encourage new developers by offering assistance to get them up
> > and running.  AFAIK, we've done that for the other bug days but it
> > might help to publish the fact that no prior Python development
> > experience is necessary.
>
> That's right, though I guess it'll be hard to find new core developers.
> Unfortunately, for most people developing _with_ Python is much more fun than
> developing Python.
>
> Settling on Friday, how about the 31st of March?

Sounds good to me.

Jeremy

> If that's okay for the VIPs, I will send out announcements on python-list, the
> non-english newsgroups and lists and ask Tim to place it on the website.
>
> Georg
>
> ___
> 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/jeremy%40alum.mit.edu
>
___
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 2.5 Schedule

[Anthony Baxter]

On Saturday 18 March 2006 18:48, Neal Norwitz wrote:
> Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
> real quick, hopefully within a couple of weeks.  If you have any
> *major* features (particularly implemented in C) that you want to
> see in 2.5, bring it up now.  I want to strive for feature
> completeness by alpha 1.  I know we will have some .py modules that
> won't make it into alpha 1, but they really should make it in by
> alpha 2 or be deferred to 2.6.

+1. We shouldn't be making feature changes once we hit beta. 

I'd still like to push 2.4.3rc1 out in a couple of days time, with 
2.4.3 final next week, and then maybe aim for 2.5a1 a week or two 
later? How does that work for everyone?

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] Py3k: Except clause syntax

[Gareth McCaughan]

On Friday 2006-03-17 05:04, Alex Martelli wrote:

> Hmmm, if we allowed '( as )' for generic expr's we'd make  
> a lot of people pining for 'assignment as an expression' very happy,  
> wouldn't we...?

I hope not. It looks a lot more like a binding construct
than an assigning one. But what about "pattern-matching"?
Currently, you can say

def f((x0,y0), (x1,y1)):
...

but wouldn't if be nice if you could say

def f((x0,y0) as p0, (x1,y1) as p1):
...

and have both the "packed" and "unpacked" forms
available? (Prior art: some functional languages
that let you define a function with multiple
"pattern-matching" clauses have a similar feature.)

-- 
g

___
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 Process

[Christian Tismer]

Guido van Rossum wrote:
...

> Please don't respond with answers to these questions -- each of them
> is worth several threads. Instead, ponder them, and respond with a +1
> or -1 on the creation of the python-3000 mailing list. We'll start
> discussing the issues there -- or here, if the general sense is not to
> split the list.

I think this list has grown already too much activity, so I'd
appreciate a split.

+1  -- chris
___
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 2.5 Schedule

[Fred L. Drake, Jr.]

On Monday 20 March 2006 00:49, Anthony Baxter wrote:
 > I'd still like to push 2.4.3rc1 out in a couple of days time, with
 > 2.4.3 final next week, and then maybe aim for 2.5a1 a week or two
 > later? How does that work for everyone?

I should be fine to build the documentation Wednesday night (US Eastern time).


  -Fred

-- 
Fred L. Drake, Jr.   
___
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