Mailman 3 March 2011 - Python-ideas

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

16 Dec '20

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 28 Oct '12

28 Oct '12

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 13 Oct '12

13 Oct '12

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 a half-float (16-bit) type to PEP 3118 (and possibly the struct module?)
by Eli Stevens (Gmail) 05 Apr '11

05 Apr '11

Hello, Numpy 1.6.0 adds support for a half-float (16-bit) data type, but cannot currently export a buffer interface to the data, since the closest type that PEP 3118 supports is an unsigned short ('H'). This makes working with the data from outside numpy (for example, from Cython) difficult, since even if numpy were to expose a buffer interface to the data, it's unclear that the data needs special treatment to interpret correctly (numpy does this with bit shifting functions to convert it to a float32, but it has access to the array dtype which isn't available through the buffer interface, per my understanding). What would be required to get a float16 data type added to PEP 3118 (either implicitly via inclusion of the struct module, or explicitly in the PEP itself)? I'm not currently a contributor to python, numpy or cython, but am prepared to provide patches. Some of my exploratory work for numpy and cython (which is my driving use case) is below. Numpy seems to use the 'e' format character, so I stuck with that. Thanks, Eli http://en.wikipedia.org/wiki/Half_precision_floating-point_format https://github.com/wickedgrey/cython https://github.com/wickedgrey/numpy

10 27

namedtuple() subclasses again
by Jan Kaliszewski 31 Mar '11

31 Mar '11

Hello, Another thoughts (and use cases) about namedtuple-DRY-matter and (what is more important) subclassing namedtuple() classes: Quite often I need to create my own named tuple class(es) with some additional methods or modifications of existing ones (most often: a custom version of __repr__()). Now I must write something like: _MyNamedTupleBase = namedtuple('MyNamedTuple', ('one_field', 'another_field', 'and_another_one')) class MyNamedTuple(_MyNamedTupleBase): def __repr__(self): "My sophisticated __repr__()" # and e.g. some new methods... ...or: class MyNamedTuple(namedtuple('MyNamedTuple', ('one_field', 'another_field', 'and_another_one'))): def __repr__(self): "My sophisticated __repr__()" # and e.g. some new methods... It would be very nice to be able to do it in such a way: class MyNamedTuple(namedtuple.abc): _fields = ( 'one_field', 'another_field', 'and_another_one', ) def __repr__(self): "My sophisticated __repr__()" # and e.g. some new methods... ...and especially: class MyAbstractNamedTuple(namedtuple.abc): def __repr__(self): "My sophisticated __repr__()" # and e.g. some new methods... class MyNamedTupleA(MyAbstractNamedTuple): _fields = 'a b c' class MyNamedTupleB(MyAbstractNamedTuple): _fields = ( 'one_field', 'another_field', 'and_another_one', ) (Please note that _fields is a part of the public API of named tuples). Implementation would be easy to explain (and to do; actually I have an outline in my head). The type (metaclass) of namedtuple.abc would be a subclass of abc.ABCMeta and would also act (by ABC registration mechanism) as an abstract base for all named tuples and structsequences like sys.version_info. So all these expressions would be True: >>> isinstance(namedtuple('Foo', 'x y z'), namedtuple.abc) >>> isinstance(sys.version_info, namedtuple.abc) And obviously: >>> isinstance(MyNamedTuple, namedtuple.abc) # referiring to the above examples What do you think about the idea? Regards. *j

6 11

Adding a `Counter.elements_length` method
by cool-RR 31 Mar '11

31 Mar '11

Hello folks, I suggest a `Counter.elements_length` method should be added, that would give the same answer as `sum(counter.itervalues())`. What do you think? Ram.

2 2

EuroPython 2011: call for paper is ending - Please spread the word
by Palla 31 Mar '11

31 Mar '11

