Mailman 3 May 2011 - Python-ideas

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley Dec. 16, 2020

Dec. 16, 2020

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich

10 15

i18n and Python tracebacks
by Andre Roberge Oct. 28, 2012

Oct. 28, 2012

I think it would be a good idea if Python tracebacks could be translated into languages other than English - and it would set a good example. For example, using French as my default local language, instead of >>> 1/0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero I might get something like >>> 1/0 Suivi d'erreur (appel le plus récent en dernier) : Fichier "<stdin>", à la ligne 1, dans <module> ZeroDivisionError: division entière ou modulo par zéro André

9 15

Cofunctions PEP - Revision 4
by Greg Ewing Oct. 13, 2012

Oct. 13, 2012

Here's an updated version of the PEP reflecting my recent suggestions on how to eliminate 'codef'. PEP: XXX Title: Cofunctions Version: $Revision$ Last-Modified: $Date$ Author: Gregory Ewing <greg.ewing(a)canterbury.ac.nz> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Feb-2009 Python-Version: 3.x Post-History: Abstract ======== A syntax is proposed for defining and calling a special type of generator called a 'cofunction'. It is designed to provide a streamlined way of writing generator-based coroutines, and allow the early detection of certain kinds of error that are easily made when writing such code, which otherwise tend to cause hard-to-diagnose symptoms. This proposal builds on the 'yield from' mechanism described in PEP 380, and describes some of the semantics of cofunctions in terms of it. However, it would be possible to define and implement cofunctions independently of PEP 380 if so desired. Specification ============= Cofunction definitions ---------------------- A cofunction is a special kind of generator, distinguished by the presence of the keyword ``cocall`` (defined below) at least once in its body. It may also contain ``yield`` and/or ``yield from`` expressions, which behave as they do in other generators. From the outside, the distinguishing feature of a cofunction is that it cannot be called the same way as an ordinary function. An exception is raised if an ordinary call to a cofunction is attempted. Cocalls ------- Calls from one cofunction to another are made by marking the call with a new keyword ``cocall``. The expression :: cocall f(*args, **kwds) is evaluated by first checking whether the object ``f`` implements a ``__cocall__`` method. If it does, the cocall expression is equivalent to :: yield from f.__cocall__(*args, **kwds) except that the object returned by __cocall__ is expected to be an iterator, so the step of calling iter() on it is skipped. If ``f`` does not have a ``__cocall__`` method, or the ``__cocall__`` method returns ``NotImplemented``, then the cocall expression is treated as an ordinary call, and the ``__call__`` method of ``f`` is invoked. Objects which implement __cocall__ are expected to return an object obeying the iterator protocol. Cofunctions respond to __cocall__ the same way as ordinary generator functions respond to __call__, i.e. by returning a generator-iterator. Certain objects that wrap other callable objects, notably bound methods, will be given __cocall__ implementations that delegate to the underlying object. Grammar ------- The full syntax of a cocall expression is described by the following grammar lines: :: atom: cocall | <existing alternatives for atom> cocall: 'cocall' atom cotrailer* '(' [arglist] ')' cotrailer: '[' subscriptlist ']' | '.' NAME Note that this syntax allows cocalls to methods and elements of sequences or mappings to be expressed naturally. For example, the following are valid: :: y = cocall self.foo(x) y = cocall funcdict[key](x) y = cocall a.b.c[i].d(x) Also note that the final calling parentheses are mandatory, so that for example the following is invalid syntax: :: y = cocall f # INVALID New builtins, attributes and C API functions -------------------------------------------- To facilitate interfacing cofunctions with non-coroutine code, there will be a built-in function ``costart`` whose definition is equivalent to :: def costart(obj, *args, **kwds): try: m = obj.__cocall__ except AttributeError: result = NotImplemented else: result = m(*args, **kwds) if result is NotImplemented: raise TypeError("Object does not support cocall") return result There will also be a corresponding C API function :: PyObject *PyObject_CoCall(PyObject *obj, PyObject *args, PyObject *kwds) It is left unspecified for now whether a cofunction is a distinct type of object or, like a generator function, is simply a specially-marked function instance. If the latter, a read-only boolean attribute ``__iscofunction__`` should be provided to allow testing whether a given function object is a cofunction. Motivation and Rationale ======================== The ``yield from`` syntax is reasonably self-explanatory when used for the purpose of delegating part of the work of a generator to another function. It can also be used to good effect in the implementation of generator-based coroutines, but it reads somewhat awkwardly when used for that purpose, and tends to obscure the true intent of the code. Furthermore, using generators as coroutines is somewhat error-prone. If one forgets to use ``yield from`` when it should have been used, or uses it when it shouldn't have, the symptoms that result can be extremely obscure and confusing. Finally, sometimes there is a need for a function to be a coroutine even though it does not yield anything, and in these cases it is necessary to resort to kludges such as ``if 0: yield`` to force it to be a generator. The ``cocall`` construct address the first issue by making the syntax directly reflect the intent, that is, that the function being called forms part of a coroutine. The second issue is addressed by making it impossible to mix coroutine and non-coroutine code in ways that don't make sense. If the rules are violated, an exception is raised that points out exactly what and where the problem is. Lastly, the need for dummy yields is eliminated by making it possible for a cofunction to call both cofunctions and ordinary functions with the same syntax, so that an ordinary function can be used in place of a cofunction that yields zero times. Record of Discussion ==================== An earlier version of this proposal required a special keyword ``codef`` to be used in place of ``def`` when defining a cofunction, and disallowed calling an ordinary function using ``cocall``. However, it became evident that these features were not necessary, and the ``codef`` keyword was dropped in the interests of minimising the number of new keywords required. The use of a decorator instead of ``codef`` was also suggested, but the current proposal makes this unnecessary as well. It has been questioned whether some combination of decorators and functions could be used instead of a dedicated ``cocall`` syntax. While this might be possible, to achieve equivalent error-detecting power it would be necessary to write cofunction calls as something like :: yield from cocall(f)(args) making them even more verbose and inelegant than an unadorned ``yield from``. It is also not clear whether it is possible to achieve all of the benefits of the cocall syntax using this kind of approach. Prototype Implementation ======================== An implementation of an earlier version of this proposal in the form of patches to Python 3.1.2 can be found here: http://www.cosc.canterbury.ac.nz/greg.ewing/python/generators/cofunctions.h… If this version of the proposal is received favourably, the implementation will be updated to match. Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

