Re: [Python-Dev] PY_SSIZE_T_CLEAN

[Martin v. Löwis]

Thomas Heller wrote:
> Then, from only reading the PEP without looking up the sources,
> it is not clear to me what the PY_SIZE_T_CLEAN definition does.

The description says

The conversion codes 's#' and 't#' will output Py_ssize_t
if the macro PY_SSIZE_T_CLEAN is defined before Python.h
is included, and continue to output int if that macro
isn't defined.

which (IMO, of course), specifies precisely what PY_SSIZE_T_CLEAN
does. What information do you find lacking here?

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] Problem with module loading on multi-arch?

[Martin v. Löwis]

Neal Becker wrote:
> x86_64 is multiarch.  That means, we allow both i386 and x86_64 binaries to
> coexits.  Is the proposal that python should not support this?  That would
> be unfortunate.

No. You should install the Python library to the architecture-specific
directory (/usr/lib64/python2.3 for AMD64 and /usr/lib/python2.3 for
x86, I guess). The library destination shouldn't be split into to
locations.

> I suspect is would not be that difficult to correctly support multiarch
> platforms.

If you think you can fix it - go ahead. As I said: I keep applying
patches from people who claim they know how things ought to work,
much without questioning them.

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] All green!

[Martin v. Löwis]

Tim Peters wrote:
> I believe it's possible to fiddle the buildbot master to send email
> when a test run fails, and maybe it's time to start doing that.

I just changed to do that, let's see whether that works.

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

[M.-A. Lemburg]

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

