Mailman 3 December 2011 - Python-Dev

generators and ceval
by Ron Adam 16 Dec '11

16 Dec '11

Hi, I Just added issue 13607 with a patch that removes the generator specific checks and code out of the ceval PyEval_EvalFrameEx() function. Those parts where moved up into the generator gen_send_ex() function. Doing that removed the generator flag checks from the eval loop and made it a bit cleaner. In order to do that, I needed to give generators a why to look at the 'why' value. Doing that also cleaned up the code in gen_sendex() as it can use the 'why' in a select instead of several indirect if tests. http://bugs.python.org/issue13607 Altogether it made yields about 10% faster, and everything else about 2%-3% faster (on average). But it does need to be checked. Cheers, Ron

1 0

Re: [Python-Dev] [Python-checkins] cpython: improve abstract property support (closes #11610)
by Nick Coghlan 16 Dec '11

16 Dec '11

On Fri, Dec 16, 2011 at 6:34 AM, benjamin.peterson <python-checkins(a)python.org> wrote: > +abc > +--- > + > +Improved support for abstract base classes containing descriptors composed with > +abstract methods. The recommended approach to declaring abstract descriptors is > +now to provide :attr:`__isabstractmethod__` as a dynamically updated > +property. The built-in descriptors have been updated accordingly. > + > + * :class:`abc.abstractproperty` has been deprecated, use :class:`property` > + with :func:`abc.abstractmethod` instead. > + * :class:`abc.abstractclassmethod` has been deprecated, use > + :class:`classmethod` with :func:`abc.abstractmethod` instead. > + * :class:`abc.abstractstaticmethod` has been deprecated, use > + :class:`property` with :func:`abc.abstractmethod` instead. > + > +(Contributed by Darren Dale in :issue:`11610`) s/property/staticmethod/ in the final bullet point here. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Compiling the source without stat
by Hossein 16 Dec '11

16 Dec '11

Hi. I just started to port latest python 2.7.2 to another platform (don't think you're eager to know... well it's CASIO ClassPad). And I faced a "minor" problem... It hasn't got stat or fstat or anything. (It supports a very limited set of c std lib). As pyport.c suggested, i defined both DONT_HAVE_STAT and DONT_HAVE_FSTAT, but problems only began. It failed to compile most of import.c, particularly because it fell into the wrong `#if !defined(PYOS_Something)' blocks. Sometimes it just fell into an #else part which assumed stat are available. So although HAVE_STAT is meant to control file operations, most of the source code aren't implement to use it. You see how "minor" the problem was? So now I need advice from developers. Is there a fix for it? What a question... definitely no replacement to stat. It's 99% definite that I can't compile further without touching the source code. I have to #define my own PYOS_whatever and handle files in my own way. In that case where should my special file handling cases go? I saw some marshal.c code which seemed it wants to abstract away platform's file handling from source code; but from what I understood it can't be made to use alternate file handling methods. If there is anything I should do (maybe show you my handmade pyconfig.h?) tell me. [My first post in a mailing list... Should I say] Best Regards, Hossein [in here?]

7 8

Re: [Python-Dev] [Python-checkins] cpython: input() in this sense is gone
by Nadeem Vawda 16 Dec '11

16 Dec '11

On Thu, Dec 15, 2011 at 10:44 PM, benjamin.peterson <python-checkins(a)python.org> wrote: > +# eval_input is the input for the eval() functions. Shouldn't this be "function" rather than "functions"?

1 0

Proposed changes to provide compression support for rotated log files
by Vinay Sajip 16 Dec '11

16 Dec '11

In response to http://bugs.python.org/issue13516 I'm thinking of implementing some changes in the rotating file handlers, as outlined here: http://plumberjack.blogspot.com/2011/12/improved-flexibility-for-log-file.h… The changes (including tests) are almost ready to check in, but I thought I'd give any one here who's interested a chance to comment, in case they can spot any shortcomings of the approach I suggest. Regards, Vinay Sajip

3 4

readd u'' literal support in 3.3?
by Chris McDonough 15 Dec '11

15 Dec '11

On the heels of Armin's blog post about the troubles of making the same codebase run on both Python 2 and Python 3, I have a concrete suggestion. It would help a lot for code that straddles both Py2 and Py3 to be able to make use of u'' literals. It would seem to be an easy thing to reenable (see http://www.reddit.com/r/Python/comments/n3q7q/thoughts_on_python_3_armin_ro… ) . It would seem to cost very little in terms of maintenance, and not much in docs. It would make it possible to share code like this across py2 and py3: a = u'foo' Instead of (with e.g. six): a = u('foo') Or: from __future__ import unicode_literals a = 'foo' I recognize that the last option is probably the way "its meant to be done", but in reality it's just more practical to not fail when literal notation is more specific than strictly necessary. - C

29 112

PyUnicodeObject / PyASCIIObject questions
by Jim Jewett 14 Dec '11

14 Dec '11

(see http://www.python.org/dev/peps/pep-0393/ and http://hg.python.org/cpython/file/6f097ff9ac04/Include/unicodeobject.h ) typedef struct { PyObject_HEAD Py_ssize_t length; Py_hash_t hash; struct { unsigned int interned:2; unsigned int kind:2; /* now 3 in implementation */ unsigned int compact:1; unsigned int ascii:1; unsigned int ready:1; } state; wchar_t *wstr; } PyASCIIObject; typedef struct { PyASCIIObject _base; Py_ssize_t utf8_length; char *utf8; Py_ssize_t wstr_length; } PyCompactUnicodeObject; typedef struct { PyCompactUnicodeObject _base; union { void *any; Py_UCS1 *latin1; Py_UCS2 *ucs2; Py_UCS4 *ucs4; } data; } PyUnicodeObject; (1) Why is PyObject_HEAD used instead of PyObject_VAR_HEAD? It is because of the names (.length vs .size), or a holdover from when unicode (as opposed to str) did not expect to be compact, or is there a deeper reason? (2) Why does PyASCIIObject have a wstr member, and why does PyCompactUnicodeObject have wstr_length? As best I can tell from the PEP or header file, wstr is only meaningful when either: (2a) wstr is shared with (and redundant to) the canonical representation -- which will therefore not be ASCII. So wstr (and wstr_length) shouldn't need to be represented explicitly, and certainly not in the PyASCIIObject base. or (2b) The string is a "Legacy String" (and PyUnicode_READY has not been called). Because it is a Legacy String, the object header must already be a full PyUnicodeObject, and the wstr fields could at least be stored there. I'm also not sure why wstr can't be stored in the existing .data member -- once PyUnicode_READY is called, it will either be there (shared) or be discarded. Are there other times when the wstr will be explicitly re-filled and cached? (3) I would feel much less nervous if the remaining 4 values of PyUnicode_Kind were explicitly reserved, and the macros raised an error when they showed up. (Better still would be to allow other values, and to have the macros delegate to some attribute on the (sub) type object.) Discussion on py-ideas strongly suggested that people should not be rolling their own string string representations, and that it won't really save as much as people think it will, etc ... but I'm not sure that saying "do it without inheritance" is the best solution -- and that is what treating kind as an exhaustive list does. -jJ

5 6

Re: [Python-Dev] readd u'' literal support in 3.3?
by Lennart Regebro 14 Dec '11

14 Dec '11

On Tue, Dec 13, 2011 at 23:38, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > On Wed, Dec 14, 2011 at 8:17 AM, Michael Foord > <fuzzyman(a)voidspace.org.uk> wrote: >> More specifically "six" [1] is the name of Benjamin Peterson's support >> package to help write code that works on both 2 and 3. So the idea is that >> the conversion isn't just a straight syntax conversion - but that it [could] >> generate code using this library. > > The thing is, the code you want to generate varies depending on > whether you want to target 2.6+, or include 2.5 and earlier. Sure. This is different fixers, and then script to run it could have a parameter for version. I'd expect though that a 2to6 first targets 2.6+, and possibly never end up supporting 2.5 at all. I do realize there still is 2.4 out in the wild, but fewer and fewer people need to support it, and the effort to support it is much higher. > String translation is also an open question. For some codebases, you > want both u"" and "" to translate to a Unicode "" (either in Py3k or > via the future import), but if a code base deals with WSGI-style > native strings (by means of u"" for text, "" for native, b"" for > binary), then the more appropriate translation is to use the future > import and map them to "", str("") and b"" respectively. Yeah, that can't be done automatically. There is no generic way to determine if a string should be binary, unicode or native.

1 0

str.format implementation
by Ben Wolfson 13 Dec '11

13 Dec '11

Hi, I'm hoping to get some kind of consensus about the divergences between the implementation and documentation of str.format (http://mail.python.org/pipermail/python-dev/2011-June/111860.html and the linked bug report contain examples of the divergences). These pertain to the arg_name, attribute_name, and element_index fields of the grammar in the docs: replacement_field ::= "{" [field_name] ["!" conversion] [":" format_spec] "}" field_name ::= arg_name ("." attribute_name | "[" element_index "]")* arg_name ::= [identifier | integer] attribute_name ::= identifier element_index ::= integer | index_string index_string ::= <any source character except "]"> + Nothing definitive emerged from the last round of discussion, and as far as I can recall there are now three proposals for what kind of changes might be worth making: (1) the implementation should conform to the docs;* (2) like (1) with the change that element_index should be changed to "integer | identifier" (rendering index_string otiose); (3) like (1) with the change that index_string should be changed to '<any source character except "]", "}", or "{">'. * the docs link "integer" to http://docs.python.org/reference/lexical_analysis.html#grammar-token-integer but the current implementation only allows decimal integers, which seems reasonable and worth retaining. (2) was suggested by Greg Ewing on python-dev and (3) by Petri Lehtinen in the bug report. (Petri actually suggested that braces be disallowed except for the nesting in the format_spec, but it comes to the same thing.) None of these should be difficult to implement; patches exist for (1) and (2). (2) and (3) would lead to format strings that are easier to for the programmer to visually parse; (1) would make the indexing part of the replacement field conform more closely to the way indexing with strings behaves in Python generally, where arbitrary strings can be used. (It wouldn't conform exactly, obviously, since ']' would still be excluded.) I personally would prefer (1) to (2) or (3), and (3) to (2), had I my druthers, but it doesn't matter a *whole* lot to me; I'd prefer any of them to nothing (or to changing the docs to reflect the current batty behavior). -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry]

5 4

IEEE/ISO draft on Python vulnerabilities
by Eric Snow 13 Dec '11

13 Dec '11

re-sending with subject :) On Mon, Dec 12, 2011 at 2:44 PM, Eric Snow <ericsnowcurrently(a)gmail.com> wrote: > Guido posted this on Google+: > >> IEEE/ISO are working on a draft document about Python vulunerabilities: http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-03… (in the context of a larger effort to classify vulnerabilities in all languages: ISO/IEC TR 24772:2010, available from ISO at no cost at: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html (its link is near the bottom of the web page). > > Will this document have a broad use, such that we should make sure it > is accurate (to avoid any future confusion)? I skimmed through and > found that it covers a lot of ground, not necessarily about > vulnerabilities, with some inaccuracies but not a ton that I noticed. > If it doesn't matter then no big deal. Just thought I'd bring it up. > > -eric

4 4