11 29

Adding 'bytes' as alias for 'latin_1' codec.
by INADA Naoki June 2, 2011

June 2, 2011

Hi, all. There are some situation that I want to use bytes as a string in real world. (I use the 'bstr' for bytes as a string below) Sadly, Python 3's bytes is not bytestring. For example, when I want to make 'cat -n' that is transparent to encoding, Python 3 doesn't permit b'{0:6d}'.format(n) and '{0:6d}'.format(n).encode('ascii') is circuitous way against simple requirements. I think the best way to handle such situation with Python 3 is using 'latin1' codec. For example, encoding transparent 'cat -n' is: import sys fin = open(sys.stdin.fileno(), 'r', encoding='latin1') fout = open(sys.stdout.fileno(), 'w', encoding='latin1') for n, L in enumerate(fin): fout.write('{0:5d}\t{1}'.format(n, L)) If using 'latin1' is Pythonic way to handle encoding transparent string, I think Python should provide another alias like 'bytes'. Any thoughts? -- INADA Naoki <songofacandy(a)gmail.com>

16 57

Minor tweak to PEP 8?
by Mike Meyer June 2, 2011

June 2, 2011

PEP eight has an interesting omission in the "Code Layout" section. It doesn't say how to indent continuation lines when code is wrapped to comply with the line length limits. It has examples, but no textual guides. Which means you can do a rock-stupid word warp (with no indentation on the continuation lines), point at the resulting mess, and say "See? If we follow this part of the PEP, we get really ugly code!". Mail doing just that is what prompted this suggestion. I therefore propose adding a sentence or two to this section, something along the lines of: The continuation line(s) should be indented to reflect the structure of the statement being continued. This should be at least one space beyond the first open parenthesis that is not closed on the continued line, if present. Nothing hard and fast, just a requirement to use good sense and the minimal indent resulting from doing so. <mike -- Mike Meyer <mwm(a)mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