> Including the completed block into the pep would be useful.
> 
> Ronald
> 
> 
>> -- 
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Source  (#1, Mar 17  
>> 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/ 
>> ronaldoussoren%40mac.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/mal%40egenix.com

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 18 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

Re: [Python-Dev] Python 2.5 Schedule

[Josiah Carlson]

"Neal Norwitz" <[EMAIL PROTECTED]> wrote:
> 
> I posted a message to c.l.p about the upcoming alpha 1.
> 
> 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.

(as previously requested August 12, 2005)
(http://mail.python.org/pipermail/python-dev/2005-August/055356.html)
> For 2.5a1...
> 
> Some exposure of _PyLong_AsByteArray() and _PyLong_FromByteArray() to
> Python. There was a discussion about this almost a year ago
> (http://python.org/sf/1023290), and no mechanism (struct format code
> addition, binascii.tolong/fromlong, long.tostring/fromstring, ...)
> actually made it into Python 2.4 .  At this point, I'd be happy to get
> /any/ mechanism, with a preference to struct and/or binascii (I'd put
> them in both, if only because different groups of people people may look
> for them in both places, and people who use one tend to like to use that
> one for as much as possible, and because the code additions in both are
> minor).

Raymond followed up with the following:
(http://mail.python.org/pipermail/python-dev/2005-August/055358.html)

> Assign 1023290 to me and I'll get it done in the next month or so.

It was assigned, but he didn't get around to it at the time.  I can
easily update the patch/test/documentation for struct, but my CPython
abilities are somewhat lacking, and I wouldn't be comfortable writing
two new functions in the binascii module.

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

[Fredrik Lundh]

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.

the xmlplus/xmlcore situation needs to be sorted out.





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

[Nick Coghlan]

Should GeneratorExit inherit from Exception or BaseException?

Currently, a generator that catches Exception and continues on to yield 
another value can't be closed properly (you get a runtime error pointing out 
that the generator ignored GeneratorExit).

The only decent reference I could find to it in the old PEP 348/352 
discussions is Guido writing [1]:

> when GeneratorExit or StopIteration
> reach the outer level of an app, it's a bug like all the others that
> bare 'except:' WANTS to catch.

(at that point in the conversation, I believe bare except was considered the 
equivalent of "except Exception:")

While I agree with what Guido says about GeneratorExit being a bug if it 
reaches the outer level of an app, it seems like a bit of a trap that a 
correctly written generator can't write "except Exception:" without preceding 
it with an "except GeneratorExit:" that reraises the exception. Isn't that 
exactly the idiom we're trying to get rid of for SystemExit and 
KeyboardInterrupt?

Regards,
Nick.

[1] http://mail.python.org/pipermail/python-dev/2005-August/055173.html
-- 
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

Re: [Python-Dev] Merging email 4.0 to Python 2.5 svn trunk

[Barry Warsaw]

On Fri, 2006-03-17 at 09:40 -0500, Barry Warsaw wrote:

> The fix is simple, change 'P' to 'p' in the test, but I want to make
> sure that nobody cares that __import__('email.Parser') now returns an
> object that isn't a module, but acts enough like the original module for
> all intents and purposes.

I think the answer is "no", so I'm going to commit these changes.

-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

[Barry Warsaw]

On Sat, 2006-03-18 at 22:53 +1000, Nick Coghlan wrote:
> Should GeneratorExit inherit from Exception or BaseException?

Actually, this prompts me to write about an issue I have with PEP 352.
I actually don't think it's necessary (yes, I know it's already in the
tree).

What I would much rather is is for StandardError to be renamed Error,
for Exception to remain the base class of the exception hierarchy, and
for KeyboardInterrupt to be moved to inherit directly from Exception.
GeneratorExit, SystemExit, and StopIteration would continue to inherit
from Exception.

The reasoning is this: anything that can be raised is an Exception.  Not
all Exceptions are Errors.  Anything that signals an error condition is
an Error, and anything that signals a warning condition is a Warning.
Thus the basic hierarchy /ought/ to be:

Exception
+- KeyboardInterrupt
+- GeneratorExit
+- SystemExit
+- StopIteration
+- Error
|  +- ImportError
|  +- (etc.)
|
+- Warning
   +- UserWarning
   +- (etc.)

Use defined errors should inherit from Error, not Exception.  With this,
"except Exception" would be a synonym for bare except, while "except
Error" would be the standard idiom for letting non-error exceptions pass
through.

I don't know whether this is possible for Python 2.5, but I think it
should be what we strive for for Py3K, and I do not think BaseException
is at all necessary.

-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

[Georg Brandl]

Barry Warsaw wrote:
> On Sat, 2006-03-18 at 22:53 +1000, Nick Coghlan wrote:
>> Should GeneratorExit inherit from Exception or BaseException?
> 
> Actually, this prompts me to write about an issue I have with PEP 352.
> I actually don't think it's necessary (yes, I know it's already in the
> tree).
> 
> What I would much rather is is for StandardError to be renamed Error,
> for Exception to remain the base class of the exception hierarchy, and
> for KeyboardInterrupt to be moved to inherit directly from Exception.
> GeneratorExit, SystemExit, and StopIteration would continue to inherit
> from Exception.
> 
> The reasoning is this: anything that can be raised is an Exception.  Not
> all Exceptions are Errors.  Anything that signals an error condition is
> an Error, and anything that signals a warning condition is a Warning.
> Thus the basic hierarchy /ought/ to be:
> 
> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> |  +- ImportError
> |  +- (etc.)
> |
> +- Warning
>+- UserWarning
>+- (etc.)

Cool! That's so far the clearest solution. An additional bonus is that except
statements look nicer:

except:# still catches all Exceptions, just like
except Exception:

except Error:  # is what you normally should do

Cheers,
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/archive%40mail-archive.com

Re: [Python-Dev] GeneratorExit inheriting from Exception

[Matthew Fleming]

except Error:  # is what you normally should do+1
This definatley makes more sense and is easier to understand just from glancing at it.Thanks,Matt
___
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

[Samuele Pedroni]

Barry Warsaw wrote:
> On Sat, 2006-03-18 at 22:53 +1000, Nick Coghlan wrote:
> 
>>Should GeneratorExit inherit from Exception or BaseException?
> 
> 
> Actually, this prompts me to write about an issue I have with PEP 352.
> I actually don't think it's necessary (yes, I know it's already in the
> tree).
> 
> What I would much rather is is for StandardError to be renamed Error,
> for Exception to remain the base class of the exception hierarchy, and
> for KeyboardInterrupt to be moved to inherit directly from Exception.
> GeneratorExit, SystemExit, and StopIteration would continue to inherit
> from Exception.
> 
> The reasoning is this: anything that can be raised is an Exception.  Not
> all Exceptions are Errors.  Anything that signals an error condition is
> an Error, and anything that signals a warning condition is a Warning.
> Thus the basic hierarchy /ought/ to be:
> 
> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> |  +- ImportError
> |  +- (etc.)
> |
> +- Warning
>+- UserWarning
>+- (etc.)
> 
> Use defined errors should inherit from Error, not Exception.  With this,
> "except Exception" would be a synonym for bare except, while "except
> Error" would be the standard idiom for letting non-error exceptions pass
> through.
> 
> I don't know whether this is possible for Python 2.5, 

well, one thing to consider is all the

class MyException(Exception):

in current code.


> but I think it
> should be what we strive for for Py3K, and I do not think BaseException
> is at all necessary.
> 
> -Barry
> 
> 
> 
> 
> 
> ___
> 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/pedronis%40strakt.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] GeneratorExit inheriting from Exception

[Barry Warsaw]

On Sat, 2006-03-18 at 16:50 +0100, Samuele Pedroni wrote:

> > I don't know whether this is possible for Python 2.5, 
> 
> well, one thing to consider is all the
> 
> class MyException(Exception):
> 
> in current code.

Yep, which is why I'm not sure we can do this for Py2.5.  However as PEP
352 talks about a transition plan for Py3k, I think we should document
the ultimate desired hierarchy (and maybe implement that in the p3yk
branch ;), and then think about how to transition to it in Py2.5.

One possible approach is to revert BaseException out of Py2.5,
re-position KeyboardInterrupt, and add Error as an alias for
StandardError.  Then we can encourage people to start using Error as the
base classes for their own errors.

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

[Raymond Hettinger]

[Neal]
>I posted a message to c.l.p about the upcoming alpha 1.
>
> 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.

FYI, I have several non-major C components to go in but not in time for alpha 
1. 
They include some minor fix-ups in the sets module, the str.partition function, 
add gc to itertools.tee, a couple of functions in binascii, add 
itertools.izip_longest, Crutcher's patch to make exec take dictionary 
arguments, 
move the peepholer to just before the assembler, and implement Alex's iterator 
copier for a number of iterables (xrange, repeat, count, reversed, list, tuple, 
deque, dict, and set).  All of these have been previously discussed/approved 
and 
should go in to the second alpha.

The only one that is borderline is Crutcher's patch.  I will try to free up 
some 
time to get that into alpha 1.  It touches critical parts of the interpreted 
and 
needs to be reviewed, tested, timed, and exercised thoroughly.


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

[Fernando Perez]

"Martin v. Löwis" wrote:

> M.-A. Lemburg wrote:

>> Do you really think module authors do have a choice given that last
>> sentence ?
> 
> I really do. Most developers will not be confronted with 64-bit systems
> for several years to come. That current hardware supports a 64-bit mode
> is only one aspect: Most operating system installations on such hardware
> will continue to operate in 32-bit mode for quite some time.

I think it's worth pointing out that the above is not true in a fairly
significant market: AMD hardware under Linux.  Just about any AMD chip you
can buy for a desktop these days is 64-bit, and all major linux
distributions have out-of-the box native x86-64 support (via a native build
downloadable as a separate install CD, typically).  So while it may well be
true that most Win32 users who have 64 bit hardware will still be using it
in 32 bit mode, in the Linux world it is /extremely/ common to find native
64 bit users.  If you want confirmation, stop by the scipy list anytime for
any of the recurrent battles being fought on the 64 bit front (often
related to obscure compilation problems with Fortran code).

So I think M.A. is right on the money here with his statement.  Unless you
consider the Linux/64bit camp insignificant.  But if that is the case, it
might be worth putting a big statement in the 2.5 release notes indicating
"there is a good chance, if you use third party extensions and a 64 bit OS,
that this won't work for you".  Which will mean that a fraction of the
scientific userbase (a big, enthusiastic and growing community of python
users) will have to stick to 2.4.

Regards,

f

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

[Christos Georgiou]

I made a plea for help months ago (just checked, and it was Jan 2004! time 
flies like a fruit or something, ref 
http://mail.python.org/pipermail/python-list/2004-January/202704.html ) 
about directions to fix the borken Tix.Grid widget; I had no replies.

I finally found some spare time (too little, though, much work, wife 
expecting etc) and I started work on it, and at the moment it can be added 
in a window and has some functionality, but I need a lot more finding my way 
about using tcl/tk --I have almost zero knowledge of the language.

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



___
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

[Georg Brandl]

[moving to python-dev]

Alex Martelli wrote:
> Georg Brandl <[EMAIL PROTECTED]> wrote:
> 
>> can someone please tell me that this is correct and why:
> 
> IMHO, it is not correct: it is a Python bug (and it would be nice to fix
> it in 2.5).

Fine. Credits go to Michal Kwiatkowski for discovering that in bug #1448042
which I closed out of ignorance ;)

>> >>> class C(object):
>> ... pass
>> ...
>> >>> c = C()
>> >>> c.a = 1
>> >>> c.__dict__
>> {'a': 1}
>> >>> c.__dict__ = {}
>> >>> c.a
>> Traceback (most recent call last):
>>   File "", line 1, in ?
>> AttributeError: 'C' object has no attribute 'a'
> 
> So far so good, I think we agree;-).
Yes.

