Okay, I finally found a little time and got roundup installed and operating.
Only major complaint at this point is that the issue messages are
presented in top-post format (argh).
Does anyone know off the top of one's head what to change to put roundup
in bottom-post (chronological) format?
Ezio Melotti wrote:
On 26/04/2011 22.32, Ethan Furman wrote:
Okay, I finally found a little time and got roundup installed and
operating.
Only major complaint at this point is that the issue messages are
presented in top-post format (argh).
Does anyone know off the top of one's head
Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic wrote:
The other day I was surprised to learn this:
nan = float('nan')
nan == nan
False
[nan] == [nan]
True # also True in tuples, dicts, etc.
That one surprises me a bit too: I knew we were using
ide
Ricardo Kirkner wrote:
I'll give you the example I came upon:
I have a TestCase class, which inherits from both Django's TestCase
and from some custom TestCases that act as mixin classes. So I have
something like
class MyTestCase(TestCase, Mixin1, Mixin2):
...
now django's TestCase class in
Victor Stinner wrote:
Le mardi 03 mai 2011 à 16:22 +0200, Nadeem Vawda a écrit :
On Tue, May 3, 2011 at 3:19 PM, victor.stinner
wrote:
+# Issue #10276 - check that inputs of 2 GB are handled correctly.
+# Be aware of issues #1202, #8650, #8651 and #10276
+class ChecksumBigBufferTestCase(unitte
Victor Stinner wrote:
Le mercredi 04 mai 2011 à 15:40 -0700, Ethan Furman a écrit :
Victor Stinner wrote:
Le mardi 03 mai 2011 à 16:22 +0200, Nadeem Vawda a écrit :
On Tue, May 3, 2011 at 3:19 PM, victor.stinner
wrote:
+int_max = 0x7FFF
+with open(TESTFN, "wb+&q
Victor Stinner wrote:
Le jeudi 05 mai 2011 à 05:07 -0700, Ethan Furman a écrit :
>>
... hence the resulting file is one less than 2GB.
Yep, it's 0x7FFF because it's INT_MAX, the biggest value storable in
an int. The zlib module stores the buffer size into an int in
The bytes type in Python 3 does not feel very consistent.
For example:
--> some_var = 'abcdef'
--> some_var
'abcdef'
--> some_var[3]
'd'
--> some_other_var = b'abcdef'
--> some_other_var
b'abcdef'
--> some_other_var[3]
100
On the one hand we have the 'bytes are ascii data' type interface, and
Greg Ewing wrote:
Ethan Furman wrote:
On the one hand we have the 'bytes are ascii data' type interface, and
on the other we have the 'bytes are a list of integers between 0 -
255' interface.
I think the weird part is that there exists a literal for
writing a byte arra
In Python 3 inequality comparisons became forbidden.
--> 123 < [1, 2, 3]
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: int() < list()
However, equality comparisons are still allowed
--> 123 == [1, 2, 3]
False
But you can't mix them (inequality wins)
-
Ethan Furman wrote:
Greg Ewing wrote:
As for
--> some_other_var[3] == b'd'
there ought to be a literal for specifying an integer
using an ascii character, so you could say something like
if some_other_var[3] == c'd':
which would be equivalent to
if some_other_v
Ethan Furman wrote:
[...]
Also posted to Python-Ideas.
~Ethan~
___
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
Martin v. Löwis wrote:
Here's another thought, that perhaps is not backwards-incompatible...
some_var[3] == b'd'
At some point, the bytes class' __eq__ will be called -- is there a
reason why we cannot have
1) a check to see if the bytes instance is length 1
2) a check to see if
i) the othe
Terry Reedy wrote:
On 5/18/2011 2:51 PM, Ethan Furman wrote:
In Python 3 inequality comparisons became forbidden.
--> 123 < [1, 2, 3]
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: int() < list()
However, equality comparisons are sti
Nick Coghlan wrote:
OK, summarising the thread so far from my point of view.
[snip]
To be honest, I don't think there is a lot we can do here except to
further emphasise in the documentation and elsewhere that *bytes is
not a string type* (regardless of any API similarities retained to
ease t
Nick Coghlan wrote:
On Thu, May 19, 2011 at 6:43 PM, Nick Coghlan wrote:
For point 2, I'm personally +0 on the idea of having 1-element bytes
and bytearray objects delegate hashing and comparison operations to
the corresponding integer object. We have the power to make the
obvious code correct
Glyph Lefkowitz wrote:
In fact, I feel like I would want to push in the opposite direction:
don't treat one-byte bytes slices less like integers; I wish I could
more easily treat n-byte sequences _more_ like integers! :). More
protocols have 2-byte or 4-byte network-endian packed integers embe
Guido van Rossum wrote:
On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote:
Proposals to address this include:
- introduce a "character" literal to allow c'a' as an alternative to ord('a')
-1; the result is not a *character* but an integer. I'm personally
favoring using b'a'[0] and possibly h
Thank you all for the responses. Rather than reply to each, I just made
one big summary. :)
Martin v. Löwis wrote:
> Ethan Furman wrote:
>> # constants
>>
>> EOH = b'\r'[0]
>> CHAR = b'
P.J. Eby wrote:
At 01:56 AM 6/14/2011 +, exar...@twistedmatrix.com wrote:
On 12:35 am, ncogh...@gmail.com wrote:
On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby wrote:
You can still do it one at a time:
CHAR, = b'C'
INT, = b'I'
...
etc. I just tried it with Python 3.1 and it works there.
Michael Foord wrote:
On 28/06/2011 17:34, Terry Reedy wrote:
On 6/28/2011 10:48 AM, Michael Foord wrote:
On 28/06/2011 15:36, Terry Reedy wrote:
S = open('myfile.txt').read()
now return a text string in both Py2 and Py3 and a subsequent
'abc' in S
works in both.
Nope, it returns a bytestri
Ethan Furman wrote:
Michael Foord wrote:
On 28/06/2011 17:34, Terry Reedy wrote:
On 6/28/2011 10:48 AM, Michael Foord wrote:
On 28/06/2011 15:36, Terry Reedy wrote:
S = open('myfile.txt').read()
now return a text string in both Py2 and Py3 and a subsequent
'abc' in S
w
smith jack wrote:
i want to install PIL on windows, but failed
Python-Dev is for discussion of developing the next release of Python.
This question should go to python-list, as your last question did.
Good luck.
~Ethan~
___
Python-Dev mailing list
Glenn Linderman wrote:
On 7/20/2011 7:19 AM, Vinay Sajip wrote:
It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which Python to dispatch it to.
Glenn Linderman wrote:
On 7/25/2011 3:43 AM, Antoine Pitrou wrote:
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan wrote:
>
> > If we add EINTR, I don't know if it's better to add it to
> > BlockingIOError or to create a new exception (InterruptError?).
>
> InterruptedError seems like a re
Andrew Bennetts wrote:
Ethan Furman wrote:
[…] or "EINTRError" in my order of preference.
>>
Please not that last one! ;)
Why not, exactly?
Because this is Python, and readability counts. Yes, it does take some
getting used to (I finally stopped typing 'enum
Eli Bendersky wrote:
I like this solution since this issue of documenting
test.support keeps
coming up. Otherwise we can not document test.support,
We already do.
25.6. test.support — Utility functions for tests
is about half of the page that also contains
Barry Warsaw wrote:
On Jul 29, 2011, at 02:07 PM, Eli Bendersky wrote:
I think the unlink&rmtree functions are just a symptom. The real issue here
is - what is the devguide for, and how is it different from Python's
existing documentation? What should go into the official docs, and what
should g
My apologies for posting here first, but I'm not yet confident enough in
my bug searching fu, and duplicates are a pain.
Here's the issue:
from unittest import *
class MyTest(TestCase):
def test_add(self):
self.assertEqual(1,(2-1),"Sample Subraction Test")
if __name__ == '__main__
Michael Foord wrote:
On 3 Aug 2011, at 21:36, Ethan Furman wrote:
My apologies for posting here first, but I'm not yet confident enough in my bug
searching fu, and duplicates are a pain.
Here's the issue:
from unittest import *
That's the bug right there. Just import TestCa
Michael Foord wrote:
On 3 Aug 2011, at 22:58, Ethan Furman wrote:
Michael Foord wrote:
On 3 Aug 2011, at 21:36, Ethan Furman wrote:
My apologies for posting here first, but I'm not yet confident enough in my bug
searching fu, and duplicates are a pain.
Here's the issue:
fro
Barry Warsaw wrote:
On Aug 16, 2011, at 08:32 AM, Nick Coghlan wrote:
Based on this thread, there are actually two options I'd be fine with:
1. Just revert it and leave Py_RETURN_NONE as a special snowflake
2. Properly generalise the incref-and-return idiom via a Py_RETURN macro
Incrementally i
Antoine Pitrou wrote:
Hello,
When reviewing the PEP 3151 implementation (*), Ezio commented that
"FileSystemError" looks a bit strange and that "FilesystemError" would
be a better spelling. What is your opinion?
FileSystemError
___
Python-Dev mailing
Terry Reedy wrote:
PEP-393 provides support of the full Unicode charset (U+-U+10)
an all platforms with a small memory footprint and only O(1) functions.
For Windows users, I believe it will nearly double the memory footprint
if there are any non-BMP chars. On my new machine, I should
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/01/2011 02:54 PM, Antoine Pitrou wrote:
If you look at Wikipedia, it says: “El alfabeto español consta de 27
letras”. The Ñ is separate from the N (and so is it in my
French-Spanish dictionnary). The accented letters, howev
Albert Zeyer wrote:
I was thinking about a persistent Python interpreter system.
python-dev is for developing the next version of Python (3.3 at this
point). Questions like this should go to python-list or python-ideas.
~Ethan~
___
Python-Dev mail
A question came up on StackOverflow about range objects and floating
point numbers. I thought about writing an frange that did for floats
what range does for ints, so started examining the range class. I
noticed it has __le__, __lt__, __eq__, __ne__, __ge__, and __gt__
methods. Some experime
Guido van Rossum wrote:
Also, Ethan, I hope you're familiar with the reason why there is no
range() support for floats currently? (Briefly, things like range(0.0,
0.8, step=0.1) could include or exclude the end point depending on
rounding, which makes for troublesome semantics.)
Good point, tha
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
>>
Follow-up question: since the original range returned lists, and comparisons
do make sense for lists, should the new range also implement them?
What would be the use-case?
The only reason I'm aware of at the moment is to prev
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
Follow-up question: since the original range returned lists, and
comparisons
do make sense for lists, should the new range also implement them?
What would be the use-case?
The only reason
Martin v. Löwis wrote:
Yes, I realize this is because range returned a list in 2.x. However,
aren't __contains__, __getitem__, count, and index implemented in 3.x
range because 2.x range returned lists?
No, they are implemented because they are meaningful, and with an
obvious meaning. "Is 30 i
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing wrote:
..
And I don't like "linspace" either. Something more self
explanatory such as "subdivide" or "interpolate" might
be better.
"Grid" would be nice and short, but may suggest 2-dimentional result.
Whatever word we c
Raymond Hettinger wrote:
On Sep 27, 2011, at 11:24 AM, Ethan Furman wrote:
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing wrote:
..
And I don't like "linspace" either. Something more self
explanatory such as "subdivide" or "interp
Steven D'Aprano wrote:
Alexander Belopolsky wrote:
In addition to Steven's criticisms of numpy.linspace(), I would like a
new function to work with types other than float. It certainly makes
sense to have range-like functionality for fractions and decimal
floats, but also I often find a need t
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 10:11 AM, Alexander Belopolsky wrote:
The name "frange" does not necessarily imply that we have to mimic the
API completely. As long as frange(10.0) and frange(1.0, 10.0) works
as expected while addressing floating point subtleties through
optiona
Steven D'Aprano wrote:
Ethan Furman wrote:
What about the idea of this signature?
frange([start], stop, step=None, count=None)
Then when count is desired, it can be specified, and when step is
sufficient, no change is necessary.
A default of start=0 makes sense for integer range, be
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 11:20 AM, Ethan Furman wrote:
I personally would use the step value far more often than the count
value.
But that's exactly what we don't *want* you to do! Because (unless you
are a numerical wizard) you probably aren't doing the
Guido van Rossum wrote:
But why offer an API that is an attractive nuisance? I don't think
that it is a burden to the user to have to specify "from 0 to 2 inches
in 8 steps" instead of "from 0 to 2 inches in 1/4 inch steps". (And
what if they tried to say "from 0 to 3 1/4 inches in 1/2 inch steps
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 1:21 PM, Ethan Furman wrote:
Guido van Rossum wrote:
But why offer an API that is an attractive nuisance? I don't think
that it is a burden to the user to have to specify "from 0 to 2 inches
in 8 steps" instead of "from 0 to
Tres Seaver wrote:
On 10/21/2011 12:31 PM, Benjamin Peterson wrote:
2011/10/21 Eric V. Smith :
>>>
What's the logic for adding some braces, but removing others?
>>
No braces if everything is a one-liner, otherwise braces
everywhere.
Hmm, PEP 7 doesn't show any example of the one-liner exce
Benjamin Peterson wrote:
2011/11/9 Barry Warsaw :
I think we should have an official pronouncement about Python 2.8, and PEPs
are as official as it gets 'round here. Thus I propose the following. If
there are no objections , I'll commit this taking the next available
number.
Cheers,
-Barry
P
Georg Brandl wrote:
Am 07.12.2011 02:23, schrieb Cameron Simpson:
On 30Nov2011 22:10, Raymond Hettinger wrote:
| When updating the documentation, please don't go overboard with warnings.
| The docs need to be worded affirmatively -- say what a tool does and show how
to use it correctly.
| See
This belongs on python-ideas. Please take it there.
~Ethan~
___
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
Martin,
You seem heavily invested in minidom.
In the near future I will need to parse and rewrite parts of an xml file
created by a third-party program (PrintShopMail, for the curious).
It contains both binary and textual data.
Would you recommend minidom for this purpose? What other purpose
Stephen J. Turnbull wrote:
Matt Joiner writes:
> Readability is the highest concern, and this should be at the
> discretion of the contributor.
That's quite backwards. "Readability" is community property, and has
as much, if not more, to do with common convention as with some
absolute metric
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/05/2012 02:14 PM, Glenn Linderman wrote:
1) the security problem is not in CPython, but rather in web servers
that use dict inappropriately.
Most webapp vulnerabilities are due to their use of Python's cgi module,
which it
Mark Shannon wrote:
I think that CPython should have proper coroutines, rather than add more
bits and pieces to generators in an attempt to make them more like
coroutines.
I have mentioned this before, but this time I have done something about
it :)
I have a working, portable, (asymmetric)
Is there a reason why normal classes can't have their __doc__ strings
rewritten? Creating a do-nothing metaclass seems like overkill for such
a simple operation.
Python 3.2 ... on win32
--> class Test():
... __doc__ = 'am I permanent?'
...
--> Test.__doc__
'am I permanent?'
--> Test.__doc__
Benjamin Peterson wrote:
2012/1/19 Victor Stinner :
http://bugs.python.org/issue12773 :)
The bug is marked as close, whereas the bug exists in Python 3.2 and
has no been closed. The fix must be backported.
It's not a bug; it's a feature.
Where does one draw the line between feature and bug
Guido van Rossum wrote:
> We should not encourage people to write code that works with a certain
> bugfix release but not with the previous bugfix release of the same
> feature release.
Then what's the point of a bug-fix release? If 3.2.1 had broken
threading, wouldn't we fix it in 3.2.2 and en
Stephen J. Turnbull wrote:
Ethan Furman writes:
Where does one draw the line between feature and bug?
Miracle: Works as documented.[2]
[2] Python is pretty miraculous, isn't it?
Yes, indeed it is! :)
~Ethan~
___
Python-Dev mailing
Summary:
Exception Chaining is cool, unless you are writing libraries that want
to transform from Exception X to Exception Y as the the previous
exception context is unnecessary, potentially confusing, and cluttery
(yup, just made that word up!).
For all the gory details, see http://bugs.pyt
Donald Stufft wrote:
Even if a MemoryException is raised I believe that is still a
fundamental change in the documented contract of dictionary API. I don't
believe there is a way to fix this without breaking someones
application. The major differences I see between the two solutions is
that co
Benjamin Peterson wrote:
2012/1/20 Ethan Furman :
Summary:
Exception Chaining is cool, unless you are writing libraries that want to
transform from Exception X to Exception Y as the the previous exception
context is unnecessary, potentially confusing, and cluttery (yup, just made
that word up
Georg Brandl wrote:
Well, the "as" in "raise as" would be very easily overlooked too.
In any case, I don't think the context suppression is the most important
thing about the exception raising, so it doesn't need to stand out...
Good point.
___
Pyth
PEP: XXX
Title: Interpreter support for concurrent programming
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2012
Python-Version: 3.3
Post-History:
Abstract
One of the open issues from PEP
Benjamin Peterson wrote:
2012/1/26 Ethan Furman :
PEP: XXX
Title: Interpreter support for concurrent programming
mm?
Oops!
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2012
Python-Version: 3.3
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be only slightly better.
Speaking for everyone that wants context suppression (using Steven
D'Aprano's words): chained excep
Terry Reedy wrote:
The PEP does not address the issue of whether the new variation of raise
is valid outside of an except block. My memory is that it was not to be
and I think it should not be. One advantage of the 'as' form is that it
is clear that raising the default as something else is inva
Michael Foord wrote:
On 28/01/2012 04:44, Stephen J. Turnbull wrote:
I think it's a bad idea to introduce a feature that's *supposed* to
break (in the sense of "make a break", ie, change the normal pattern)
with every release and then try to avoid breaking (in the sense of
"causing an unexpected
Nick Coghlan wrote:
On Sat, Jan 28, 2012 at 10:33 AM, Ethan Furman wrote:
So the question is:
- should 'raise ... from ...' be legal outside a try block?
- should 'raise ... from None' be legal outside a try block?
Given that it would be quite a bit of work to
Benjamin Peterson wrote:
2012/1/26 Ethan Furman :
PEP: XXX
Congratulations, you are now PEP 409.
Thanks, Benjamin!
So, how do I make changes to it?
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
For those not on the nosy list, here's the latest post
to http://bugs.python.org/issue6210:
---
It looks like agreement is forming around the
raise ... from None
method. It has been mentioned more than once that having the context
saved
Latest addition for PEP 409 has been sent. Text follows:
Language Details
Currently, __context__ and __cause__ start out as None, and then get set
as exceptions occur.
To support 'from None', __context__ will stay as it is, but __cause__
will start out as False, and will chang
uppressing exception context
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2012
Post-History: 30-Aug-2002, 01-Feb-2012
Abstract
One of the open issues from PEP 3134 is suppressing context: currently
t
PEP: 409
Title: Suppressing exception context
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2012
Post-History: 30-Aug-2002, 01-Feb-2012
Abstract
One of the open issues from PEP 3134 is
I'm looking at the docs to make the relevant changes due to PEP 409, and
I'm noticing some problems.
E.g. The PyException_Get|Set_Context|Cause all talk about using NULL to
clear the related attribute, when actually in should be Py_None.
Only PyException_GetCause is directly related to PEP 40
Ethan Furman wrote:
Only PyException_GetCause is directly related to PEP 409 -- should I
only fix that one, and open up a new issue on the tracker for the other
three, or should I fix all four now?
The specific question is now irrelevant (still learning the differences
between the C code and
What an appropriate title since I sent it to the wrong place. :(
~Ethan~
___
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
Guido van Rossum wrote:
Hm... Reading this draft, I like the idea of using "raise X from
None", but I still have one quibble. It seems the from clause sets
__cause__, and __cause__ can indicate three things: (1) print
__cause__ (explicitly set), (2) print __context__ (default), (3) print
neither
Guido van Rossum wrote:
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman wrote:
My apologies for my ignorance, but is the code smell because both False and
None evaluate to bool(False)?
That's part of it, but the other part is that the type of __context__
is now truly dynamic. I often *
Terry Reedy wrote:
> It sounds like you are asking for a special class
> __NoException__(BaseException) to use as the marker.
Guido van Rossum wrote:
So what did you think of Terry Reedy's idea of using a special exception class?
Our table would then look like:
__context__
Tim Delaney wrote:
On 2 February 2012 12:43, Nick Coghlan wrote:
Hmm, after writing up that list, the idea of using "__cause__ is
Ellipsis" (or even "__cause__ is ...")to mean "use __context__
instead" occurs to me. After all, "..." has the right connotations of
"fill this in fro
PEP: 409
Title: Suppressing exception context
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2012
Post-History: 30-Aug-2002, 01-Feb-2012, 03-Feb-2012
Abstract
One of the open issues from PEP
I was looking at the other Open Issues on PEP 3134, think I might try to
resolve them as well, and discovered via testing that they have already
been taken care of.
Is there an established way to get information like that?
I realize that PEPs are partly historical documents, but it would it
m
Glenn Linderman wrote:
On 2/2/2012 2:10 PM, Ethan Furman wrote:
* Use /Ellipsis/ as the default value (the /.../ singleton).
Accepted. There are no other possible values; it cannot be raised as
it is not an acception; it has the connotation of 'fill in the
rest...' as in
Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 9:16 AM, Ethan Furman wrote:
I was looking at the other Open Issues on PEP 3134, think I might try to
resolve them as well, and discovered via testing that they have already been
taken care of.
Is there an established way to get information like that
Guido van Rossum wrote:
Great, PEP 409 is accepted with Ellipsis instead of False!
Awesome. :)
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
Guido van Rossum wrote:
On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman wrote:
Nick Coghlan wrote:
FWIW, I expect the implementation will *allow* "raise exc from
Ellipsis" as an odd synonym for "raise exc".
Are
Nick Coghlan wrote:
FWIW, I expect the implementation will *allow* "raise exc from
Ellipsis" as an odd synonym for "raise exc".
Are we sure we want that? Raising from something not an exception seems
counter-intuitive (None being the obvious exception).
I'd want to allow
"exc.__cause__ =
Tim Delaney wrote:
In that case, would the best syntax be:
raise Exception() from Ellipsis
or:
raise Exception() from ...
? I kinda like the second - it feels more self-descriptive to me than
"from Ellipsis" - but there's the counter-argument that it could look
like noise, and I thi
Yury Selivanov wrote:
Re "raise ValueError from ..."
So what does it mean now? Just resetting __cause__ to make __context__ printed?
Whatever __cause__ was before (None, or an actual exception), it is now
Ellipsis -- so __context__ will be printed and the exception chain will
be followed.
Yury Selivanov wrote:
While the example is valid, I doubt that it is in any sense
"common" case.
No it is a corner case. Another way to spell it is:
try:
try:
raise IndexError()
except:
raise CustomError() from None
except CustomError as e:
# nevermind, let's see t
Barry Warsaw wrote:
raise e from ...
is certainly cute, but not very informative. Triple-dots will be confusing
and difficult to read in documentation and code, and Ellipsis has no logical
connection to the purpose of this PEP. So while I'm +1 on everything else in
the PEP, I'm -1 on this
Yury Selivanov wrote:
I got it, and I think it's fine to use explicit __cause__ reset,
using Ellipsis, or even some __NoException__ special object if
we decide to introduce one.
I'm against allowing 'from ...' syntax.
Well, ... /is/ Ellipsis -- no way to tell them apart by them time this
pa
Yury Selivanov wrote:
On 2012-02-03, at 1:20 PM, Guido van Rossum wrote:
Please. Let's stop this. There is no known use case to ever write
that. We're just not putting specific measures to prevent it. Writing
a = ...
Is likewise cute but not very informative. But it is valid syntax.
Well, r
Good news! PEP 409 has been accepted!
Not so good news: There is no one assigned to Issue 6210 to review the
patches... any volunteers?
http://bugs.python.org/issue6210
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
sk also because I expect CPython
to lead by example.
On another note, will the old format ever be deprecated? Is there a date?
Brett Cannon wrote:
> On Tue, Feb 22, 2011 at 10:43, Ethan Furman wrote:
>
>> Greetings!
>>
>> According to these release notes in Python
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote:
A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.
Even if it was quite fast, I don't think such a function would bring
the same benefits as
Benjamin Peterson wrote:
2012/2/26 Nick Coghlan :
Thanks for writing that up. I'd be amenable if the PEP was clearly
updated to say that ``raise exc from cause`` would change from being
syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise
exc`` (as it is now) to ``_hidden = exc;
1401 - 1500 of 1590 matches
Mail list logo