11 20

Threading hooks and disable gc per thread
by Christian Heimes May 27, 2011

May 27, 2011

Hello, today I've spent several hours debugging a segfault in JCC [1]. JCC is a framework to wrap Java code for Python. It's most prominently used in PyLucene [2]. You can read more about my debugging in [3] With JCC every Python thread must be registered at the JVM through JCC. An unattached thread, that accesses a wrapped Java object, leads to errors and may even cause a segfault. Accessing also includes garbage collection. A code line like a = {} or "a b c".split() can segfault since the allocation of a dict or a bound method runs through _PyObject_GC_New(), which may trigger a cyclic garbage collection run. If the current thread isn't attached to the JVM but triggers a gc.collect() with some Java objects in a cycle, the interpreter crashes. It's quite complicated and hard to "fix" third party tools to attach all threads created in the third party library. The issue could be solved with a simple on_thread_start hook in the threading module. However there is more to it. In order to free memory threads must also be detached from the JVM, when a thread has ended. A second on_thread_stop hook isn't enough since the bound methods may also lead to a gc.collect() run after the thread is detached. I propose three changes to Python in order to fix the issue: on thread start hook -------------------- Similar to the atexit module, third party modules can register a callable with *args and **kwargs. The functions are called inside the newly created thread just before the target is called. The best place for the hook list is threading.Thread._bootstrap_inner() right before the try: self.run() except: block. Exceptions are ignored during the call but reported to the user at the end (same as atexit's atexit_callfunc()) on thread end hook ------------------ Same as on thread start hook but the callables are called inside the dying thread after self.run(). gc.disable_thread(), gc.enable_thread(), gc.isenabled_thread() -------------------------------------------------------------- Right now almost any code can trigger a gc.collect() run non-deterministicly. Some application like JCC want to control if gc.collect() is wanted on a thread level. This could be solved with a new flat in PyThreadState. PyThreadState->gc_enabled is enabled by default. When the flag is false, _PyObject_GC_Malloc() doesn't start a gc.collect() run for that thread. The collection is delayed until another thread or the main thread triggers it. The three functions should also have a C equivalent so C code can prevent gc in a thread. Thoughs? Christian [1] http://lucene.apache.org/pylucene/jcc/index.html [2] http://lucene.apache.org/pylucene/ [3] http://mail-archives.apache.org/mod_mbox/lucene-pylucene-dev/201105.mbox/br…

5 7

Suggestion: Integrate the script "pindent.py" as standard command for formatting pyhton code
by Serge Hulne May 27, 2011

May 27, 2011

Suggestion: Integrate the script "pindent.py" as standard command for formatting pyhton code Here is the link; http://svn.python.org/projects/python/trunk/Tools/scripts/pindent.py Pindent stands for "Pyton indent": Goal : 1. It provides bloc delimiters (end of blocks) in the for of comments (like "#end if" or "#end for" etc ... ) 2. This allows one to check / restore the indentation of Python code, in cases where> 1. A copy/paste went wrong 2. The indentation of a Python source got corrupted when the script was posted on web page, send via email etc ... 3. Standardise (fix) sources which happily mix whitespaces and tabs 4. Make Python code more readable for developers used to end of blocs delimiters (Ruby, C, C++, C#,Java, etc ...) Basically the idea is the same as the Go language "gofmt" (Go format). Example: #------------------- - Before using pindent: #!/usr/bin env python i = 0 for c in "hello world": if c == 'l': i+=1 print "number of occurrences of `l` :", i #------------------ - After using indent: #!/usr/bin env python i = 0 for c in "hello world": if c == 'l': i+=1 print "number of occurrences of `l` :", i # end if # end for Serge Hulne

