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 … [View More]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 [View Less]

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 … [View More]

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 … [View More]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: [View Less]

11 29

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

June 3, 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 … [View More]

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 … [View More]

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 … [View More]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… [View Less]

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 … [View More]

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' … [View More]

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 … [View More]

3 4

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

May 24, 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 … [View More]

3 5

CPython optimization: storing reference counters outside of objects
by Amaury Forgeot d'Arc May 23, 2011

May 23, 2011

Hi, 2011/5/23 Sturla Molden <sturla(a)molden.no>: > Instead, we could use multiple heaps: > > Each Python thread could manage it's own heap for malloc and free (cf. > HeapAlloc and HeapFree in Windows). Objects local to one thread only reside > in the locally managed heap. > > When an object becomes shared by seveeral Python threads, it is moved from a > local heap to the global heap of the process. Some objects, such as modules, > would be stored directly onto … [View More]

2 1

Re: [Python-ideas] [Python-Dev] CPython optimization: storing reference counters outside of objects
by Sturla Molden May 23, 2011

May 23, 2011

Den 23.05.2011 06:59, skrev "Martin v. Löwis": > > My expectation is that your approach would likely make the issues > worse in a multi-CPU setting. If you put multiple reference counters > into a contiguous block of memory, unrelated reference counters will > live in the same cache line. Consequentially, changing one reference > counter on one CPU will invalidate the cached reference counters of > that cache line on other CPU, making your problem a) actually worse. In a … [View More]

1 0

function defaults and an empty() builtin
by Jack Diederich May 22, 2011

May 22, 2011

During a code review I got asked a question about a "pythonic" idiom I've been asked about before. The code was like this: def func(optional=None): if optional is None: optional = [] The question was why the optional value wasn't set to an empty list in the first place. The answer is that Really Bad Things can happen if someone actually goes and manipulates that empty list because all future callers will see the modified version. I don't think this defensive programming practice is … [View More]

13 34

Filtered "for" loop with list-comprehension-like syntax
by Dan Baker May 21, 2011

May 21, 2011

One common pattern I run across when parsing plain text data files is that I want to skip over blank lines when processing. If I wanted to build a list of all non-blank lines in the file, I could simply do: lines = [line for line in input_file if line.strip()] But as a loop, it almost invariably gets written as: for line in input_file: if not line.strip(): continue # do the real processing It seems odd that "for x in y if z" is allowed in comprehensions but not in a regular for … [View More]

4 4

Type Metadata (and related ideas)
by andrew cooke May 19, 2011

May 19, 2011

Hi, I just finished working on a project that plays around with ABCs and function annotations. The idea was to allow for more delcarative code by adding tools to describe Pytohn data in more detail. While I don't think the result is suitable for adding to Python (it's way too big a change, and it's not yet proven), the process of making something consistent involved working through a lot of ideas about "types in Python" that I recorded at http://www.acooke.org/pytyp.pdf Part of that paper (… [View More]

1 0

PEP-3151 pattern-matching
by Devin Jeanpierre May 19, 2011

May 19, 2011

Hello, PEP-3151 < http://www.python.org/dev/peps/pep-3151/ > mentions a really weird syntax for pattern-matching. I was hoping I could suggest an alternative that's both more concise, and possible to implement without doing something drastic like changing existing syntax or semantics. The PEP offers the pattern-matching syntax: > except IOError as e if e.errno == errno.ENOENT: ... I'd instead suggest something along the lines of > except io_error(errno.ENOENT): ... … [View More]

15 44

Re: [Python-ideas] [Python-Dev] Python 3.x and bytes
by Ethan Furman May 18, 2011

May 18, 2011

Martin v. Löwis wrote [from python-dev]: > Immutable objects that compare equal should hash equal; > so we would also have to change the hashing of byte strings. Not sure > whether that, in turn, has undesirable consequences. I thought it was the other-way-round -- if they hash equal, they should compare equal? Or is this just for immutables? > In addition, equality should be transitive, so b'A' == 65.0. I'm not sure what you're getting at... we could certainly have step 2 … [View More]

2 1

Rename python.exe to python3.exe on Windows
by Devin Jeanpierre May 18, 2011

May 18, 2011

Hello, On most *nix systems, Python 3.x is available as the python3 executable, and Python 2.x as the 'python' executable. This lets both exist side-by-side and be usable from the command-line. The alternative (used by Arch), is to name Python 2.x 'python2', and 3.x 'python'. The Windows distribution of Python does neither, it names them both 'python.exe', meaning that you can't install and use both at once. Moreover, if you install Python 2.7 and then Python 3.2, the default handler for .py … [View More]

6 6

Suggestion for Style Guide for Python Code PEP 8
by Rahul Amaram May 15, 2011

May 15, 2011

Hi, I was wondering if the following programming recommendation would be added to the Style Guide for Python Code (PEP 8) page. The preferred way for checking if a key (k) exists in a dictionary (d) is "if k in d". This is faster than "if k in d.keys()" and this has superseded "d.has_key(k)" Cheers, Rahul.

