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 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 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
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:
Newest changes uploaded.
--
Added file: http://bugs.python.org/file25707/__hash__3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14617
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
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
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
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:
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:
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:
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 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:
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:
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:
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:
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
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:
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
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
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:
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
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
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
1801 - 1854 of 1854 matches
Mail list logo
