Python-Dev December 2010

python-dev@python.org

110 participants
114 discussions

Re: [Python-Dev] r87518 - python/branches/py3k/Parser/tokenizer.c

by Georg Brandl

Am 27.12.2010 21:12, schrieb victor.stinner: > Author: victor.stinner > Date: Mon Dec 27 21:12:13 2010 > New Revision: 87518 > > Log: > Issue #10778: decoding_fgets() decodes the filename from the filesystem > encoding instead of UTF-8. > > > Modified: > python/branches/py3k/Parser/tokenizer.c > > Modified: python/branches/py3k/Parser/tokenizer.c > ============================================================================== > --- python/branches/py3k/Parser/tokenizer.c (original) > +++ python/branches/py3k/Parser/tokenizer.c Mon Dec 27 21:12:13 2010 > @@ -545,6 +545,7 @@ > { > char *line = NULL; > int badchar = 0; > + PyObject *filename; > for (;;) { > if (tok->decoding_state == STATE_NORMAL) { > /* We already have a codec associated with > @@ -585,12 +586,16 @@ > if (badchar) { > /* Need to add 1 to the line number, since this line > has not been counted, yet. */ > - PyErr_Format(PyExc_SyntaxError, > - "Non-UTF-8 code starting with '\\x%.2x' " > - "in file %.200s on line %i, " > - "but no encoding declared; " > - "see http://python.org/dev/peps/pep-0263/ for details", > - badchar, tok->filename, tok->lineno + 1); > + filename = PyUnicode_DecodeFSDefault(tok->filename); > + if (filename != NULL) { > + PyErr_Format(PyExc_SyntaxError, > + "Non-UTF-8 code starting with '\\x%.2x' " > + "in file %.200U on line %i, " > + "but no encoding declared; " > + "see http://python.org/dev/peps/pep-0263/ for details", > + badchar, filename, tok->lineno + 1); > + Py_DECREF(filename); > + } Hmm, and in case decoding fails, we return a Unicode error (without context) instead of a syntax error? Doesn't seem like a good trade-off when the file name is just displayed in a message. Georg

10 years, 7 months

Column offsets for attribute nodes

by 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. :) 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

10 years, 7 months

Issue #6210: Exception Chaining missing method for suppressing context

by Ethan Furman

I see the last comment was added on the 4th. Where should continued discussion take place -- bug-tracker, python-dev, ... ? ~Ethan~

10 years, 7 months

nonlocal x = value

by Stefan Behnel

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

10 years, 7 months

Fwd: Range __contains__ and objects with __index__ methods

by Mark Dickinson

.. 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

10 years, 7 months

Re: [Python-Dev] Range __contains__ and objects with __index__ methods

by Mark Dickinson

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 >

10 years, 7 months

Re: [Python-Dev] [Python-checkins] r87445 - python/branches/py3k/Lib/numbers.py

by Nick Coghlan

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

10 years, 7 months

Range __contains__ and objects with __index__ methods

by Nick Coghlan

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

10 years, 7 months

Fault handler updated, now disabled by default

by Victor Stinner

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

10 years, 7 months

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

by Antoine Pitrou

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.

10 years, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev December 2010