>> >>> 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.  FWIW, mucking
> around with gc.getreferrers (with a more uniquely identifiable value for
> d.a;-) shows a dictionary "somewhere" with keys 'a' and '__dict__'...

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/archive%40mail-archive.com

Re: [Python-Dev] Python 2.5 Schedule

[Barry Warsaw]

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.

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

[Barry Warsaw]

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.

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.

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

[Scott David Daniels]

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> The former seems fairly pointless, and the latter difficult (since it has 
>> implications for moving the data store when the array gets resized).
> 
> I don't see why that should be a serious problem, as
> long as it's understood that the address reported by
> the array interface is only for temporary use.
> 
> I also don't see what relevance the semantics of
> Python indexing or mutation has. The array interface
> should just report the location and shape of the
> data as it happens to be when the call is made.
> What happens to it in between times is entirely
> up to the object.

But it might be nice to be able to determine if the object has a way
of promising a constant address while a reference is held.  The
array.array implementation could simply say, "nope."  I certainly have
use for implementations that can give better guarantees, and I'd
like to be able to distinguish the two.

--Scott David Daniels
[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] Python 2.5 Schedule

[Giovanni Bajo]

Raymond Hettinger <[EMAIL PROTECTED]> wrote:

> They include [...] the str.partition function,

Where is the current version of this patch?

After reharsing the archives, I have an additional suggestion which I didn't
find already mentioned in the discussion. What about:

str.partition()  ->  (left, right or None)
str.rparition()  ->  (left or None, right)

which means:

"foo:bar".partition(":") -> ("foo", "bar")
"foo:bar".rpartition(":") -> ("foo", "bar")
"foo:".partition(":") -> ("foo", "")
"foo:".rpartition(":") -> ("foo", "")
":foo".partition(":") -> ("", "foo")
":foo".rpartition(":") -> ("", "foo")
"foo".partition(":") -> ("foo", None)
"foo".rpartition(":") -> (None, "foo")

