Re: [Python-Dev] Range __contains__ and objects with __index__ methods
On Mon, Dec 27, 2010 at 11:52 AM, Terry Reedy wrote: > Return a converted to an integer. Equivalent to a.__index__()." > comes close to implying equality (if possible). > > What are the actual used of .__index__? PEP 357 gives the original rationale - it was to allow integer-like objects (such as numpy scalars) to be used as sequence indices, as well as slice parameters. I would have to grep the source to get a full list of uses, but I believe it is already used in at least those two cases, as well as for sequence repetition (via '*') and to identify permitted inputs to bin/oct/hex. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Range __contains__ and objects with __index__ methods
> What are the actual used of .__index__? Can you please rephrase this question? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87445 - python/branches/py3k/Lib/numbers.py
On 12/26/2010 7:01 PM, Nick Coghlan wrote: Yes, the definition in the language reference could definitely be improved to mention the semantics first, and then reference operator.index second. Possible wording "Indicates to the Python interpreter that the object is semantically equivalent to the returned integer, rather than merely supporting a possibly lossy coercion to an integer If that is the intent of __index__, the doc should say so more clearly. That clarification would change my answer to your question about range. > (i.e. as the __int__ method allows for types like float and decimal.Decimal). This allows non-builtin objects to be used as sequence indices, elements of a slice definition, multiplies in sequence repetition, etc. Can be invoked explicitly from Python code via operator.index()" Removing the circularity from the definitions of __index__ and operator.index doesn't have a great deal to do with the docstrings in numbers.py, though. It is both related and needed though. IE, it is hard to answer questions about what to to with .index if the intended meaning of .index is not very clear ;-). -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Range __contains__ and objects with __index__ methods
On 12/26/2010 7:15 PM, Nick Coghlan wrote: Starting in Python 3.2, range() supports fast containment checking for integers (i.e. based on an O(1) arithmetic calculation rather than an O(N) iteration through the entire sequence). Currently, this fast path ignores objects that implement __index__ - they are relegated to the slow iterative search. This seems wrong to me - the semantics of __index__ are such that it is meant to be used for objects that are alternative representations of the corresponding Python integers (e.g. numpy scalars, or integers that use a particular number of bits in memory). Under that interpretation, if an object provides __index__, we should use the fast path instead of calling __eq__ multiple times. If I understand, you are proposing 'replacing' o with o.__index__() (when possible) and proceeding on the fast path rather than iterating the range and comparing o for equality each value in the range (the slow path). I suppose this would change semantics if o != o.__index__(). Equality is not specified in the manual: "object.__index__(self) Called to implement operator.index(). Also called whenever Python needs an integer object (such as in slicing, or in the built-in bin(), hex() and oct() functions). Must return an integer." However "operator.__index__(a) Return a converted to an integer. Equivalent to a.__index__()." comes close to implying equality (if possible). What are the actual used of .__index__? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Column offsets for attribute nodes
On Mon, Dec 27, 2010 at 9:34 AM, Benjamin Peterson wrote: > 2010/12/26 Sven Brauch : >> In that discussion, there's been different opinions about which >> behaviour is better; main arguments were "consistency" for the current >> and "usefulness" for the suggested behaviour. It has been proposed to >> ask the question on this list, that's why I'm doing that now. :) > > My argument against this change is that an attribute includes the > expression from which the attribute is being taken. This is consistent > with subscripts and calls, which both have the lineno and col_offset > of their source expressions. I'd like to see the impact on existing uses of this information (primarily SyntaxErrors) before forming a firm opinion, but my initial inclination is that retaining the column information for the subattribute names is a better option. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Range __contains__ and objects with __index__ methods
Starting in Python 3.2, range() supports fast containment checking for integers (i.e. based on an O(1) arithmetic calculation rather than an O(N) iteration through the entire sequence). Currently, this fast path ignores objects that implement __index__ - they are relegated to the slow iterative search. This seems wrong to me - the semantics of __index__ are such that it is meant to be used for objects that are alternative representations of the corresponding Python integers (e.g. numpy scalars, or integers that use a particular number of bits in memory). Under that interpretation, if an object provides __index__, we should use the fast path instead of calling __eq__ multiple times. Thoughts? Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Column offsets for attribute nodes
Hey, yeah, you're right, that would be even better. Currently it would also give a 3 for bar in "foo.bar.baz". I'd be fine with both solutions, but yours seems more logical. Bye, Sven 2010/12/27 Glenn Linderman : > On 12/26/2010 1:41 PM, Sven Brauch wrote: > > Hi there, > > I recently filed a feature request in the tracker to change the > behaviour of the parser in terms of setting ranges on attribute AST > nodes, because I'm working on an application which needs more > information than is currently provided. I suggested to change the > behaviour from > foo.bar.baz # <- foo is said to start at column 0, bar at 0 and baz at > 0 (current) > to > foo.bar.baz # <- foo starts at 0, bar at 3 and baz at 7 (suggestion) > > In that discussion, there's been different opinions about which > behaviour is better; main arguments were "consistency" for the current > and "usefulness" for the suggested behaviour. It has been proposed to > ask the question on this list, that's why I'm doing that now. :) > The thread can be found here: http://bugs.python.org/issue10769 > > So, which version do you think to be better: the current one or the > suggested one? > > The current one is better, but maybe bar at 4 and baz at 8 would be even > better. > > In other words, I don't think pointing at the "." is useful? Was that your > intention? > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/svenbrauch%40googlemail.com > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fault handler updated, now disabled by default
On Mon, Dec 27, 2010 at 8:57 AM, Victor Stinner wrote: > Le dimanche 26 décembre 2010 à 14:10 +, exar...@twistedmatrix.com a > écrit : >> On 25 Dec, 10:31 pm, mer...@netwok.org wrote: >> >>faulthandler is a module: enable the handler is simple as "import >> >>faulthandler". >> > >> >That sounds like a source of unwanted behavior (aka problems) if the >> >handler is enabled by 1Cpydoc faulthandler 1D or by a pkgutil walk. You >> >may want to consider using a function to enable the functionality (and >> >add one to disable it). >> >> Enormous +1. > > I don't know pkgutil. How does it work? In which case would it load the > faulthandler module? > > faulthandler is currently only written in C. pkgutil includes a function that lets you walk the entire module heirarchy, implicitly importing everything, including all the builtin modules. It's one of the reasons doing things as side-effects of import is considered highly undesirable. The pydoc tests do this when they bring the (docstring-based) documentation server up to check its handling of HTTP requests. (we recently picked up an implicit addition of a logging handler by concurrent.futures due to this effect). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Column offsets for attribute nodes
On 12/26/2010 1:41 PM, Sven Brauch wrote: Hi there, I recently filed a feature request in the tracker to change the behaviour of the parser in terms of setting ranges on attribute AST nodes, because I'm working on an application which needs more information than is currently provided. I suggested to change the behaviour from foo.bar.baz #<- foo is said to start at column 0, bar at 0 and baz at 0 (current) to foo.bar.baz #<- foo starts at 0, bar at 3 and baz at 7 (suggestion) In that discussion, there's been different opinions about which behaviour is better; main arguments were "consistency" for the current and "usefulness" for the suggested behaviour. It has been proposed to ask the question on this list, that's why I'm doing that now. :) The thread can be found here: http://bugs.python.org/issue10769 So, which version do you think to be better: the current one or the suggested one? The current one is better, but maybe bar at 4 and baz at 8 would be even better. In other words, I don't think pointing at the "." is useful? Was that your intention? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87445 - python/branches/py3k/Lib/numbers.py
On Mon, Dec 27, 2010 at 3:13 AM, Éric Araujo wrote: > Le 24/12/2010 02:08, Nick Coghlan a écrit : >> On Fri, Dec 24, 2010 at 4:41 AM, eric.araujo >> wrote: >>> Fix small inaccuracy: there is no index function >> >> Yes, there is, it just isn't a builtin - it lives in the operator module. > Defining object.__index__ with operator.index seems pretty circular to > me :) http://docs.python.org/dev/reference/datamodel#object.__index__ > does it, but it should be fixed IMO. The difference between __int__ and > __index__ is also not clear. Yes, the definition in the language reference could definitely be improved to mention the semantics first, and then reference operator.index second. Possible wording "Indicates to the Python interpreter that the object is semantically equivalent to the returned integer, rather than merely supporting a possibly lossy coercion to an integer (i.e. as the __int__ method allows for types like float and decimal.Decimal). This allows non-builtin objects to be used as sequence indices, elements of a slice definition, multiplies in sequence repetition, etc. Can be invoked explicitly from Python code via operator.index()" Removing the circularity from the definitions of __index__ and operator.index doesn't have a great deal to do with the docstrings in numbers.py, though. >>> def __index__(self): >>> - """index(self)""" >>> + """someobject[self]""" >>> return int(self) >> >> Changing the docstring to say "operator.index(self)" would be the >> clearest solution here. > I disagree. __add__ is documented as implementing +, not operator.add. That's because "+" is the idiomatic spelling. operator.index *is* the Python level spelling of obj.__index__() - there is no other way to spell it (other than calling the method explicitly, which is subtly different). >> (Choosing to accept arbitrary index objects as >> integer equivalents is up to the object being indexed, just like >> interpreting slices is - a dict, for example, will never invoke >> __index__ methods). > I honestly don’t know what the best fix is. We could copy the doc from > datamodel (“called whenever Python needs an integer object (such as in > slicing, or in the built-in bin(), hex() and oct() functions)”). I’ve > been told on IRC to let Mark Dickison decide how to fix the docstrings > in the numbers module (deleting them being of course an option: magic > methods are documented in the language reference, they don’t need > docstrings). Indeed. However, as a reference module for the numeric tower, it makes a certain amount of sense to keep the docstrings in this particular case. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Column offsets for attribute nodes
It should maybe be noted that the proposed patch would change that, too, so it would be the same behaviour for all three types (subscripts, calls, and attributes) again. Just more intuitive. :) 2010/12/27 Benjamin Peterson : > 2010/12/26 Sven Brauch : >> Hi there, >> >> I recently filed a feature request in the tracker to change the >> behaviour of the parser in terms of setting ranges on attribute AST >> nodes, because I'm working on an application which needs more >> information than is currently provided. I suggested to change the >> behaviour from >> foo.bar.baz # <- foo is said to start at column 0, bar at 0 and baz at >> 0 (current) >> to >> foo.bar.baz # <- foo starts at 0, bar at 3 and baz at 7 (suggestion) >> >> In that discussion, there's been different opinions about which >> behaviour is better; main arguments were "consistency" for the current >> and "usefulness" for the suggested behaviour. It has been proposed to >> ask the question on this list, that's why I'm doing that now. :) > > My argument against this change is that an attribute includes the > expression from which the attribute is being taken. This is consistent > with subscripts and calls, which both have the lineno and col_offset > of their source expressions. > > > > -- > Regards, > Benjamin > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Column offsets for attribute nodes
2010/12/26 Sven Brauch : > Hi there, > > I recently filed a feature request in the tracker to change the > behaviour of the parser in terms of setting ranges on attribute AST > nodes, because I'm working on an application which needs more > information than is currently provided. I suggested to change the > behaviour from > foo.bar.baz # <- foo is said to start at column 0, bar at 0 and baz at > 0 (current) > to > foo.bar.baz # <- foo starts at 0, bar at 3 and baz at 7 (suggestion) > > In that discussion, there's been different opinions about which > behaviour is better; main arguments were "consistency" for the current > and "usefulness" for the suggested behaviour. It has been proposed to > ask the question on this list, that's why I'm doing that now. :) My argument against this change is that an attribute includes the expression from which the attribute is being taken. This is consistent with subscripts and calls, which both have the lineno and col_offset of their source expressions. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fault handler updated, now disabled by default
Le dimanche 26 décembre 2010 à 14:10 +, exar...@twistedmatrix.com a écrit : > On 25 Dec, 10:31 pm, mer...@netwok.org wrote: > >>faulthandler is a module: enable the handler is simple as "import > >>faulthandler". > > > >That sounds like a source of unwanted behavior (aka problems) if the > >handler is enabled by 1Cpydoc faulthandler 1D or by a pkgutil walk. You > >may want to consider using a function to enable the functionality (and > >add one to disable it). > > Enormous +1. I don't know pkgutil. How does it work? In which case would it load the faulthandler module? faulthandler is currently only written in C. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Column offsets for attribute nodes
Hi there, I recently filed a feature request in the tracker to change the behaviour of the parser in terms of setting ranges on attribute AST nodes, because I'm working on an application which needs more information than is currently provided. I suggested to change the behaviour from foo.bar.baz # <- foo is said to start at column 0, bar at 0 and baz at 0 (current) to foo.bar.baz # <- foo starts at 0, bar at 3 and baz at 7 (suggestion) In that discussion, there's been different opinions about which behaviour is better; main arguments were "consistency" for the current and "usefulness" for the suggested behaviour. It has been proposed to ask the question on this list, that's why I'm doing that now. :) The thread can be found here: http://bugs.python.org/issue10769 So, which version do you think to be better: the current one or the suggested one? Best regards, Sven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/24/2010 02:03 PM, Raymond Hettinger wrote: On Dec 24, 2010, at 10:56 AM, Terry Reedy wrote: On 12/24/2010 11:09 AM, Michael Foord wrote: On 22/12/2010 02:26, Terry Reedy wrote: On 12/21/2010 7:17 AM, Michael Foord wrote: My first priority is that doc and code match. Close second is consistency (hence, ease of learning and use) between various AssertXs. Symmetrical diffs (element in first not in second, element in second not in first) solves the problem without imposing an order on the arguments. Where applicable, I prefer this as unambiguous output headings. Could you explain what you mean? I was referring back to an output example symmetric diff that was clipped somewhere along the way: In x not in y: ... In y not in x: ... rather than just using -,+ prefixes which are not necessarily self-explanatory. 'Not applicable' would refer to output from difflib which necessarily is ordered. FWIW, I think + and - prefixes are much better for diffs that some made-up verbiage. People are used to seeing diffs with + and -. Anything else will be so contrived that it's net effect will be to make the output confusing and hard to interpret. Agree. If you want, add two lines of explanation before the diff: + means "in x, not in y" - means "in y, not it x" The notion of "making symmetric" can easily get carried too far, which a corresponding loss of useability. I agree with this also. I don't understand the effort to make the tests be symmetric when many of the tests are non-symmetric. (see list below) I think the terms expected and actual are fine and help more than they hurt. I think of these as "actual result" and "expected result". A clearer terminology might be "expr" and "expected_result". Where a tests can be used *as if* they are symmetric, but the diff context is reversed, I think that that is ok. It just needs a entry in the docs that says that will happen if you do it. That won't break tests already written. Also notice (in the list below) that the use of 'a' and 'b' do not indicate a test is symmetric, but instead are used where they are *not-symmetric*. First and second could be used for those, but I think 'a' and 'b' have less mental luggage when it comes to visually seeing the meaning of the method signature in those cases. Tests where the order is not important usually use numbered but like arguments, such as "expr1" and "expr2" or "list1" and "list2". This makes sense to me. "obj1" and "obj2" are just two objects. The terms "x in y" and "x not in y" look like what you should get from containment or regex asserts. I guess what I'm try to say is think of the whole picture when trying to make improvements like these, an idea that works for one or two things may not scale well. Cheers, Ron Non-symmetric assert methods. assertDictContainsSubset(self, expected, actual, msg=None) assertFalse(self, expr, msg=None) assertGreater(self, a, b, msg=None) assertGreaterEqual(self, a, b, msg=None) assertIn(self, member, container, msg=None) assertIsInstance(self, obj, cls, msg=None) assertIsNone(self, obj, msg=None) assertIsNotNone(self, obj, msg=None) assertLess(self, a, b, msg=None) assertLessEqual(self, a, b, msg=None) assertNotIn(self, member, container, msg=None) assertIsInstance(self, obj, cls, msg=None) assertIsNone(self, obj, msg=None) assertIsNotNone(self, obj, msg=None) assertNotIn(self, member, container, msg=None) assertNotIsInstance(self, obj, cls, msg=None) assertRegex(self, text, expected_regex, msg=None) assertNotRegexMatches(self, text, unexpected_regex, msg=None) assertRaises(self, excClass, callableObj=None, *args, **kwargs) assertRaisesRegex(self, expected_exception, expected_regex, callable_obj=None, *args, **kwargs) assertRegex(self, text, expected_regex, msg=None) assertTrue(self, expr, msg=None) assertWarns(self, expected_warning, callable_obj=None, *args, **kwargs) assertWarnsRegex(self, expected_warning, expected_regex, callable_obj=None, *args, **kwargs) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87445 - python/branches/py3k/Lib/numbers.py
Le 24/12/2010 02:08, Nick Coghlan a écrit : > On Fri, Dec 24, 2010 at 4:41 AM, eric.araujo > wrote: >> Fix small inaccuracy: there is no index function > > Yes, there is, it just isn't a builtin - it lives in the operator module. Defining object.__index__ with operator.index seems pretty circular to me :) http://docs.python.org/dev/reference/datamodel#object.__index__ does it, but it should be fixed IMO. The difference between __int__ and __index__ is also not clear. >> def __index__(self): >> -"""index(self)""" >> +"""someobject[self]""" >> return int(self) > > Changing the docstring to say "operator.index(self)" would be the > clearest solution here. I disagree. __add__ is documented as implementing +, not operator.add. > (Choosing to accept arbitrary index objects as > integer equivalents is up to the object being indexed, just like > interpreting slices is - a dict, for example, will never invoke > __index__ methods). I honestly don’t know what the best fix is. We could copy the doc from datamodel (“called whenever Python needs an integer object (such as in slicing, or in the built-in bin(), hex() and oct() functions)”). I’ve been told on IRC to let Mark Dickison decide how to fix the docstrings in the numbers module (deleting them being of course an option: magic methods are documented in the language reference, they don’t need docstrings). Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fault handler updated, now disabled by default
On 25 Dec, 10:31 pm, mer...@netwok.org wrote: faulthandler is a module: enable the handler is simple as "import faulthandler". That sounds like a source of unwanted behavior (aka problems) if the handler is enabled by 1Cpydoc faulthandler 1D or by a pkgutil walk. You may want to consider using a function to enable the functionality (and add one to disable it). Enormous +1. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
