[issue6210] Exception Chaining missing method for suppressing context
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +stoneleaf ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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]() except KeyError: raise CommandError(Unknown command) # Include the context try: command_dict[command]() except KeyError: raise with CommandError(Unknown command) I think we can even strike off the verbiage in the exception handler... that way, raise always does the same thing -- raise KeyError will raise a KeyError, always, not sometimes a KeyError and sometimes a KeyError nested in a WhatEverError. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 to print reasonably -- and it seems very unreasonable to have the exception I'm converting /from/ show up in the traceback. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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: This is a blatant falsehood -- another exception did not occur, a different exception was raised. Now, when another exception does actually occur, I'm all for the nested traceback, but if I'm raising a different one, why is this useful: -- d.address Traceback (most recent call last): File nested_exceptions.py, line 7, in __getattr__ return self.data[self.names.index(name)] ValueError: tuple.index(x): x not in tuple During handling of the above exception, another exception occurred: Traceback (most recent call last): File stdin, line 1, in module File nested_exceptions.py, line 9, in __getattr__ raise AttributeError(Attribute %s does not exist % name) AttributeError: Attribute address does not exist ? Furthermore, I use my own library, and have no interest in seeing extra, completely unnecessary, and wrong (verbiage, anyway) traceback info -- not in my own libraries, nor in other's that I may be using. Keep the nesting for when an exception actually occurs, not for when an exception is, under programmer control, being modified/changed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 it here? I'm not sure I understand what you are saying -- could you rephrase? By the way, this is all described in detail in a PEP: http://www.python.org/dev/peps/pep-3134/ Yes, I know -- and from the PEP: Rationale The Python-Dev discussions revealed interest in exception chaining for two quite different purposes. To handle the unexpected raising of a secondary exception, the exception must be retained implicitly. To support intentional translation of an exception, there must be a way to chain exceptions explicitly. This PEP addresses both. Open Issue: Suppressing Context As written, this PEP makes it impossible to suppress '__context__', since setting exc.__context__ to None in an 'except' or 'finally' clause will only result in it being set again when exc is raised. The two motivations are excellent, and I have no issue with them; what I have issue with is that it is no longer possible to discard previous context. If I want to change the error message, I can use except ValueError as exc: raise AttributeError(blah) from exc and then get The above exception was the direct cause of the following exception I would also like to see: except ValueError as exc: raise AttributeError(blah) with exc to get During handling of the above exception, another exception occurred which would be the same as: 1/0 to get During handling of the above exception, another exception occurred and, finally, if all I have is except ValueError as exc: raise AttributeError(blah) I just get the normal, previous context free, traceback. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 be possible that I want to change the exception -- leading to the three possibilities I described earlier. Looking through my dbf module, most of those re-raises I'll be changing to use the raise ... from ... syntax, but there are still a couple places where it makes no sense to have the extra nested information available. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 ZeroDivisionError as exc: raise InvalidInput() ? In both cases I want to discard the previous exception, and raise my own in its place (without the nesting, in this example). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 is raising an exception... seems unlikely that this would be a case of transforming one exception into another, therefore the raise should not suppress the context by default... okay, I'll concede the point. Looks like the best option, then, is Nick's idea of the .no_context() method on exceptions. -- versions: +Python 3.2 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 to parse than raise AttributeError(Field %s is not in table % attr) from None -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9121] Glossary entry for nested scope incorrect
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 work only for reference and not for assignment which will otherwise write to the innermost scope. -- assignee: d...@python components: Documentation messages: 108949 nosy: d...@python, stoneleaf priority: normal severity: normal status: open title: Glossary entry for nested scope incorrect versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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: 'raise' [test ['from' test]] | 'raise' 'as' [test ['from' test]]
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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() from SomeOtherError() -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 is needed. The other, more important, reason is to ensure the new syntax is spec'ed out clearly and incorporated into the language reference for the benefit of other implementations in the event that it *does* get approved) I'm not sure why this would be a syntax change. We can already do try: 1/0 except ZeroDivisionError: raise ValueError() from MathError() to explicitly set the __cause__ and ignore the previous context. The only difference would allowing 'None' to mean 'no cause, discard previous context'. 2. A change that *doesn't* need a PEP is to just adjust the implicit exception chaining such that __context__ doesn't get set automatically if it has already been set explicitly (it turns out handling this situation was an open question in PEP 3134, not a specificied behaviour). That way, this task can be handled using a utility function: def no_context(new_exc): new_exc.__context__ = None return new_exc def doXY (): # ... try: page = urlopen( someRequest ) except urllib.error.URLError as e: raise no_context(MyError( 'while doing XY', e )) This seems like a lot more work than just allowing None to mean none. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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) I must agree. The patch attached now sets __cause__ to True, leaving __context__ unclobbered. The exception printing routine checks to see if __cause__ is True, and if so simply skips the display of either cause or __context__, but __context__ can still be queried by later code. One concern raised was that since it is possible to write (even before this patch) raise KeyError from NameError outside of a try block that some would get into the habit of writing raise KeyError from None as a way of preemptively suppressing implicit context chaining; I am happy to report that this is not an issue, since when that exception is caught and a new exception raised, it is the new exception that controls the display. In other words: try: ... raise ValueError from None ... except: ... raise NameError ... Traceback (most recent call last): File stdin, line 2, in module ValueError During handling of the above exception, another exception occurred: Traceback (most recent call last): File stdin, line 4, in module NameError -- Added file: http://bugs.python.org/file24354/raise_from_none_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 already displayed) --- Proposed semantics (after patch) cause is True -- context set, but no display cause is not None -- cause set, display it instead of context cause is None -- no cause, try to display context context is None -- no context context is not None -- context set, display it (unless cause already displayed) --- I prefer to go with True for cause, instead of False, as a way of saying Yes, there was an exception before this one, but I'm not going to display it as opposed to None meaning No there is no cause, and I'm not going to show you the context either. Using True instead of False, and leaving the None's as they are now, preserves the behavior of None meaning none, as in there isn't one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 removed, and you do care about it... well, too bad. Georg, Nick: On further thought, I agree that having 'from None' set cause from None to True is counter-intuitive, and there is consistency in having __context__ as None and __cause__ as False. Thanks, Nick, for the pointers on the necessary changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 __context__ and stop following exception chain; an exception means display this exception and stop following the exception chain. -- Added file: http://bugs.python.org/file24401/raise_from_none_v6.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 ...' -- Added file: http://bugs.python.org/file24405/raise_from_none_v7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
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 explicit by using :keyword:`from` with :keyword:`raise`. The single argument to :keyword:`from` must be an exception or ``None``. It will be set as :attr:`__cause__` on the raised exception. Setting :attr:`__cause__` also implicitly sets the :attr:`__suppress_context__` attribute to ``True``. The last sentence is incorrect -- __suppress_context__ is only set to True if __cause__ is set to None; if __cause__ is set to any other exception __suppress_context__ remains False and the new exception chain will be printed: try: ... raise ValueError ... except: ... raise NameError from KeyError ... KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File stdin, line 4, in module NameError This is easily fixed by adding 'to ``None``': Setting :attr:`__cause__` to ``None`` also implicitly sets the :attr:`__suppress_context__` attribute to ``True``. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6549] ttk.Style not translating some Tcl options
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 as return None from .configure() when setting options. -- keywords: +patch nosy: +stoneleaf Added file: http://bugs.python.org/file23222/ttk.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6549 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6549] ttk.Style not translating some Tcl options
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: Does it ever make sense to do both a query and a configuration
update in the same call? I don't think it is:
-- ttk.Style.configure('TButton', 'relief', relief='sunken'
'raised'
-- s.configure('TButton','relief')
'raised'
Does it make sense to raise an exception in configure if both query_opt and kw
specified?
--
Added file: http://bugs.python.org/file23223/ttk_style_fixes.zip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6549
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6549] ttk.Style -- minor issues with element_names and configure
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6549] ttk.Style -- minor issues with element_names and configure
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6549 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14617] confusing docs with regard to __hash__
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14617] confusing docs with regard to __hash__
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14954] weakref doc clarification
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: normal severity: normal status: open title: weakref doc clarification type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25755/weakref_doc_updates.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14954] weakref doc clarification
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 references, :term:`garbage collection` is free to destroy the referent and reuse its memory for something else. However, until the object is actually destroyed the weak reference may return the object even if there are no strong references to it. -- Added file: http://bugs.python.org/file26179/weakref_doc_updates_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
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 is released.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
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: raise exc from None A total of three more words to get the desired behavior (and small ones at that). I'll work on a doc patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
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. If you are trying to do this: try: some_module.not_here() except NameError: try: backup_module.not_here() except NameError: raise from None # suppress context in NameError do this instead: try: some_module.not_here() except NameError: try: backup_module.not_here() except NameError as exc: raise exc from None # suppress context in NameError 8 -- keywords: +patch Added file: http://bugs.python.org/file26191/raise_from_doc_update.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
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 solution, I think the most common use of 'from' will be 'raise SomeException from None' or, as the patch suggests, 'raise exc from None' (exc being an already existing exception). Any examples of when somebody might do: try: do_something() except NameError: raise NewError from SomeOtherError ? I am unsure of the advantages in replacing NameError in the above stack trace with SomeOtherError instead... although NameError would still be there in __context__... Still, any examples? ~Ethan~ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
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 info: except NameError: try: fallback_module.getch() except Exception as exc: raise exc from None A total of three more words to get the desired behavior (and small ones at that). Counter-argument: if it's just three words, then why was the shorthand without the from clause implemented in the first place? I'm not sure I understand the question -- do you mean why can we do 'raise' by itself to re-raise an exception? 'from' is new, and was added in Py3k (see below). 'raise', as a shortcut, is there to allow clean-up (or whatever) in the except clause before re-raising the same exception. In 3.0 exceptions were enhanced to include a link to previous exceptions. So if you are handling exception A and exception B occurs, exception B will be raised and will have a link to A. That link is kept in __context__. This complete chain will then be printed if the last exception raised is uncaught. However, there are times when you may want to add more exception information yourself, so we have the `from` clause, which store the extra exception in __cause__. And, there are times when you are changing from one exception to another and do not want the previous one displayed -- so we now have 'from None' (which sets __suppress_context__ to True). So if some underlying function raises ValueError, but you want to transform that to an XyzError, your can do: try: some_function() except ValueError: raise XyzError from None and then, if the exception is uncaught and printed, only the XyzError will be displayed (barring custom print handlers). My use case was primarily based on the idea that the unavailability of the windows module (from the example) is irrelevant information to, say, Unix users. When an exception is raised, the user shouldn't have to see any Windows-related exceptions (that is if there is an alternate solution). So you are using the absence of the Windows based module as evidence that you are not running on Windows... but what if you are on Windows and there is some other problem with that module? The usual way to code for possible different modules is: try: import windows_module as utils # or whatever name except ImportError: import fallback_module as utils -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
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` is not supported. -- Added file: http://bugs.python.org/file26201/raise_from_doc_update_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
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://bugs.python.org/issue15510
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
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 code that loops over the return and prints it out:
for line in wrap(blah):
print(line)
you will have different output with [] than with [''].
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15510
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
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, therefore textwrap.wrap() is not exotic in its behaviour.
Whether or not split() behaves differently is irrelevant.
Not at all -- it's a warning to think Why does this shortcut function
exist? How is it different? Something I will pay more attention to. ;)
So if you have code that loops over the return and prints it out:
for line in wrap(blah):
print(line)
you will have different output with [] than with [''].
Indeed, which is a good reason *not* to change textwrap.wrap's
behaviour. The current behaviour is as reasonable as any other, and
changing it would break compatibility.
For an empty string, sure -- for a string with nothing but white space, no:
-- wrap(' ')
[]
-- ''.splitlines()
['']
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15510
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns 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, **kwargs)] ... return \n.join(lines) ... text = \ ... abcd abcd ... ... abcd abcd print(wrap_paras(text)) abcd abcd abcd abcd The edge case we're discussing determines whether line breaks between paragraphs are preserved in the result. (With current behavior, they are not.) Having now more carefully read the docs (which, admittedly, I should have done before responding the first time) I found this: textwrap.wrap(text, width=70, **kwargs) Wraps the single paragraph in text . . . textwrap.fill(text, width=70, **kwargs) Wraps the single paragraph in text, . . . In other words, it is not designed to work on multiple paragraphs at once. And the documentation is fine. Move along, no bug to see here, move along... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15209] Re-raising exceptions from an expression
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14954] weakref doc clarification
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14617] confusing docs with regard to __hash__
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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, __cause__ will be (re)set to Ellipsis. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
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) Not sure I understand this point, but I added a test in test_raise that starts a subprocess interpreter and checks its output. - testCauseSyntax test should probably be in test_raise, not test_exceptions Moved. -- Added file: http://bugs.python.org/file24529/pep409.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14136] Simplify PEP 409 command line test and move it to test_cmd_line_script
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 to me that test_cmd_line_script is to verify that python is working correctly when executing scripts, but for this test we are assuming that python does work correctly when executing scripts and we testing the verbiage from raising exceptions. -- keywords: +patch nosy: +stoneleaf Added file: http://bugs.python.org/file24668/raise_from_none_test_cleanup.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14136] Simplify PEP 409 command line test and move it to test_cmd_line_script
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 to it. (Yes, I understand that custom display hooks can still do different things, but they are custom and not the default.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14136] Simplify PEP 409 command line test and move it to test_cmd_line_script
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 rep...@bugs.python.org http://bugs.python.org/issue14136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14136] Simplify PEP 409 command line test and move it to test_cmd_line_script
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14136] Simplify PEP 409 command line test and move it to test_cmd_line_script
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14399] zipfile and creat/update comment
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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14136] Simplify PEP 409 command line test and move it to test_cmd_line_script
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 a particular way (beyond it must have seemed like a good idea at the time). It has a lot more historical cruft than the standard library does :) The proper location for a particular test can be a bit of a coin toss in many cases, but one useful guide (which applies in this case) is to try to avoid adding *new* standard library dependencies to a test module if there's an alternate suitable location that already has those dependencies. I just checked the patch and it still applies cleanly with the two effected tests passing. Nick, any chance of getting this checked in and closed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14136] Simplify PEP 409 command line test and move it to test_cmd_line_script
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/raise_from_none_test_cleanup_3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14617] confusing docs with regard to __hash__
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__() such that the hash value returned is no longer appropriate (e.g. by switching to a value-based concept of equality instead of the default identity based equality) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition. Doing so means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError). If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = ParentClass.__hash__. Otherwise the inheritance of __hash__() will be blocked, just as if __hash__ had been explicitly set to None. --- The first paragraph says the user has to change __hash__ if it's different because of changes to __eq__, the second paragraph says __hash__ is automatically removed if __eq__ is changed; the second paragraph reflects reality. Proposed change: --- Classes which change the meaning of __eq__() (thus losing automatic delegation to the parent class' __hash__) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition (which is otherwise done implicity). Having __hash__ set to None, either explicitly or implicitly, means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError). If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = ParentClass.__hash__. --- Patch attached. -- assignee: docs@python components: Documentation, Interpreter Core files: __hash__.diff keywords: patch messages: 158644 nosy: docs@python, stoneleaf priority: normal severity: normal status: open title: confusing docs with regard to __hash__ type: behavior versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25261/__hash__.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14617] confusing docs with regard to __hash__
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~ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14617] confusing docs with regard to __hash__
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18508] enum.Enum population of _value2member_map does not match fallback search
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18508] enum.Enum population of _value2member_map does not match fallback search
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18545] enum always runs member_type when use_args is True
Changes by Ethan Furman et...@stoneleaf.us: -- assignee: - ethan.furman nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18545 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18635] Enum sets _member_type_ to instantiated values but not the class
Changes by Ethan Furman et...@stoneleaf.us: -- assignee: - ethan.furman nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18635 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18635] Enum sets _member_type_ to instantiated values but not the class
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 the first alpha, but should be ready for the second. -- nosy: +barry, eli.bendersky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18635 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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 ;) . Big Question: if the Enum member was used as a key, do we use .name or .value? The decision I went with was to compare the hashes of the member name vs the member itself -- if they're the same, use the .name, otherwise use the value. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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 into the _json module; now I'm working on a function to quietly replace the object being encoded with its .value if it is, in fact, an Enum member. Just been real short on time lately. :/ Thank goodness for C API section of the docs! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18635] Enum sets _member_type_ to instantiated values but not the class
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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18635 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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 rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18635] Enum sets _member_type_ to instantiated values but not the class
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...@bugs.python.org http://bugs.python.org/issue18635 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
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 with a python built without --with-pydebug? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18693] help() not helpful with enum
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 priority: normal severity: normal status: open title: help() not helpful with enum versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18693 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18693] help() not helpful with enum
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 from this class to define new enumerations. | | Methods defined here: | | __eq__(self, other) | | __getnewargs__(self) | | __hash__(self) | | __repr__(self) | | __str__(self) | | -- | Static methods defined here: | | __new__(cls, value) | | -- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) | | name | Route attribute access on a class to __getattr__. | | This is a descriptor, used to define attributes that act differently when | accessed through an instance and through a class. Instance access remains | normal, but access to an attribute through a class will be routed to the | class's __getattr__ method; this is done by raising AttributeError. | | value | Route attribute access on a class to __getattr__. | | This is a descriptor, used to define attributes that act differently when | accessed through an instance and through a class. Instance access remains | normal, but access to an attribute through a class will be routed to the | class's __getattr__ method; this is done by raising AttributeError. --- I'm thinking we should drop the custom __dir__. help() is far more important than not seeing some things with dir(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18693 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18693] help() not helpful with enum
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 be a better solution, especially if we enhanced it to show docstrings on instances. I'll see what I can figure out. Feel free to beat me to it. :) -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18693 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18693] help() not helpful with enum
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, then we are looking at removing items to make our custom __dir__, and with each release we would have to revisit the blacklist of items we don't want (the tests would catch that for us, but it would still be effort to update the code). What if we took what object.__dir__ gave us, then added the Enum members while removing the private, er, non-public data structures? In other words, this dir in EnumMeta: def __dir__(cls): items = set(super().__dir__()) disgard = set([m for m in items if _is_sunder(m)]) members = set(cls.__members__) return sorted((items | members) ^ disgard) with this Enum: class Color(enum.Enum): ... RED = 1 ... BLUE = 2 ... GREEN = 3 ... gives us this result: dir(Color) ['BLUE', 'GREEN', 'RED', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'name', 'value'] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18693 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18693] help() not helpful with enum
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://bugs.python.org/issue18693 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18720] Switch suitable constants in the socket module to IntEnum
Ethan Furman added the comment: Issue18738 created. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] % formatting incomplete for Enum
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 'AF.IPv4' -- '%x' % AF.IPv4 '1' -- '%o' % AF.IPv4 '1' Hex and octal work, decimal and integer do not. -- messages: 195160 nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka priority: normal severity: normal status: open title: % formatting incomplete for Enum type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18606] Add statistics module to standard library
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18606 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] % formatting incomplete for Enum
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
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] % formatting incomplete for Enum
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://bugs.python.org/issue18738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
Ethan Furman added the comment: Gotcha. I'm on it. -- assignee: - ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
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
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
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
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
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
__format__ be:
def __format__(self, fmt):
return format(str(self), fmt)
which makes the format specification language match str's.
I disagree. A subclass shouldn't have to write code to provide the /same/
behavior as its superclass, just code for
different behavior. In the cases of
'%d' % int_subclass
or
'{:d}'.format(int_subclass)
str should be smart enough to actually produce the numeric value, not rely on
the subclass' __repr__.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
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 involved anywhere, except the one on which
.format() is called ('{:d}'), and it doesn't know about the types of any
arguments or what the format specifiers mean, so it can't make any
decisions.
As far as format goes, I don't think there is a problem. It's behaving just
like it should (which makes sense, since
IntEnum is derived from int and is already using int's __format__ by default).
The problem, then, is just with %-formatting, which is squarely a str (aka
Objects/unicodeobject.c) issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
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 codes that specifically call for a numeric representation should give that numeric representation (format is good here, % is not). For format, I think the question is should an IntEnum format like an int, with the wacky exception of a specifier of '', or should it always format like a str? I think for format we should treat IntEnums as ints unless the s or r codes are specifically used. I agree the %-formatting question is different, and I further think there's not much we can do there. We can have unicodeobject.c convert int (and float) subclasses to actual ints and floats before getting the numeric value (we just did this to _json.c so it could serialize IntEnums). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
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? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
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://bugs.python.org/issue18738
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
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 friendly) -- then IntEnum (and other int subclasses) don't have to worry about it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