Notice that None-checking can be done as a way to know if the separator was
found. I mentally went through the diff here
(http://mail.python.org/pipermail/python-dev/2005-August/055781.html) and
found out that most (all?) the usages of '_' disappears with this semantic.
-- 
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

Re: [Python-Dev] GeneratorExit inheriting from Exception

[Giovanni Bajo]

Georg Brandl <[EMAIL PROTECTED]> wrote:

>> Exception
>> +- KeyboardInterrupt
>> +- GeneratorExit
>> +- SystemExit
>> +- StopIteration
>> +- Error
>>>  +- ImportError
>>>  +- (etc.)
>>>
>> +- Warning
>>+- UserWarning
>>+- (etc.)
>
> Cool! That's so far the clearest solution. An additional bonus is that
> except
> statements look nicer:
>
> except:# still catches all Exceptions, just like
> except Exception:
>
> except Error:  # is what you normally should do

+1 on the general idea, I just don't specifically like that "except:" is the
"wrong" thing to do: part of the PEP352 idea was that people writing
"except:" out of ignorance would still not cause their program to intercept
KeyboardInterrupt, or StopIteration.

Unless this new proposal also includes changing the meaning of "except:" to
"except Error". Also, under this new proposal, we could even remove
Exception from the builtins namespace in Py3k. It's almost always wrong to
use it, and if you really really need it, it's spelled exceptions.Exception.
-- 
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

Re: [Python-Dev] GeneratorExit inheriting from Exception

[Barry Warsaw]

On Sat, 2006-03-18 at 19:32 +0100, Giovanni Bajo wrote:

> +1 on the general idea, I just don't specifically like that "except:" is the
> "wrong" thing to do: part of the PEP352 idea was that people writing
> "except:" out of ignorance would still not cause their program to intercept
> KeyboardInterrupt, or StopIteration.
> 
> Unless this new proposal also includes changing the meaning of "except:" to
> "except Error". 

It's worth debating.  OT1H, it's a semantic different for Python 2.x
(although +1 on the idea for Py3K).  OTOH, I think people generally want
to just catch errors and not all exceptions.  Going along with that,
maybe the interpreter should do something different when an Exception
that's not an Error reaches the top (e.g. not print a traceback if
KeyboardInterrupt is seen -- we usually just catch that, print
"Interrupted" and exit).

> Also, under this new proposal, we could even remove
> Exception from the builtins namespace in Py3k. It's almost always wrong to
> use it, and if you really really need it, it's spelled exceptions.Exception.

I'm not sure I'd go as far as hiding Exception, since I don't think the
penalty is that great and it makes it easier to document.

-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

[Giovanni Bajo]

Barry Warsaw wrote:

> >Unless this new proposal also includes changing the meaning of
>> "except:" to "except Error".

> It's worth debating.  OT1H, it's a semantic different for Python 2.x
> (although +1 on the idea for Py3K).

I was speaking of Py3K here, yes.

> Going along with that, maybe the interpreter should do something
> different when an Exception that's not an Error reaches the top
> (e.g. not print a traceback if KeyboardInterrupt is seen -- 
> we usually just catch that, print "Interrupted" and exit).

SystemExit is already special-cased, as far as I can tell. KeyboardInterrupt
could be in fact be special cased as well (I saw many Python newbies -- but
otherwise experienced -- being disgusted at first when they interrupt their
code with CTRL+C: they expect the program to exit "almost silently").

>> Also, under this new proposal, we could even remove
>> Exception from the builtins namespace in Py3k. It's almost
>> always wrong to use it, and if you really really need it, it's
>> spelled exceptions.Exception.

> I'm not sure I'd go as far as hiding Exception, since I don't think the
> penalty is that great and it makes it easier to document.

The situation (in Py3k) I was thinking is when people see this code:

except:
# something

and want to change it so to get a name to the exception object. I *think* many
could get confused and write:

except Exception, e:
# something

which changes the meaning. It "sounds" correct, but it's wrong. Of course, it's
easy to argue that "Exception" is just that, and people actually meant "Error".
In a way, the current PEP352 is superior here because it makes harder to do the
"bad" thing by giving it a complex name (BaseException).

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] Two buildbot slaves wedged

[Tim Peters]

svn got confused trying to incorporate updates to the email pkg.  Slaves

sparc solaris10 gcc trunk
and
x86 gentoo trunk

got stuck in their trunk "updating" steps for 7 hours, presumably as a result.

I killed those builds, and tried to start new builds on those slaves. 
There was no effect apart from their "pending" count rising from 6 to
7.  They respond to pings, but won't start another build.

I'm not sure how they get into such a state (but saw it at Zope Corp
at times too).  It's possible that their buildbot processes need to be
restarted, and/or that the master process needs to be restarted.
___
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

[Wolfgang Langner]

Hello,

what about:

try:
  something
except NameError or OtherError as e:


Only a thought.

--
bye by Wolfgang
___
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

[Raymond Hettinger]

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


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] Python Library Reference top page too long

[Aahz]

On Fri, Mar 17, 2006, Georg Brandl wrote:
> Greg Ewing wrote:
>> Russell E. Owen wrote:
>>> 
>>> Another thing that would be *really* useful is to list the actual 
>>> built-in types with the category. For example:
>>> Sequence Types (str, unicode, list, tuple, buffer, xrange)
>>> Mapping Types (dict)
>> 
>> +1
> 
> If I understand correctly what you mean, that's already done.

