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
Hi,
it seems that Py3 doesn't support setting a "nonlocal" value as part of the
"nonlocal" command
Python 3.2a4+ (py3k:86480, Nov 16 2010, 16:43:22)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def x():
... y = 5
... def f():
... nonlocal y = 6
File "<stdin>", line 4
nonlocal y = 6
^
SyntaxError: invalid syntax
even though the PEP clearly describes this feature.
http://www.python.org/dev/peps/pep-3104/#proposed-solution
Either the PEP or the implementation should be updated. Personally, I think
the PEP should be changed as I think that the syntax complicates the
grammar more than it's worth. Also, the moratorium applies here, given that
Py3.1 does not implement this.
Comments?
Stefan
.. and here's my original reply to Nick, which was also intended to go
to the list. Sorry, folks.
Mark
---------- Forwarded message ----------
From: Mark Dickinson <dickinsm(a)gmail.com>
Date: Mon, Dec 27, 2010 at 10:27 AM
Subject: Re: [Python-Dev] Range __contains__ and objects with __index__ methods
To: Nick Coghlan <ncoghlan(a)gmail.com>
On Mon, Dec 27, 2010 at 12:15 AM, Nick Coghlan <ncoghlan(a)gmail.com> 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 [...]
Is seems to me that there are two separate issues here. Namely, (1)
Determine the semantics of 'x in range(...)' for an object x that
implements __index__, and (2) implement the containment check
efficiently.
At the moment, it looks as though the __index__ method is ignored
entirely for the containment check, so you're proposing a change in
semantics. If/when that change in semantics is made, fixing up the
code to do the containment check efficiently seems like it should be a
straightforward task.
With the proposed change in semantics, the simple definition (x in
range(...) iff x == y for some element y of range(...)) no longer
holds. I'm not convinced (but not unconvinced either) that it's worth
breaking that simplicity.
Mark
Bah. I meant to send this to the list. (I suspect that Nick also
meant to send his reply to the list.)
On Mon, Dec 27, 2010 at 12:43 PM, Mark Dickinson <dickinsm(a)gmail.com> wrote:
> On Mon, Dec 27, 2010 at 12:23 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
>> The symmetry only breaks for a class that breaks the invariant:
>>
>> x == operator.index(x)
>>
>> Failing to guarantee that invariant seems to violate the whole spirit
>> of operator.index().
>
> Agreed. (Though one also needs transitivity, symmetry, etc., of
> equality, since what we really need is that x == y is interchangeable
> with operator.index(x) == y.)
>
>> Perhaps this is what we should be documenting as
>> the true distinguishing feature between the intended semantics of
>> __index__ and the semantics of __int__?
>
> Hmm. Perhaps. For me, this doesn't fully capture the intent of
> __index__, though.
>
> So the semantics (ignoring performance issues for now) would become:
>
> def range_contains(self, x)
> try:
> i = operator.index(x)
> except TypeError:
> i = x
> return any(i == y for y in self)
>
> ?
>
> This change sounds fine to me; it would be good to have a
> documentation note somewhere indicating that the range implementation
> assumes x == index(x), though. This might belong in the range
> documentation, or perhaps the __index__ method documentation could
> indicate that some builtins might have unpredictable behaviour if the
> identity is violated.
>
> Mark
>
On Fri, Dec 24, 2010 at 4:41 AM, eric.araujo <python-checkins(a)python.org> wrote:
> Author: eric.araujo
> Date: Thu Dec 23 19:41:33 2010
> New Revision: 87445
>
> Log:
> Fix small inaccuracy: there is no index function
Yes, there is, it just isn't a builtin - it lives in the operator module.
> def __index__(self):
> - """index(self)"""
> + """someobject[self]"""
> return int(self)
Changing the docstring to say "operator.index(self)" would be the
clearest solution here. (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).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
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 | ncoghlan(a)gmail.com | Brisbane, Australia
Hi,
Thanks to all your useful remarks, I improved my patch twice (version 10
and 11). I think that the last version (11) addresses all reported
issues. The most notable change is that the fault handler is now
disabled by default. It fixes also the function getting the thread
state, it now works in all cases (especially if the thread causing the
fault doesn't hold the GIL).
Summary of the patch (#8863):
- Add an optional fault handler for SIGSEGV, SIGFPE, SIGILL and SIGBUS
signals displaying the Python backtrace
- Setting PYTHONFAULTHANDLER environment variable, or using
"-X faulthandler" command line option, enables it
- If it's enabled, display also the Python backtrace on a fatal error
Use case: when a program crashs, the user reruns its application with
the fault handler enabled and tries to reproduce the crash. He/She can
send the Python backtrace to the developer, or use it directly (if
he/she understands it).
I think that this patch helps to isolate crashs in Python or libraries,
especially if the user doesn't have all tools needed to get a Python
backtrace (on a crash) and the developer is unable to reproduce the bug
(because it doesn't have the same OS or libraries). For example, gdb 7
and python-gdb.py are rare on Windows :-) (even on Linux!)
So, do you agree with the fault handler? Does someone want to give a
last review because I commit it?
http://bugs.python.org/issue8863
Victor
On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
ezio.melotti <python-checkins(a)python.org> wrote:
> Author: ezio.melotti
> Date: Sat Dec 18 21:00:04 2010
> New Revision: 87389
>
> Log:
> #10573: use actual/expected consistently in unittest methods.
IMHO, this should be reverted. The API currently doesn't treat these
arguments differently, so they should really be labeled "first" and
"second". Otherwise, the user will wrongly assume that the signature is
asymmetric and that they should be careful about which order they pass
the arguments in.
Regards
Antoine.
Eh, no. That is a different user. Alan didn't have Developer tracker
privileges yet though, so I fixed that. Please revert.
Georg
Am 24.12.2010 22:59, schrieb terry.reedy:
> Author: terry.reedy
> Date: Fri Dec 24 22:59:03 2010
> New Revision: 87478
>
> Log:
> Match current tracker name, though I do not know if still active.
>
>
> Modified:
> python/branches/py3k/Misc/maintainers.rst
>
> Modified: python/branches/py3k/Misc/maintainers.rst
> ==============================================================================
> --- python/branches/py3k/Misc/maintainers.rst (original)
> +++ python/branches/py3k/Misc/maintainers.rst Fri Dec 24 22:59:03 2010
> @@ -247,7 +247,7 @@
> xml.sax.saxutils
> xml.sax.xmlreader
> xmlrpc loewis
> -zipfile alanmcintyre
> +zipfile aimacintyre
> zipimport
> zlib
> ================== ===========