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 f
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.
>
> Al
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 h
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
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.
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
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 Exce
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.
Sys
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 th
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 clau
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* b
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 importan
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 except
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 whe
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
___
P
[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 di
> [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
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 u
[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 upgra
[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
>
[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 e
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 k
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
> i
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 pa
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
sig
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
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 par
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, a
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 (di
[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
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/mail
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 effec
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
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
> KeyboardInte
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 b
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
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 repor
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
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
[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 t
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 litt
"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
[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 no
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 ta
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
> t
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
Un
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).
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 i
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 purpose
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
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
"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
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 wo
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 lis
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
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 inclu
56 matches
Mail list logo