Partially, by my standard.  That is, the names of the types are now
listed, but you still have to drill down two layers to get to the string
methods.
-- 
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] Two buildbot slaves wedged

[Neal Norwitz]

On 3/18/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> svn got confused trying to incorporate updates to the email pkg.  Slaves
>
> sparc solaris10 gcc trunk
> and
> x86 gentoo trunk
>
> got stuck in their trunk "updating" steps for 7 hours, presumably as a result.
>
> I killed those builds, and tried to start new builds on those slaves.
> There was no effect apart from their "pending" count rising from 6 to
> 7.  They respond to pings, but won't start another build.

I've seen this happen a few times.  It seems the only way to fix this
is to restart the master which I did.  After the restart, all the
pending changes are lost, so I forced a rebuild on both machines.

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

[Martin v. Löwis]

Fernando Perez wrote:
> So I think M.A. is right on the money here with his statement.  Unless you
> consider the Linux/64bit camp insignificant.  But if that is the case, it
> might be worth putting a big statement in the 2.5 release notes indicating
> "there is a good chance, if you use third party extensions and a 64 bit OS,
> that this won't work for you".  Which will mean that a fraction of the
> scientific userbase (a big, enthusiastic and growing community of python
> users) will have to stick to 2.4.

It's more intricate than that. If certain extensions are of interest to
the scientific community, I certainly expect the authors of them to fix
them.

However, to "fix" the extension can still be done in different levels:
you can easily fix it to not crash, by just honoring all compiler
warnings that gcc produces. That doesn't mean you fully support
Py_ssize_t, since you might not support collections with more than
2**31 elements. In these cases, the extension will not crash, but it
will compute incorrect results if you ever encounter such a collection.
Even on all these AMD64 Linux machines, this is still fairly unlikely,
since you need considerably more than 16GiB main memory to do something
useful on such collections - very few machines have that much memory
today. Again, people that have such machines and need to run Python
programs with that many data need to make sure that the extensions
work for them. Sticking with 2.4 is no option for these people, since
2.4 doesn't support such large collections, anyway.

To really fix such extensions, I recommend building with either
Microsoft C or Intel C. The Microsoft compiler is available free
of charge, but runs on Windows only. It gives good warnings, and
if you fix them all (in a careful way), your code should fully
support 64 bits. Likewise for the Intel compiler: it is available
for free only for a month, but it runs on Linux as well.

OTOH, I'm still doubtful how many extensions will be really affected
by the change in the first place. Your code *breaks* with the change
only if you implement the sequence or buffer protocols. I'm doubtful
that this is an issue for most applications, since many extensions
(I believe) work without implementing these protocols.

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] Patch or feature? Tix.Grid working for 2.5

[Martin v. Löwis]

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

I wouldn't object to including it before beta 1.

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] Two buildbot slaves wedged

[Martin v. Löwis]

Tim Peters wrote:
> I'm not sure how they get into such a state (but saw it at Zope Corp
> at times too).  It's possible that their buildbot processes need to be
> restarted, and/or that the master process needs to be restarted.

It's a buildbot 0.7.1 bug (according to the 0.7.2 changelog); the
sighup command sometimes gets confused. I thought it would survive
the configuration change when no build is ongoing, but apparently
I was wrong.

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] Patch or feature? Tix.Grid working for 2.5

[Neal Norwitz]

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...
>
> I wouldn't object to including it before beta 1.

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.

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

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

[Neal Norwitz]

On 3/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> FYI, I have several non-major C components to go in but not in time for alpha 
> 1.
> They include some minor fix-ups in the sets module, the str.partition 
> function,
> add gc to itertools.tee, a couple of functions in binascii, add
> itertools.izip_longest, Crutcher's patch to make exec take dictionary 
> arguments,
> move the peepholer to just before the assembler, and implement Alex's iterator
> copier for a number of iterables (xrange, repeat, count, reversed, list, 
> tuple,
> deque, dict, and set).  All of these have been previously discussed/approved 
> and
> should go in to the second alpha.
>
> The only one that is borderline is Crutcher's patch.  I will try to free up 
> some
> time to get that into alpha 1.  It touches critical parts of the interpreted 
> and
> needs to be reviewed, tested, timed, and exercised thoroughly.

All those seem reasonable.  Do the functions you mention address Josiah's patch?

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

[Brett Cannon]

On 3/18/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-03-18 at 22:53 +1000, Nick Coghlan wrote:
> > Should GeneratorExit inherit from Exception or BaseException?
>
> Actually, this prompts me to write about an issue I have with PEP 352.
> I actually don't think it's necessary (yes, I know it's already in the
> tree).
>

Much to personal pain and sprint time.  Are you trying to make me shed
a manly tear, Barry?!?  =)

> What I would much rather is is for StandardError to be renamed Error,
> for Exception to remain the base class of the exception hierarchy, and
> for KeyboardInterrupt to be moved to inherit directly from Exception.
> GeneratorExit, SystemExit, and StopIteration would continue to inherit
> from Exception.
>

So it isn't that PEP 352 is unnecessary since there is nothing here
about deprecating string execptions and making built-in exceptions
new-style.  You just want to change the renaming of the exceptions.

