Mailman 3 July 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

Specify number of items to allocate for array.array() constructor
by Sven Rahmann Feb. 21, 2020

Feb. 21, 2020

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int … [View More]

14 20

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

change NoneType, NotImplementedType, & ellipses to return the appropriate singleton
by Ethan Furman Aug. 7, 2011

Aug. 7, 2011

Consider: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. --> for ins in ({0:'0'}, (1,), set([2, 3]), [4, 5], 6, 'seven', ... 8.0, True, None): ... print(type(ins)) ... type(ins)() ... <class 'dict'> {} <class 'tuple'> () <class 'set'> set() <class 'list'> [] <class 'int'> 0 <class 'str'> '' <class 'float'> 0.0 <class 'bool'> False &… [View More]

15 20

Make compile('1\n2\n', '', 'single') raise an exception instead of silently truncating?
by Devin Jeanpierre Aug. 6, 2011

Aug. 6, 2011

compile('1\n2\n', '','single') == compile('1\n', '','single'). That is, it ignores the second statement ('2\n'), without offering a way for the caller to detect this. Considering that 'single' is primarily used to emulate the behaviour of the Python interpreter, most of the time, giving it multiple statements is an impossibility, and so that case doesn't matter and could raise an exception without affecting existing code. For example, the code module meets this description, as do debuggers … [View More]

2 4

New imaplib implementation for Python 3.2+ standard library
by Maxim Khitrov Aug. 4, 2011

Aug. 4, 2011

Hello python-ideas, My most recent project lead me down a path that eventually ended up at a new implementation of imaplib based on [RFC-3501]. Although I started the project by gradually adding functionality to the existing IMAP4 library, some of the features that I required simply could not be merged in (without breaking everything). As a result, I wrote my own version of the library, which incorporates all existing functionality of imaplib and includes many of my own improvements. I wrote … [View More]

7 19

anonymous object support
by Herman Sheremetyev Aug. 4, 2011

Aug. 4, 2011

It is currently somewhat difficult/awkward to create arbitrary "anonymous" objects in Python. For example, to make some object that simply has a foo() method you have to declare a class that defines foo() and instantiate it: class Foo: def foo(self, x): return x obj = Foo() It would be a bit easier if Python allowed attributes to be set on instances of builtins the way it does for user-defined classes. This would at least allow something like: obj = object() obj.foo = lambda x: x Alas, … [View More]

14 23

+1, +0.5
by Christopher King July 30, 2011

July 30, 2011

What does +1 or +0.5 mean. I assume that they are some sort of rating, so how does the rating system work. Thanks

2 1

Enums
by Guido van Rossum July 29, 2011

July 29, 2011

On Sun, Jul 24, 2011 at 3:47 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > We've actually been down the 'namespace object' road years ago (Steve > Bethard even wrote a proto-PEP IIRC) and it suffered the same fate as > most enum PEPs: everyone has slightly different ideas on what should > be supported, so you end up being faced with one of two options: > 1. Ignore some of the use cases (so some users still have to do their own thing) > 2. Support all of the use cases … [View More]

29 100

A function that gives you the number of items in an arbitrary iterable (not len)
by Mike Graham July 28, 2011

July 28, 2011

There are a couple patterns, some uglier than others, which I have seen occasionally pop up which could be solved by a new builtin or stdlib that works like def exhaust(it): count = 0 for item in it: count += 1 return count Here are some situations where such a function could come in handy: 1. I want to know how many conditions satisfy a condition. I can currently determine this with code like sum(itertools.imap(cond, it)) or one of several other options. Oftentimes these … [View More]

3 2

Re: [Python-ideas] anonymous object support
by Herman Sheremetyev July 26, 2011

July 26, 2011

[adding python-ideas back to CC] On Mon, Jul 25, 2011 at 5:40 PM, Paul Moore <p.f.moore(a)gmail.com> wrote: > On 25 July 2011 08:41, Herman Sheremetyev <herman(a)swebpage.com> wrote: >>> >>> class Dummy: pass >>> >>> It's not really worth including something this short in the stdlib: >>> >>> from somewhere import Dummy >>> >>> is actually longer! >> >> This doesn't actually help with the "create … [View More]object as an expression" >> requirement. Steven D'Arpano's message describes some implementation >> details, and it would be nice if you didn't have to import it though I >> could live with that as well. > > I'm not quite sure I follow. Are you insisting that you need to create > an instance and then assign an instance attribute/method <b>in a > single expression</b>, and have the resulting instance be the value of > that expression? > > If so, then I don't really see what you gain apart from saving a line > or two in your source code, and confusing your reader. But if you must > do that, then Nick's suggestion of using the type builtin would > probably do what you want. (I make no claims that it's particularly > readable, but I'd say you gave up on that when you insisted on a > one-line solution :-)) > > To compare, we're talking about: > > d = Dummy() > d.foo = lambda x: x > expression_involving(d) > > vs > > expression_involving(Dummy(foo = lambda x:x)) You could do that if it seems reasonable or useful in that particular case, but more often than not I think you'd do something like: variable = Dummy(foo=lambda x: x) expression_involving(variable) Having one line of code that accomplishes a simple task (creating an object and saving it in a variable) instead of having to write N lines for each attribute makes for more readability not less IMO. You can still break lines inside the parens and add each attribute on its own line, but the indentation would at least clue the reader to the fact that it's really a single operation. Having N lines, especially if N is more than 2 or 3, is begging for the whole thing to be moved off into a helper function. And in tests this kind of operation happens all the time. > Even using trivial examples like this, I find the first more readable > (and I'd curse the writer if I had to maintain code like the second). > If expression_involving() was anything more complex than a function > call, or foo was more than the identity function, this would be > utterly unreadable. > > Can you point at any real code that implements a class-making function > such as you describe, and then uses it? I'd be curious to see any > real-world examples to check if my intuition that such code is > difficult to understand holds up. https://github.com/has207/flexmock/blob/master/tests/flexmock_test.py You can take a look at the tests starting at line 56 -- the flexmock() function does exactly what I'm proposing when given keyword args. > PS Feel free to quote any of this mail back on-list. I would have > added the list back into my reply, on the assumption that you simply > forgot to include the list, but didn't want to do so without your > agreement... It wasn't my message that took the list off the CC :) Cheers, -Herman [View Less]

