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
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
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
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
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
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
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
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.
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
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).
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
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 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
[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
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:
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
[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
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
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
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
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,
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
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
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
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
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:
[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
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
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
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
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
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
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
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
[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
[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
[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
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
[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
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
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
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
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
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
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.
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
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
Greg On the other hand, in
Gregexcept E1, E2 as e:
Greg the E1, E2 is just a tuple expression, so it's
Greg exactly equivalent to
Gregexcept (E1, E2) as e:
The comma and as have different precedence in your proposed except clause
than they currently do in the
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
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
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
51 matches
Mail list logo