> The reasoning is this: anything that can be raised is an Exception.  Not
> all Exceptions are Errors.  Anything that signals an error condition is
> an Error, and anything that signals a warning condition is a Warning.
> Thus the basic hierarchy /ought/ to be:
>
> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> |  +- ImportError
> |  +- (etc.)
> |
> +- Warning
>+- UserWarning
>+- (etc.)
>
> Use defined errors should inherit from Error, not Exception.  With this,
> "except Exception" would be a synonym for bare except, while "except
> Error" would be the standard idiom for letting non-error exceptions pass
> through.
>

I still like my idea of a ControlFlowException, but that died with PEP
348 (along with part of my innocence).

> I don't know whether this is possible for Python 2.5, but I think it
> should be what we strive for for Py3K, and I do not think BaseException
> is at all necessary.
>

I view PEP 352 as the PEP that fixed an issue with overreaching
'except' clauses, officially getting us off of string exceptions, and
making built-in exceptions new-style classes.  I do not view it as the
be-all-end-all hierarchy for Py3K.

With that said, I am not changing the PEP.  Another PEP that suggests
the hierarchy for Py3K can be suggested, but I am not doing it.  I am
totally burned out on exceptions after two PEPs on the subject matter.

Just remember that PEP 348 was meant for Py3K when we are supposed to
break stuff and how much resistence I hit.  Granted my changes were
more radical, but even in the end, small changes were resisted
heavily.  In other words, make sure you have the time and energy to
take this on.  =)

But the above suggestions seem reasonable, especially if bare 'except'
statements go away.  So I am supportive of the idea.

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

[Raymond Hettinger]

[Raymond]
> FYI, I have several non-major C components to go in but not in time for alpha 
> 1.
> They include some minor fix-ups in the sets module, the str.partition 
> function,
> add gc to itertools.tee, a couple of functions in binascii, add
> itertools.izip_longest, Crutcher's patch to make exec take dictionary 
> arguments,
> move the peepholer to just before the assembler, and implement Alex's iterator
> copier for a number of iterables (xrange, repeat, count, reversed, list, 
> tuple,
> deque, dict, and set).  All of these have been previously discussed/approved 
> and
> should go in to the second alpha.
>
> The only one that is borderline is Crutcher's patch.  I will try to free up 
> some
> time to get that into alpha 1.  It touches critical parts of the interpreted 
> and
> needs to be reviewed, tested, timed, and exercised thoroughly.

[Neal]
> All those seem reasonable.  Do the functions you mention address Josiah's 
> patch?

I believe so.  They are binascii.b2long() and binascii.long2b().
And, no, the name of the latter wasn't taken from a song ;-)


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

[Python-Dev] pyexpat namespace problem (Was: libbzip2 version?)

[Trent Mick]

[Georg Brandl wrote]
> There seems to be a new version of expat too: http://python.org/sf/1433435
> 
> The namespace problem with pyexpat persists: http://python.org/sf/1295808

http://python.org/sf/1295808

[My lastest comment to that bug]
> As Neal points out this is a duplicate of
> . The patch on *that* bug
> fixes the specific issue, but does not solve the general
> problem (as Michael, 'mwh', pointed out in the comments
> there).
> 
> I think we should 
> 1. apply this patch
> 2. then perhaps update our expat version (see
>http://python.org/sf/1433435,
>http://mail.python.org/pipermail/python-dev/2006-March/062287.html),
> 3. then update Modules/expat/pyexpatns.h (that this patch
>adds) for any new symbols in the new version of Expat.

I'm testing my patch to the trunk right now to make sure it passes
everything. If you all think this is a good idea I could apply it and
then also give a go an upgrading out expat version (I haven't looked at
whether that would be very difficult).

Cheers,
Trent

-- 
Trent Mick
[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] pyexpat namespace problem (Was: libbzip2 version?)

[Trent Mick]

[Trent Mick wrote]
> I'm testing my patch to the trunk right now to make sure it passes
> everything. If you all think this is a good idea I could apply it and
> then also give a go an upgrading out expat version (I haven't looked at
> whether that would be very difficult).

"give a go at upgrading our (i.e. Python's) expat version"

Trent

-- 
Trent Mick
[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] pyexpat namespace problem (Was: libbzip2 version?)

[Martin v. Löwis]

Trent Mick wrote:
> I'm testing my patch to the trunk right now to make sure it passes
> everything. If you all think this is a good idea I could apply it and
> then also give a go an upgrading out expat version (I haven't looked at
> whether that would be very difficult).

I would like to see an update to the current Expat release before that.

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] PySet API

[Raymond Hettinger]

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

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

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


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] pyexpat namespace problem (Was: libbzip2 version?)

[Trent Mick]

[Martin v. Loewis wrote]
> Trent Mick wrote:
> > I'm testing my patch to the trunk right now to make sure it passes
> > everything. If you all think this is a good idea I could apply it and
> > then also give a go an upgrading out expat version (I haven't looked at
> > whether that would be very difficult).
> 
> I would like to see an update to the current Expat release before that.

Okay. I'll see if I can try that tomorrow.

Trent

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

[Greg Ewing]

Barry Warsaw wrote:
> On Sat, 2006-03-18 at 19:32 +0100, Giovanni Bajo wrote:

>>Unless this new proposal also includes changing the meaning of "except:" to
>>"except Error". 

