Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +stoneleaf
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python-bugs-list
Ethan Furman et...@stoneleaf.us added the comment:
I like MRAB's suggestion best:
MRAB wrote:
Suggestion: an explicit 'raise' in the exception handler excludes the
context, but if you want to include it then 'raise with'. For example:
# Exclude the context
try:
command_dict[command
Ethan Furman et...@stoneleaf.us added the comment:
There is already support for this in the traceback module (see the
chain parameter to various funcs).
I'm not sure how that's going to help as I don't want my library code to be
responsible for printing out exceptions, I just want them
Ethan Furman et...@stoneleaf.us added the comment:
Besides, if you are writing library code (as opposed to application
code), you shouldn't care at all how tracebacks are displayed, should
you?
I care when it lies:
During handling of the above exception, another exception occurred
Ethan Furman et...@stoneleaf.us added the comment:
During handling of the above exception, another exception occurred:
This is a blatant falsehood -- another exception did not occur, a
different exception was raised.
This doesn't make any difference in any other context, so why would
Ethan Furman et...@stoneleaf.us added the comment:
And what if the exception is raised from a subroutine?
Well, if I have it surrounded by a try/except block, presumably I'm aware that
an exception could be raised. ;)
And if I'm aware that an exception could be raised, it may also
Ethan Furman et...@stoneleaf.us added the comment:
I'm talking about the exception raised from the except block.
So was I -- why should this:
try:
x = y / z
except ZeroDivisionError as exc:
raise InvalidInput()
be different from this:
try:
x = divide_and_conquer(y, z)
except
Ethan Furman et...@stoneleaf.us added the comment:
I said the *except* block, not the *try* block ;)
Ah. So you did.
Okay, if I'm understanding correctly, the scenario you are talking about
involves the code in the except block calling some other function, and that
other function
Changes by Ethan Furman et...@stoneleaf.us:
--
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python
Ethan Furman et...@stoneleaf.us added the comment:
raise AttributeError from None
makes sense to me, and in a nice, short example like that I prefer it.
In real code, however, I think
raise AttributeError.no_context(Field %s is not in table % attr)
is going to be easier for the human
New submission from Ethan Furman et...@stoneleaf.us:
It currently states Note that nested scopes work only for reference and not
for assignment which will always write to the innermost scope.
This should be updated to read, e.g. Note that unless the new nonlocal keyword
is used nested scopes
Ethan Furman et...@stoneleaf.us added the comment:
Okay, I like Matthew Barnett's idea of
except SomeError [as e]:
raise as SomeOtherError('...')
This would require a change to the grammer as well, yes? From:
raise_stmt: 'raise' [test ['from' test]]
to
raise_stmt
Ethan Furman et...@stoneleaf.us added the comment:
Okay, here is a patch implementing the 'raise ... from None' method.
All critiques appreciated (especially if they include links to learn from!).
--
keywords: +patch
Added file: http://bugs.python.org/file24332/raise_from_none.diff
Ethan Furman et...@stoneleaf.us added the comment:
I went with
raise ... from None
instead of
raise as ...
because there seemed to me more support for 'from None' on python-dev, possible
confusion with 'raise as', and 'from None' follows the existing systax of
raise SomeError
Ethan Furman et...@stoneleaf.us added the comment:
1. Any syntax change requires a PEP (and, IMO, any such PEP for this issue
should get rejected: I don't consider this an important enough feature to
deserve dedicated syntax. Others disagree, which is one of the reasons why a
PEP
Ethan Furman et...@stoneleaf.us added the comment:
Nick Coghlan wrote:
1. Any syntax change requires a PEP
PEP is on python-dev.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
Ethan Furman et...@stoneleaf.us added the comment:
It looks like agreement is forming around the
raise ... from None
method. It has been mentioned more than once that having the context saved on
the exception would be a Good Thing, and for further debugging (or logging or
what-have-you
Ethan Furman et...@stoneleaf.us added the comment:
Current semantics (before patch):
cause is not None -- cause is set, display it instead of context
cause is None -- no cause, try to display context
context is not None -- no context
context is None -- context set, display it (unless cause
Ethan Furman et...@stoneleaf.us added the comment:
Patrick: The value in this enhancement is in not displaying the chained
exception. I do not see any value in throwing it away completely. If you
don't care about __context__ you can safely ignore it. On the other hand, if
it is completely
Ethan Furman et...@stoneleaf.us added the comment:
Not sure I have traceback._iter_chain() patched correctly, but all the tests
pass.
Here's the latest code.
--
Added file: http://bugs.python.org/file24362/raise_from_none_v3.diff
___
Python tracker
Ethan Furman et...@stoneleaf.us added the comment:
Attached patch now includes doc changes.
--
Added file: http://bugs.python.org/file24386/raise_from_none_v4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
Ethan Furman et...@stoneleaf.us added the comment:
Okay, *all* the documentation updates this time. Thanks, Nick!
--
Added file: http://bugs.python.org/file24387/raise_from_none_v5.diff
___
Python tracker rep...@bugs.python.org
http
Ethan Furman et...@stoneleaf.us added the comment:
Latest version of PEP is on python-dev; here is the latest patch.
Summary:
For __cause__ we are replacing the old special value of None with Ellipsis:
Ellipsis means check __context__ for an exception to display; None means ignore
Ethan Furman et...@stoneleaf.us added the comment:
PEP 409 has been accepted. :)
Attached is the latest patch implementing it, with the (hopefully ;) final
changes.
Because Ellipsis is now the default value for __cause__, 'raise ... from
Ellipsis' is treated the same as 'raise
Ethan Furman added the comment:
There is one typo and one error in the first paragraph of the patch:
When raising a new exception (rather than
using to bare ``raise`` to re-raise the
^ should be an 'a'
exception currently being handled), the
implicit exception chain can be made
Ethan Furman et...@stoneleaf.us added the comment:
Not sure what 'embossed' has to do with not having dashes as part of the
element option names.
Attached is a patch (hopefully in the right format) agains the current 3.3
sources to remove the dash from the names in .element_names(), as well
Ethan Furman et...@stoneleaf.us added the comment:
The changes to Style.configure were not good. Corrected so the (possibly
empty) result is returned when a query is made but not when configuration is
set.
Two patches: one for the element_names issue, one for the configure issue.
Question
Changes by Ethan Furman et...@stoneleaf.us:
--
title: ttk.Style not translating some Tcl options - ttk.Style -- minor issues
with element_names and configure
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6549
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +terry.reedy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6549
___
___
Python-bugs-list
Ethan Furman et...@stoneleaf.us added the comment:
Are the changes good? Can they be commited?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14617
Ethan Furman et...@stoneleaf.us added the comment:
Newest changes uploaded.
--
Added file: http://bugs.python.org/file25707/__hash__3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14617
New submission from Ethan Furman et...@stoneleaf.us:
The weak reference docs could be clearer about when weak ref'ed objects are no
longer available. Attached doc patch attempts to do so.
--
files: weakref_doc_updates.diff
keywords: patch
messages: 161895
nosy: stoneleaf
priority
Ethan Furman et...@stoneleaf.us added the comment:
Changed ... will return the object ... to ... may return the object ...
For reference, here's the new text:
A weak reference to an object is not enough to keep the object alive: when the
only remaining references to a referent are weak
Ethan Furman et...@stoneleaf.us added the comment:
I agree that raise from None would be a nice enhancement.
I don't see it going into 3.3 since we've hit feature freeze.
Nick, do we need another PEP, or just consensus on pydev? (If consensus, I can
bring it up there after 3.3.0final
Ethan Furman et...@stoneleaf.us added the comment:
Okay, I see your point. It's also not difficult to work around if you really
want to toss the extra info:
except NameError:
try:
fallback_module.getch()
except Exception as exc
Ethan Furman et...@stoneleaf.us added the comment:
Patch attached. It basically says:
8
Note: Because using :keyword:`from` can throw away valuable debugging
information, its use with a bare :keyword:`raise` is not supported
Ethan Furman et...@stoneleaf.us added the comment:
Nick Coghlan wrote:
The from clause is intended for replacing previous exceptions with *new*
exceptions, not editing the attributes of existing ones which may already
have a different __cause__ set.
Huh. While I agree with the doc patch
Ethan Furman et...@stoneleaf.us added the comment:
Tyler Crompton wrote:
I'm in a little over my head as I can't conceptualize __cause__, so I may be
looking over things.
First, you, Ethan, said the following:
It's also not difficult to work around if you really want to toss the extra
Ethan Furman et...@stoneleaf.us added the comment:
Removed sample code from doc patch as it was not robust, nor recommended
practice. New patch is effectively:
Note: Because using :keyword:`from` can throw away valuable debugging
information, its use with a bare :keyword:`raise
Ethan Furman added the comment:
The documentation says, Returns a list of output lines; an empty list is not
a list of lines.
--
nosy: +stoneleaf
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15510
Ethan Furman added the comment:
Not sure I would worry about fixing it in 2.7, although I don't have strong
feelings about that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15510
Ethan Furman added the comment:
Antoine Pitrou wrote:
Antoine Pitrou added the comment:
an empty list is not a list of lines
Really?
.splitlines()
[]
Really.
-- ''.split('\n')
['']
--
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
Ethan Furman wrote:
Antoine Pitrou added the comment:
.splitlines()
[]
-- ''.split('\n')
['']
I see the docs have been fixed in 3 to explain the not present last
empty line.
However, sure this is still not correct?
-- wrap(' ')
[]
So if you have
Ethan Furman added the comment:
Antoine Pitrou wrote:
Antoine Pitrou added the comment:
Really.
-- ''.split('\n')
['']
You claimed that an empty list is not a list of lines. I countered that
splitlines(), which *by definition* returns a list of lines, can return
an empty list
Ethan Furman added the comment:
Chris Jerdonek wrote:
Here is an example on a paragraph with line breaks between paragraphs:
s/paragraph/text/
def wrap_paras(text, width=70, **kwargs):
... lines = [line for para in text.splitlines()
... for line in wrap(para, width
Ethan Furman added the comment:
Any problems with the current doc patch? If not, can it be applied before RC1?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15209
Ethan Furman added the comment:
Any problems with the current doc patch? If not, can it be applied before RC1?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14954
Ethan Furman added the comment:
Any problems with the current doc patch? If not, can it be applied before RC1?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14617
Ethan Furman et...@stoneleaf.us added the comment:
Because Ellipsis is now the default value for __cause__,
'raise ... from Ellipsis' is treated the same as 'raise ...'
Not exactly true -- if ... is a new exception then they are the same; if ... is
a caught exception that is being reraised
Ethan Furman et...@stoneleaf.us added the comment:
I just noticed that no one is assigned to this issue -- anybody on the nosy
list able to review?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
Ethan Furman et...@stoneleaf.us added the comment:
Remaining problems:
- default sys.excepthook implementation currently does the wrong thing
Unable to duplicate on my system (Win XP SP3)
- needs a test for the pythonrun display logic (test_cmd_line_script
would be the appropriate place
Ethan Furman et...@stoneleaf.us added the comment:
Changed TestTraceback.test_traceback_verbiage to use test.support and
test.script_helper (much simpler now, thanks Antoine!).
It is still in test_raise, however.
I do not understand why we would put it in test_cmd_line_script -- it seems
Ethan Furman et...@stoneleaf.us added the comment:
Is there a better place, then, than test_cmd_line_script?
The entire purpose of PEP 409 is to allow the suppression of non-relevant
information in the exception traceback. As such I would expect every Python
interpreter to adhere
Ethan Furman et...@stoneleaf.us added the comment:
I guess the crux of the issue for me is that I'm trying to test interpreter
output, and the fact that I am using a command-line script to do so is an
implementation detail.
--
___
Python tracker
Ethan Furman et...@stoneleaf.us added the comment:
Moved to test_cmd_line_script.
--
Added file: http://bugs.python.org/file24672/raise_from_none_test_cleanup.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14136
Ethan Furman et...@stoneleaf.us added the comment:
Nick,
Thank you for your thorough answers. I'm not trying to be difficult,
just trying to learn and understand.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14136
Ethan Furman et...@stoneleaf.us added the comment:
I see a comment around line 240 that says:
# It is assumed that the end of central directory magic
# number does not appear in the comment.
Any reason not to add that check to comment.setter?
--
nosy: +stoneleaf
Ethan Furman et...@stoneleaf.us added the comment:
Nick Coghlan wrote:
Nick Coghlan ncogh...@gmail.com added the comment:
Hah, I've been dealing with Python's regression test suite for 8+ years and
there are still cases where I don't understand the rationale for testing
things
Ethan Furman et...@stoneleaf.us added the comment:
Modified test name to test_pep_409_verbiage(); modified test body to use same
pattern as other tests, thus eliminating the dangling test script files after
the test was run.
--
Added file: http://bugs.python.org/file25052
New submission from Ethan Furman et...@stoneleaf.us:
From http://docs.python.org/py3k/reference/datamodel.html#object.__hash__
---
Classes which inherit a __hash__() method from a parent class but change the
meaning of __eq__
Ethan Furman et...@stoneleaf.us added the comment:
Éric Araujo wrote:
Changes by Éric Araujo mer...@netwok.org:
--
versions: +Python 2.7 -Python 3.1
The docs for 2.7 are correct, as __hash__ is not automatically
suppressed in that version.
--
~Ethan
Ethan Furman et...@stoneleaf.us added the comment:
More re-writing...
--
Added file: http://bugs.python.org/file25264/__hash__2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14617
Changes by Ethan Furman et...@stoneleaf.us:
--
keywords: +patch
stage: - patch review
Added file: http://bugs.python.org/file30986/issue18510.stoneleaf.01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18508
Ethan Furman added the comment:
Cleaner patch.
--
Added file: http://bugs.python.org/file30987/issue18510.stoneleaf.02.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18508
Changes by Ethan Furman et...@stoneleaf.us:
--
assignee: - ethan.furman
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18545
Changes by Ethan Furman et...@stoneleaf.us:
--
assignee: - ethan.furman
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18635
Ethan Furman added the comment:
Ah, so the Enum class has the mixin class as wall as / instead of the Enum
member (which should find it via normal attribute lookup).
I have no problem with that. I'll need to make a couple more changes to the
code, add a test, etc., etc.
It won't make
Ethan Furman added the comment:
I'll check you patch later against big numbers (which is where I had
difficulties). If it works I'll try to make it more complete. If it doesn't,
I've been working on just extraction the Enum member's value and using that
(works fine on the Python side
Ethan Furman added the comment:
I don't think my idea of always extracting .value is grandiose (and didn't take
that long to implement on the Python side), but it is definitely forcing me to
learn more about C and how Python is put together.
It this point I have successfully imported Enum
Ethan Furman added the comment:
I also admit to being curious as to the reason it is useful, especially since
it is, at this point, an implementation detail.
Even so, it still makes more sense to have that attribute on the class instead
of the instance
Ethan Furman added the comment:
Eli, your method is good. I thought I had tried something similar but I
obviously had the wrong PyLong constructor.
I'll get it implemented.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ethan Furman added the comment:
Thanks for the offer, Eli, but I almost have the tests done. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18264
Ethan Furman added the comment:
Okay, patch attached with C code (thanks, Eli!), more python code, and some new
tests.
Only the `int` case is handled.
--
Added file: http://bugs.python.org/file31141/issue18264.stoneleaf.01.patch
___
Python tracker
Ethan Furman added the comment:
Well, aside from not having a clue as to what Chris is trying to do, should we
make _member_type_ public? The only reason I put it there was to aid
introspection -- Enum does not use it.
--
___
Python tracker rep
Ethan Furman added the comment:
I don't understand.
Type checks are already performed throughout the code (int, float, True, False,
NaN, Inf, etc.).
What will opereator.index buy us?
--
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
This patch handles both float and int subclasses, and includes
fixes/improvements from the review.
--
Added file: http://bugs.python.org/file31155/issue18264.stoneleaf.02.patch
___
Python tracker rep
Ethan Furman added the comment:
Forgot to add float tests. Included in this patch.
--
Added file: http://bugs.python.org/file31156/issue18264.stoneleaf.03.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18264
Ethan Furman added the comment:
Hopefully the final patch. :)
--
Added file: http://bugs.python.org/file31172/issue18264.stoneleaf.04.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18264
Ethan Furman added the comment:
Forgot to back out core dump tests before creating previous patch. This one
even passes the tests. :/
--
Added file: http://bugs.python.org/file31173/issue18264.stoneleaf.05.patch
___
Python tracker rep
Ethan Furman added the comment:
I'll plan on committing no sooner than Friday unless somebody else has
comments/corrections.
Thanks, Eli.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18264
Ethan Furman added the comment:
Eli Bendersky added the comment:
Make sure to run the test(s) in refleak mode . . .
How extensive should testing be?
I plan on always running the refleak mode tests (now that I know how ;) .
Should I also run non-refleak tests?
Should I run tests
New submission from Ethan Furman:
help(), when used on an enum member or class, returns almost nothing. I
suspect the custom __dir__ is at fault, but whatever is causing the problem
needs fixing.
--
assignee: ethan.furman
messages: 194714
nosy: barry, eli.bendersky, ethan.furman
Ethan Furman added the comment:
With custom __dir__:
Help on class Enum in module enum:
Enum = enum 'Enum'
Without custom __dir__:
Help on class Enum in module enum:
class Enum(builtins.object)
| Generic enumeration.
|
| Derive
Ethan Furman added the comment:
Sorry, sorry.
Long week, felt like more than two days, mild sense of unease and stress due to
non-functioning Release Schedule on python.org, and wanting to get Enum used
/somewhere/ in the stdlib before 3.4 is locked down.
Making help() better would
Ethan Furman added the comment:
So what do we want Enum's __dir__ to report?
Normally we see things like __eq__, __dict__, __getnewargs__, etc.
For IntEnum there would be __abs__, __floor__, __div__, etc.
Do we want to worry about those kinds of differences? I think we do.
And if we do
Ethan Furman added the comment:
Huh. I just checked `help(Color)` on my proposed __dir__ and got the two-line,
rather useless, response. Perhaps help() is broken with all custom __dir__s.
--
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
Issue18738 created.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18720
___
___
Python-bugs-list mailing list
New submission from Ethan Furman:
While `.format()` works fine with enum, %-formatting does not:
-- class AF(enum.IntEnum):
... IPv4 = 1
... IPv6 = 2
...
-- AF.IPv4
AF.IPv4: 1
-- '%s' % AF.IPv4
'AF.IPv4'
-- '%r' % AF.IPv4
'AF.IPv4: 1'
-- '%d' % AF.IPv4
'AF.IPv4'
-- '%i' % AF.IPv4
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Python-bugs-list
Ethan Furman added the comment:
'{:}'.format(AF.IPv4) is incorrect, but '{:10}'.format(AF.IPv4) behaves as it
should.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Ethan Furman added the comment:
Looks like Objects/unicodeobject.c needs the same enhancement that
Modules/_json.c received: convert int/float subclasses into actual ints/floats
before continuing.
--
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
Gotcha. I'm on it.
--
assignee: - ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Ethan Furman added the comment:
The %-formatting needs to be handled by str, correct?
What is '{:}' supposed to mean?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Ethan Furman added the comment:
Which is the same as '%s', yes? In that case, the current behavior of
'{:}'.format(AF.IPv4) is correct, isn't it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Ethan Furman added the comment:
Eric V. Smith added the comment:
I think that specifying __format__() would be best, except then you need to
decide what sort of format specification language you want to support, and
deal with all of the implementation details. Or, maybe just have Enum's
Ethan Furman added the comment:
Eric V. Smith added the comment:
For the format version, what gets called is:
int_subclass.__format__('d'), which is int.__format__(int_subclass,
'd'), which produces '1', assuming int(int_subclass) is 1.
Ah, I didn't realize. Thanks.
So, there's no str
Ethan Furman added the comment:
Eric V. Smith added the comment:
I assumed we'd want it to look like the str() version of itself, always. But
it's debatable.
An IntEnum's str and repr should be (and any format or % codes that are the
equivalent) the Enum str and repr. The %
and format
Ethan Furman added the comment:
Okay, I see your points. I can certainly agree with going with the str
representation when no numeric code is specified. But, if a numeric code is
specified (x, b, d, etc.) then the numeric value should be used.
Agreed
Ethan Furman added the comment:
On 08/14/2013 11:55 AM, Eli Bendersky wrote:
I'm not sure I understand. The discrepancy between {:} and {:10} is clearly
a problem.
Ah, you're right.
--
___
Python tracker rep...@bugs.python.org
http
Ethan Furman added the comment:
What I'm hoping is to get agreement on what the behavior should be (unspecified
format codes use str or repr, specified
numeric codes use the value), and then persuade folks that int (or PyLong) is
where that behavior should be kept (so int
is subclass
1 - 100 of 1854 matches
Mail list logo