Hi all, I'm Francesco and I am writing on behalf of "Python Italia APS", a no-profit association promoting EuroPython conference. (www.europython.eu) Europython End of Call for Presentations is April 6th. I'd like to ask to you to forward this mail to anyone that you feel may be interested. We're looking for proposals on every aspects of Python: programming from novice to advanced levels, applications and frameworks, or how you have been involved in introducing Python into your organisation. **First-time speakers are especially welcome**; EuroPython is a community conference and we are eager to hear about your experience. If you have friends or colleagues who have something valuable to contribute, twist their arms to tell us about it! Presenting at EuroPython ------------------------ We will accept a broad range of presentations, from reports on academic and commercial projects to tutorials and case studies. As long as the presentation is interesting and potentially useful to the Python community, it will be considered for inclusion in the programme. Can you show the conference-goers something new and useful? Can you show attendees how to: use a module? Explore a Python language feature? Package an application? If so, consider submitting a talk. Talks and hands-on trainings ---------------------------- There are two different kind of presentations that you can give as a speaker at EuroPython: * **Regular talk**. These are standard "talk with slides", allocated in slots of 45, 60 or 90 minutes, depending on your preference and scheduling constraints. A Q&A session is held at the end of the talk. * **Hands-on training**. These are advanced training sessions for a smaller audience (10-20 people), to dive into the subject with all details. These sessions are 4-hours long, and audience will be strongly encouraged to bring a laptop to experiment. They should be prepared with less slides and more source code. If possible, trainers will also give a short "teaser talk" of 30 minutes the day before the training, to tease delegates into attending the training. In the talk submission form, we assume that you intend to give a regular talk on the subject, but you will be asked if you are available for also doing a hands-on training on the very same subject. Speakers that will give a hands-on training are rewarded with a **free entrance** to EuroPython to compensate for the longer preparation required, and might also be eligible for a speaking fee (which we cannot confirm at the moment). Topics and goals ---------------- Specific topics for EuroPython presentations include, but are not limited to: - Core Python - Other implementations: Jython, IronPython, PyPy, and Stackless - Python libraries and extensions - Python 3.x migration - Databases - Documentation - GUI Programming - Game Programming - Network Programming - Open Source Python projects - Packaging Issues - Programming Tools - Project Best Practices - Embedding and Extending - Science and Math - Web-based Systems Presentation goals usually are some of the following: - Introduce audience to a new topic they are unaware of - Introduce audience to new developments on a well-known topic - Show audience real-world usage scenarios for a specific topic (case study) - Dig into advanced and relatively-unknown details on a topic - Compare different options in the market on a topic Community-based talk voting --------------------------- This year, for the first time in EuroPython history, the talk voting process is fully public. Every partecipant gains the right to vote for talks submitted during the Call For Papers, as soon as they commit to their presence at the conference by buying a ticket. See all the details in the talk voting[1] page. Contacts -------- For any further question, feel free to contact the organizers at info(a)pycon.it. Thank you! [1]: http://ep2011.europython.eu/talk-voting -- ->PALLA

1 0

descriptors outside of classes
by Eric Snow 30 Mar '11

30 Mar '11

Here's another outlandish idea. How about if descriptors could be used outside of classes. I.e. any global or local variable could be assigned a descriptor object and the descriptor protocol would be respected for that variable. This would be a pretty messy change, and I have no illusions that the idea will go anywhere. However, would there be room for this in python? The advantage is that it would allow for greater flexibility in hacking things up. The downside is that it hides what's really going on. Descriptors on classes are already less-than-obvious if you aren't familiar with how variables are handled on objects. I would expect that descriptors in the global namespace would be even more-so. -eric

7 17

{Python-ideas] C-API exposure
by Eric Snow 30 Mar '11

30 Mar '11

As I have been toying around with a few things, I have noticed that the C-API provides a lot more functionality than is exposed in Python. Much of the functionality can be reproduced one way or another. However, I was wondering if it would be feasible (and tractable) to expose every bit of the C-API in python. If it happened, then everything in there could be written in pure python relative to all the other exposed pieces. This would allow easier prototyping of new language features. It would not be practical from a performance standpoint for most stuff, but it would help people understand how python works underneath. As well, exposing all the pieces would provide a way to test the C-API completely from pure python. While I see several good things, I also see the size of the task. Just exposing the C-API would be a feat. On top of that, emulating the innards of each piece in pure python using the other exposed pieces would be a big job. Would it be worth it? Would it expose things we actually don't want exposed? I think it would be really cool, but half the time that is a good warning sign. -eric

6 9

Re: [Python-ideas] Serialization of custom classes.
by Masklinn 30 Mar '11

30 Mar '11

On 2011-03-30, at 13:07 , Jakob Bowyer wrote: > Ignore customjsondumps for now. Im more getting at __json__ being a > class method? As I said, there is a blessed extension mechanism in subclassing JSONEncoder, and as long as all JSONEncoder subclasses correctly call super() they should be composable. And if you decide that your objects will all implement __json__ you can just throw in a generic JSONEncoder for that. What significant gain would an additional __json__ hook provide over it? PS: the simplejson mailing list may be a better suggestion for that kind of things, it's probably where the tip of the development happens.

1 0