Then maybe it should be called "error:" rather
than "except:". :-)

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]

Barry Warsaw wrote:

> One possible approach is to revert BaseException out of Py2.5,
> re-position KeyboardInterrupt, and add Error as an alias for
> StandardError.  Then we can encourage people to start using Error as the
> base classes for their own errors.

Also maybe start issuing warnings whenever you inherit
directly 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] GeneratorExit inheriting from Exception

[Greg Ewing]

Barry Warsaw wrote:

> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> |  +- ImportError
> |  +- (etc.)
> |
> +- Warning
>+- UserWarning
>+- (etc.)

+42! This is beautifully clear and simple, especially
compared to some of the other exception hierarchy
reorganisations that have been proposed.

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

[Greg Ewing]

Nick Coghlan wrote:

> So, as a somewhat novel approach, what about putting the "as" *before* the 
> list of exceptions types?

-1. When you're scanning down a series of except
clauses, what you're looking for foremost is the
types of exceptions being caught. The bound name
is of secondary importance and only relevant to
the code in the except clause.

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

[Greg Ewing]

Wolfgang Langner wrote:

> try:
>   something
> except NameError or OtherError as e:

I don't see that this really helps anything,
since it's no clearer how "or" and "as" should
bind than it is how "," and "as" should bind.

Also it has the disadvantage that

   except E1 or E2 as e:

would *not* be equivalent to

   except (E1 or E2) as e:

On the other hand, in

   except E1, E2 as e:

the E1, E2 is just a tuple expression, so it's
exactly equivalent to

   except (E1, E2) as e:

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]

Giovanni Bajo wrote:

> The situation (in Py3k) I was thinking is when people see this code:
> 
> except:
> # something
> 
> and want to change it so to get a name to the exception object. I *think* many
> could get confused and write:
> 
> except Exception, e:
> # something

If except clauses are changed to use "as", then
as long as we're still allowing bare excepts, that
could become

   except as e:
 ...

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

[Greg Ewing]

Things are getting a bit confusing, because it seems
that there are two different things being discussed
here:

(1) A C-level array interface that's a generalisation
 of the buffer interface.

(2) A new multi-dimensional array object type which
 happens to implement (1).

As I understand the proposals, the important thing for
interoperability between different types is to have
(1). Whereas (2) would be useful to have, it's not
a prerequisite for (1).

Do I understand correctly?

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

[Terry Reedy]

Exception
+- KeyboardInterrupt
+- GeneratorExit
+- SystemExit
+- StopIteration

This would look even better to me and be easier to learn and remember if 
the above specifics were gathered under one general category parallel to 
Error and Warning.  Not sure what.  Not NonErrorNonWarning though. 
SystemException is too long and too specific.  Maybe Control?

No, I don't have a specific use other than didactic, but that is worth 
something, and I can imagine that someone else might.

+- Error
|  +- ImportError
|  +- (etc.)
|
+- Warning
   +- UserWarning
   +- (etc.)

Otherwise, looks good to me.

Terry Jan Reedy




___
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

[Nick Coghlan]

Barry Warsaw wrote:
> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> |  +- ImportError
> |  +- (etc.)
> |
> +- Warning
>+- UserWarning
>+- (etc.)
> 
> Use defined errors should inherit from Error, not Exception.  With this,
> "except Exception" would be a synonym for bare except, while "except
> Error" would be the standard idiom for letting non-error exceptions pass
> through.
> 
> I don't know whether this is possible for Python 2.5, but I think it
> should be what we strive for for Py3K, and I do not think BaseException
> is at all necessary.

The main problems I have with the idea are the fact that a large fraction of 
the user-defined exceptions out there already inherit from Exception (and this 
has been pushed for a long time as the right thing to do) and the fact that 
"except Exception:" has also been pushed for years as the preferred 
alternative to a bare "except:".

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 also agree with the point made during the PEP 348/352 discussions that 
StopIteration reaching any except clause that isn't specifically expecting it 
*is* an error. Direct calls to an iterator's next method need to expect the 
StopIteration and decide how to handle it - not handling it is a bug.

For KeyboardInterrupt/SystemExit/GeneratorExit, it is clear that the standard 
behaviour should be to reraise them - the entire point of those exceptions is 
to shut down an entire call stack. StopIteration, on the other hand, merely 
indicates that a particular iterator has completed, not that the entire stack 
of iterators should be shut down.

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

Re: [Python-Dev] Expose the array interface in Python 2.5?

[Nick Coghlan]

Greg Ewing wrote:
> Things are getting a bit confusing, because it seems
> that there are two different things being discussed
> here:
> 
> (1) A C-level array interface that's a generalisation
> of the buffer interface.
> 
> (2) A new multi-dimensional array object type which
> happens to implement (1).
> 
> As I understand the proposals, the important thing for
> interoperability between different types is to have
> (1). Whereas (2) would be useful to have, it's not
> a prerequisite for (1).
> 
> Do I understand correctly?

That sounds right to me. Although option 2 is more a matter of "have an 
exemplar of the interface in the standard library that can be used by 
inheritance or containment".

The interface is actually already defined by numpy - Option 1 would involve 
transferring that info to a PEP on python.org without necessarily providing 
any examples of the interface in the standard library. This pushes more work 
onto those wishing to support the interface (since they will need to either 
implement the interface independently or become dependent on another library 
such as numpy).