12 12

Python 3.x and bytes
by Ethan Furman May 24, 2011

May 24, 2011

As those who have to work with byte strings know, when retrieving a single character from a byte string, what you get back is not a byte string, but an int -- a rather important distinction from unicode strings (str). This has the frustrating side-effect of b'abc'[2] == b'c' being False. It is far too late to change that particular behavior of the byte string (returning int's, that is) -- however, it may not be too late for a non-backwards-incompatible change: have the bytes class' __eq__ method be modified so that it 1) checks to see if the bytes instance is length 1 2) checks to see if a) the other object is an int, and b) 0 <= other_obj < 256 3) if 1 and 2, make the comparison between the int and its single element instead of returning NotImplemented? This makes sense to me -- after all, the bytes class is an array of ints in range(256); it is a special case, but doesn't feel any more special than passing an int into bytes() giving a string of that many null bytes; and it would get rid of the, in my opinion ugly, idiom of some_var[i:i+1] == b'd' It would also not require a new literal syntax. Thoughts? ~Ethan~

13 21

Implementing __dir__ (moving dir implementation to object.__dir__?)
by Michael Foord May 24, 2011

May 24, 2011

Hello all, I'm looking at implementing __dir__ for a class (mock.Mock as it happens) to include some dynamically added attributes, the canonical use case according to the documentation: http://docs.python.org/dev/reference/datamodel.html?highlight=__dir__#objec… What I would like to do is report all the "standard attributes", and then add any dynamically created attributes. So the question is, how do I obtain the "standard list" (the list that dir would normally report in the absence of a custom __dir__ implementation)? There is no object.__dir__ (despite the fact that this is how it is documented...) and obviously calling dir(self) within __dir__ is doomed to failure. The best I have come up with is: def __dir__(self): return dir(type(self)) + list(self.__dict__) + self._get_dynamic_attributes() This works (absent multiple inheritance), but it would be nice to just be able to do: def __dir__(self): standard = super().__dir__() return standard + self._get_dynamic_attributes() Moving the relevant parts of the implementation of dir into object.__dir__ would be one way to solve that. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

3 4

__implements__ on arguments to ABCMeta.register
by Eric Snow May 23, 2011

May 23, 2011

ABCMeta.register is great. It adds the cls argument to the _abc_registry of the ABC. However, the class that was passed in does not get touched. If you then want to find out to which classes a class has been registered, you can't find out from that class. Whereas your can find out from an abstract base class which classes have been registered to it. I propose having ABCMeta.register add/update a special method __implements__ to the class that is getting registered. This would not be done to builtin/extension types. It adds the ABC to the __implements__ of the subclass that is getting registered. Something along these lines, right before the final return in the method: if not hasattr(subclass, "__implements__"): try: subclass.__implements__ = {cls} except TypeError: pass else: subclass.__implements__.add(cls) This is a small addition, but I realize it [potentially] adds another special method to classes, so it's not trivial. The use case is that I want to be able to validate that a class implements all of the abstract methods of all the classes to which it has been registered. I don't have a programmatic way of discovering that set without asking every class out there. This is an easy way to accomplish this (for non-extension/non-builtin types). An alternative is to subclass ABCMeta and tack this on, but that only works for my ABCs. Another is to use a class decorator to do this any place I do a register (or even to do the register too), but again, only for the places that I do the registration. Anyway, if it's useful to me then it may be useful to others, so I wanted to put this out there. I expect this has come up before, particularly during discussions about PEP 3119. However, I wasn't able to track down anything specifically about doing this sort of "reverse registration". And, of course, I may be overestimating the value of this functionality. If this does not seem that valuable to anyone else, then no big deal. :) -eric

3 5