6 13

use "as" for block scope support
by 海韵 July 25, 2011

July 25, 2011

New submission from HaiYun Yan <lyricconch(a)gmail.com>: just like mozilla javascript "let" extension https://developer.mozilla.org/en/new_in_javascript_1.7#Block_scope_with_let… according function args can have the default value let_stmt is unnecessary for python. ============example 1=========== f = None with open(...) as f: assert hasattr(f, "read") f = 1 assert f == 1 assert f is None ==========example 2============== try: e = None 1/0 except … [View More]

6 10

Fwd: use "as" for block scope support
by 海韵 July 25, 2011

July 25, 2011

1. but what about ( t * s + t / s )? temp var always keep in memory. (should not reduce ( t + s ) to ( 2 * x ) since x, y may not a number. any operator here should be conside as independent function. ) 2. try convert this to the lambda form: (x+y as t, x-y as s)(t * s as u, t/s as v)(u << v as p, u>>v as q) p ** q In runtime: lambda = MAKE_FUNCTION/MAKE_CLOSURE = PyFunction_New lambda call = CALL_FUNCTION = PyFrame_New + PyEval_EvalFrameEx all of them are heavy, (you can … [View More]

1 1

Re: [Python-ideas] Deprecate str.find
by Larry Bugbee July 20, 2011

July 20, 2011

> Steven D'Aprano wrote: > In my wishlist for Python 4000 I have: and sooner would be nicer. > * list.index renamed to list.find > * str.find and list.find return None if the argument is not found +1 ...and forget throwing an exception if not found. None is much preferred.

2 1

Left division operator
by Sturla Molden July 18, 2011

July 18, 2011

I was wondering if anyone else has felt the need for a leftward division operator in Python. That is, y\x in addition to x/y. Thus the operators: y \ x y \\ x Why the statement "y\x" is different from "x/y": 1. Opposite order of evaluation: This is important if evaluating one of the operands has side-effects. 2. In linear algebra, (Y**-1)*X is in general not equal to X*(Y**-1). Matrix and vector algebra in fundamental to computer graphics and scientific computing. 3. NumPy … [View More]

10 16

Deprecate str.find
by Mike Graham July 18, 2011

July 18, 2011

str.find (and bytes.find) is worse than the alternatives in every way. It should be explicitly deprecated in favour of str.__contains__ and str.index. str.find when used to check for substring is inferior to the in operator. "if sub in s:" is shorter, easier-to-read, and more efficient than "if s.find(sub) != -1:" and is not prone to the error "if s.find(sub):" I have occasionally seen. str.index is better for finding indices in that it supports an idiomatic exception-based API rather than a … [View More]

17 61

Re: [Python-ideas] None-as-sentinel alternatives? (was: deferred default arguments)
by Don Spaulding July 16, 2011

July 16, 2011

On Wed, Jul 13, 2011 at 8:23 PM, Steven D'Aprano <steve(a)pearwood.info>wrote: > Eric Snow wrote: > > A New Solution >> --------------- >> >> Provide a builtin version of a Deferred singleton, like None or >> NotImplemented. When resolving arguments for a call, if an argument >> is this Deferred object, replace it with the default argument for that >> parameter on the called function, if there is one. If there isn't, >> act as though … [View More]

3 3

deferred default arguments
by Eric Snow July 14, 2011

July 14, 2011

I'll get this out of the way now. This is probably a dumb idea. However, I have found myself working around a use case lately and have a thought of a cleaner solution. The Situation --------------- As you know, you can use default arguments when defining a function. Sometimes you want to pass an argument through from a function's arguments to another function that the original ("outer") calls. I run into this during inheritance-related calls and when interfacing between two compatible APIs.… [View More] Here's an example: class X: def f(self, name="N/A"): ... class Y(X): def f(self, name="N/A"): super().f(name) Y().f() So, the name argument is passed through from Y's f() to X's. In this case, we want to keep the default argument the same. Current Solutions --------------- Keeping the default arguments the same can be accomplished in a few different ways right now, but they are less than ideal: * Manually keep the two sync'ed (like above), a DRY violation. * Use introspection at definition time (using X.f.__defaults__ and X.f.__kwdefaults__), which is fragile (if the X.f attributes are changed later or the function definition's signature changes). * Use a dummy value to indicate that the default should be supplied by X's f(). This requires some clutter in the function and possibly a less obvious default argument. Here's an example of that last one: class DeferredType: pass DEFERRED = DeferredType() class X1: def f(self, name="N/A"): if name is DEFERRED: name = "N/A" # DRY #name = X1.f.__defaults__[0] # fragile ... class Y1(X1): def f(self, name=DEFERRED): super().f(name) Of course, the DEFERRED object could be any other specific object, particularly None. Here's another similar example that reminds me of Jack's example[1] from the recent thread on mutable default arguments. It is the solution I am using currently. class X2: def f(self, name=None): if name is None: name = "N/A" ... class Y2(X2): def f(self, name=None): super().f(name) Of course, using DEFERRED instead of None would allow you to use None as the actual default argument, but you get the idea. Notice that the actual default argument is no longer in the argument list, so it is less obvious and no longer introspect-able. I have also run into this use-case outside of inheritance situations. A New Solution --------------- Provide a builtin version of a Deferred singleton, like None or NotImplemented. When resolving arguments for a call, if an argument is this Deferred object, replace it with the default argument for that parameter on the called function, if there is one. If there isn't, act as though that argument was not passed at all. Here's how it would look: class X: def f(self, name="N/A"): ... class Y(X): def f(self, name=Deferred): super().f(name) [2] This way, Y's f has a sensible default argument for "name"[3] and implies where to find the actual default argument (on super().f)[4]. X's f is not cluttered up and has a clear, introspect-able default argument. Thoughts? -eric p.s. while I usually pursue random flights of fancy (answers looking for questions), this idea was born of an honest-to-goodness practical use-case I use semi-frequently. One thing I've learned about the Python community is that ideas that come from real [and common] use-cases have a much better chance of not dying a quick and painful death (not holding my breath here though <wink>). [1] http://mail.python.org/pipermail/python-ideas/2011-May/010263.html [2] As a bonus, an "outer" function could take advantage of different default arguments when calling more than one function: def f(name="N/A"): ... def g(name="Undefined"): ... def h(name=Deferred): f(name) g(name) [3] "Deferred" indicates what kind of argument it is in a straightforward way. However, I don't want the name to be confused with anything like Twisted Deferred objects, so whatever name is clear would, of course, be appropriate. [4] That is true from a people perspective, but not for introspection; e.g. if you want to introspect the actual default argument for Y.f, you would have to be able to programmatically determine how that parameter is used in the function body... [View Less]

6 9

os.path.isparent and os.path.ischild
by Giampaolo Rodolà July 14, 2011

July 14, 2011

>>> isparent('/a', '/a/b') True >>> isparent('/a/b', '/a') False >>> ischild('/a/b', '/a') True >>> ischild('/a', '/a/b') False Thoughts? Regards, --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/

16 30

Opening a folder in Explorer/Nautilus/Mac-thingie
by cool-RR July 9, 2011

July 9, 2011

Hello, I have the path of a certain folder. I want to open it using the default folder explorer for that system. For example, if it's a Windows computer, I want to use Explorer, if it's Linux, I want to use Nautilus or whatever is the default there, if it's Mac, I want to use whatever Mac OS's explorer is called. I asked this on StackOverflow: http://stackoverflow.com/questions/6631299/python-opening-a-folder-in-explo… But it seems that Python doesn't offer a cross-platform way to do this. … [View More]

3 3

Allow isinstance second argument to be a set of types
by Michael Foord July 7, 2011

July 7, 2011

Hello all, Occasionally I build up tuples of types for passing as the second argument to isinstance. I've noticed on occasions having duplicates, for example the following code is Python 2 & 3 compatible but results in a duplicate on one of them: FunctionTypes = ( # python function type(create_autospec), # instance method type(ANY.__eq__), # unbound method type(_ANY.__eq__), ) It would feel cleaner to me if I could make FunctionTypes a set and use that as the … [View More]

20 45

python
by VIGNESH BALA July 4, 2011

July 4, 2011

ideas abt python..

2 1

dir with a glob?
by Sturla Molden July 1, 2011

July 1, 2011

Often when exploring an object with the 'dir' function, particularly in large packages like SciPy, I find that I need to filter the outout. Since a dir reminds me of a dos 'dir' or linux 'ls', a glob feels like the most natural to use. For example, none of these would work: >>> dir(sp.fft.i*) # syntax error >>> dir('sp.fft.i*') # returns the attributes a string I believe a new dir functions is needed, or a change in the behviour of the current version. Of course a '… [View More]

13 26