Option 2 would involve either modifying array.array to expose the interface, 
or adding a new type, array.dimarray, that allowed such structures to be 
accessed, but not necessarily easily manipulated.

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

Re: [Python-Dev] GeneratorExit inheriting from Exception

[Nick Coghlan]

Terry Reedy wrote:
> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> 
> This would look even better to me and be easier to learn and remember if 
> the above specifics were gathered under one general category parallel to 
> Error and Warning.  Not sure what.  Not NonErrorNonWarning though. 
> SystemException is too long and too specific.  Maybe Control?
> 
> No, I don't have a specific use other than didactic, but that is worth 
> something, and I can imagine that someone else might.

I'd vote for ControlFlowException if StopIteration is included in the 
category, and TerminatingException if it isn't.

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

Re: [Python-Dev] Py3k: Except clause syntax

[skip]

Greg> On the other hand, in

Greg>except E1, E2 as e:

Greg> the E1, E2 is just a tuple expression, so it's
Greg> exactly equivalent to

Greg>except (E1, E2) as e:

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.

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

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

[Travis E. Oliphant]

Paul Moore wrote:
> On 3/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> 
>> Travis E. Oliphant wrote:
>>> Would it be possible to add at least the C-struct array interface to the
>>> Python arrayobject in time for Python 2.5?
>> I'm very much for that.
>>
>>> Is someone on this list willing to help make it happen?
>> Unfortunately not me - I'm too busy with ctypes, and if the array interface
>> makes it into the core I will have to implement/use that in ctypes too.

The ctypes interface is also another reason I really want a basic array 
interface into the core.

As the very clever people on this list noticed, I was actually asking 
two different things because I was really looking for support from 
people who wanted either one...

What I would really like to see is a very-simple C-object defined 
(perhaps not even exposed to the Python user but only the 
extension-module writer).

This C-object would have the structure of NumPy arrays, be inheritable, 
and define an __array_struct__ method (notice I'm not even asking at 
this point for a new function-pointer table like the buffer protocol has 
--- although I think at some point that could be useful and maybe it is 
even better right now to push for that).

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.

This C-object already has been somewhat fleshed out and the only real 
work would be to add support for it on other objects.

> If all that is required is a simple C definition added to the Python
> code, then it seems to me that would be (a) fairly easy, but (b)
> pretty useless (on the basis that a standards-style PEP like the DB
> API ones would do much the same, without any code changes).

I think I would like to see a real object that can be inherited from (at 
least in C extension modules).  Again perhaps in Python 2.5, this object 
is not even intentionally exposed to the Python level.

> 
> On the third hand, the PEP referenced from the page you quote (at
> http://svn.scipy.org/svn/PEP/PEP_genarray.txt) seems to specify an
> implementation - are you just asking for that to be added to the core?
> If so, why not submit this as a formal PEP, and see what happens from
> there? (For this route, one of the Numeric people *needs* to champion
> the PEP, IMHO, as only they are qualified to address any points that
> get raised in general discussion).
>

The big problem is the release schedule of Python 2.5,  I've really 
wanted to get "something" along these lines going for Python 2.5, but 
I've not had the time to finish the PEP.  So, perhaps I'll tone down the 
request to a simple C-object with even less defined and put that out.

Frankly, I'm really looking for help from an avid Python-dev person who
may have an interest but perhaps not much experience with arrays.

-Travis


___
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

[Just van Rossum]

Greg Ewing wrote:

> Barry Warsaw wrote:
> 
> > One possible approach is to revert BaseException out of Py2.5,
> > re-position KeyboardInterrupt, and add Error as an alias for
> > StandardError.  Then we can encourage people to start using Error
> > as the base classes for their own errors.
> 
> 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).

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

[Nick Coghlan]

Just van Rossum wrote:
> Greg Ewing wrote:
> 
>> Barry Warsaw wrote:
>>
>>> One possible approach is to revert BaseException out of Py2.5,
>>> re-position KeyboardInterrupt, and add Error as an alias for
>>> StandardError.  Then we can encourage people to start using Error
>>> as the base classes for their own errors.
>> 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).

This was one of the key things that led to the approach in PEP 352. Barry's 
hierarchy is very similar to some of the suggestions made during the PEP 348 
discussion, and they were rejected because they made the transition a hell of 
a lot harder without any concomitant benefit. I know this because I was one of 
the people making those suggestions.

With PEP 352 (tweaked to move GeneratorExit out from under Exception):
   - "except:" continues to mean catch everything
   - "except Exception:" now does the right thing
   - inheriting from Exception continues to be correct for user exceptions
   - errors may choose to inherit from one of the existing Errors instead

With Barry's proposed hierarchy:
   - "except:" continues to mean catch everything
   - "except Exception:" continues to do the wrong thing
   - all code has to change to do "except Error:" instead
   - inheriting from Exception becomes incorrect for user exceptions
   - all code has to change to inherit from Error instead
   - non-error user exceptions (such as completion of a search using nested
 loops) have no clear parent to inherit from (both Error and Exception
 are wrong, albeit for different reasons.

The additional pain required in order to have 'Exception' at the root of the 
hierarchy just isn't worth it.

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