3 4

a few decorator recipes
by Mathias Panzenböck May 14, 2011

May 14, 2011

A few decorator recipes that might be worthwhile to add to functools: A way to assign annotations to functions/classes: def annotations(**annots): def deco(obj): if hasattr(obj,'__annotations__'): obj.__annotations__.update(annots) else: obj.__annotations__ = annots return obj return deco _NONE = object() def getannot(obj, key, default=_NONE): if hasattr(obj, '__annotations__'): if default is _NONE: return obj.__annotations__[key] else: return obj.__annotations__.get(… [View More]

2 2

triple-quoted strings and indendation
by Matthias Lehmann May 14, 2011

May 14, 2011

Hi all, two times in one day I read about the problems of triple-quoted strings and indendation (one time on stackoverflow, one time one this list). Python is well known for its readability and its use of idendation to this end. But with triple-quoted strings, nice indendation is not possible without the need to post-process the resulting string. Problem ======= Most often, the desired result of >>> some_string = """Hello ... World.""" is simply Hello World … [View More]instead of Hello World. Idea ===== What about the idea, to use a string-flag to indicate, that the triple-quoted string is to be trimmed. Like: >>> some_string = t"""Hello ... World.""" This would blend in with the 'u' and 'r' flags that already exist. The triple-quoted string is trimmed to remove all whitespace up to the column where the first line of the string started OR all common whitespace of the subsequent lines, if the subsequent lines start on a column before the first line. The second rule makes it possible to also write: >>> some_string = t"""Hello ... World.""" Pros ===== The advantages above textwrap.dedent are: 1) textwrap.dedent only removes whitespace common to ALL lines, so to achieve the desired result, one has to add an additional newline >>> some_string = """ ... Hello ... World.""" >>> result = textwrap.dedent(some_string)[1:] 2) Also, it does not work, if one actually does want some common whitespace before all lines: >>> some_string = """ ... Hello ... Wold.""" >>> result = textwrap.dedent(some_string)[1:] gives again Hello World which is not, what I wanted. But >>> some_string = t""" Hello ... World.""" would give Hello World. 3) And finally to quote a post from earlier today "I know about textwrap.dedent, but having to use a Python function call to code a literal has always made me uncomfortable." Problems ========= Common indendation style for triple-quoted string (as far as I know) is >>> foo = """blubber ... bla""" (align to first quote-char) but with this auto-trimming, it would look better to use >>> foo = t"""blubber ... bar""" (align to first char after triple quotes) The other stlye would still work, though - as long as one does not want to preserve leading whitespace. Maybe the t flag could also cause a leading and trailing newline to be removed, so that >>> foo = t""" ... Hallo ... World. ... """ would also result in Hello World. Maybe something like this has been proposed before - please be kind, if it is an old hat. Mat <javascript:void(0);> [View Less]

8 19

Re: [Python-ideas] Suggestion for Style Guide for Python Code PEP 8
by Weeble May 13, 2011

May 13, 2011

On 12.05.2011 15:44, Rahul Amaram wrote: > The preferred way for checking if a key (k) exists in a dictionary (d) > is "if k in d". This is faster than "if k in d.keys()" and this has > superseded "d.has_key(k)" While 'k in d' is the right way to do it, I feel the claim it's faster that 'k in d.keys()' is somewhat weak. While this is technically true, it's a constant overhead, not some cost linear in the size of the collection - at least in Python 3 - because .keys() returns a view. … [View More]

1 0

Allow 'import star' with namespaces
by Brendan Moloney May 11, 2011

May 11, 2011

Hello, I posted this on python-dev, but was told that this is the more appropriate list. Currently if I do: $ import pkg Then all of the public subpackages/submodules are not automatically pulled into the 'pkg' namespace. I can do: $ from pkg import * To get all of the public subpackages/submodules, but that dumps them all into the current namespace. Why not allow: $ import pkg.* This would allow easier interactive use (by eliminating the need to import individual subpackages/submodules)… [View More]

10 20

EuroPython: Early Bird will end in 2 days!
by Palla May 11, 2011

May 11, 2011

Hi all, If you plan to attend, you could save quite a bit on registration fees! Buy your ticket now! http://ep2011.europython.eu/registration/ The end of Early bird is on May 12th, Friday, 23:59:59 CEST. We'd like to ask to you to forward this post to anyone that you feel may be interested. We have an amazing lineup of tutorials, events and talks. We have some excellent keynote speakers and a very complete partner program... but early bird registration ends in 2 days! Right now, you still … [View More]

1 0

1_000_000
by Matt Chaput May 7, 2011

May 7, 2011

Not sure if this has been proposed before: A syntax change to allow underscores as thousands separators in literal numbers to improve readability, e.g.: for i in range(1, 1_000_000): pass I believe D allows this and while it's a small thing it really is much more readable. Worth a PEP? Thanks, Matt

20 41