Mailman 3 March 2012 - 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

Yielding through context managers
by Joshua Bartlett Jan. 8, 2013

Jan. 8, 2013

I'd like to propose adding the ability for context managers to catch and handle control passing into and out of them via yield and generator.send() / generator.next(). For instance, class cd(object): def __init__(self, path): self.inner_path = path def __enter__(self): self.outer_path = os.getcwd() os.chdir(self.inner_path) def __exit__(self, exc_type, exc_val, exc_tb): os.chdir(self.outer_path) def __yield__(self): self.inner_path = … [View More]

6 14

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

Re: [Python-ideas] Cofunctions - Back to Basics
by Mark Shannon Oct. 20, 2012

Oct. 20, 2012

Greg Ewing wrote: > Mark Shannon wrote: > >> Why not have proper co-routines, instead of hacked-up generators? > > What do you mean by a "proper coroutine"? > A parallel, non-concurrent, thread of execution. It should be able to transfer control from arbitrary places in execution, not within generators. Stackless provides coroutines. Greenlets are also coroutines (I think). Lua has them, and is implemented in ANSI C, so it can be done portably. See: http://www.jucs.… [View More]

9 25

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

sys.implementation
by Eric Snow April 26, 2012

April 26, 2012

In October 2009 there was a short flurry of interest in adding "sys.implementation" as an object to encapsulate some implementation-specific information [1]. Does anyone recollect where this proposal went? Would anyone object to reviving it (or a variant)? -eric [1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html

7 16

Re: [Python-ideas] make __closure__ writable
by Mark Shannon April 10, 2012

April 10, 2012

Yury Selivanov wrote: > On 2012-03-16, at 2:57 PM, Yury Selivanov wrote: > >> Decorators can be nested, and what you can do in this case is to >> find the most inner-wrapped function by traversing the '__wrapped__' >> attributes (and check that the function you found is the actual >> original function). After that you can play with its attributes, >> but you can't simply substitute the function object, as the inner >> decorator won't use it. So … [View More]

7 20

Thread stopping
by Andrew Svetlov April 2, 2012

April 2, 2012

I propose to add Thread.interrupt() function. th.interrupt() will set a flag in ThreadState structure. When interpreter switches to next thread it will check that flag. If flag is on then ThreadInterruptionError will be raised in thread context. If thread has blocked via threading locks (Lock, RLock, Condition, Semaphore etc) — exception is raised also. Of course we cannot interrupt thread if it has been locked by C Extension call or just waiting for blocking IO. But, I think, the way to … [View More]

14 22

Implied try blocks
by Calvin Spealman March 29, 2012

March 29, 2012

Given that for some time the try/except/else form is standard and encouraged, I've found the following pattern really common in my code: try: r = some_single_statement() except TypeError: print "oh no!" raise OhNoException() else: p = prepare(r) print "I got", p Where the try block ever doing more than one thing feels dangerous or sloppy, because I want to make sure I know exactly where the exception comes from. The else block becomes the long tail and the try is just the … [View More]

6 6

Re: [Python-ideas] PEP x: Static module/package inspection
by anatoly techtonik March 29, 2012

March 29, 2012

(reposting this from Google Group once more as the previous post missed Mailing List, because I was not subscribed in Mailman) *Static module/package inspection* Abstract: - static: without execution (as opposed to dynamic) - module/package: .py or __init__.py file - inspection: get an overview of the contents *What should this do?* * * The proposal to add a mechanism to Python interpreter to get an outline of module/package contents without importing or executing module/package. The … [View More]outline includes names of classes, functions, variables. It also should contain values for variables that could be provided without sophisticated calculations (e.g. a string, integer, but probably not expressions as it may lead to security leaks). *Why?* * * *user story PEPx.001:* As a Python package maintainer, I find it bothersome to repeatedly write bolierplate code (e.g. setup.py) to package my single file module. The reason I should write setup.py is to provide version and description info. This info is already available in my module source code. So I need to either copy/paste the info from the module manually, or to import (and hence execute) my module during packaging and installation, which I don't want either, because modules are often installed with root privileges. With this PEP, packing tool will be able to extract meta information from my module without executing it or without me manually copying version fields into some 'package configuration file'. *user story PEPx.002:* As a Python Application developer, I find it really complicated to provide plugin extension subsystem for my users. Users need a mechanism to switch between different versions of the plugin, and this mechanism is usually provided by external tool such as setuptools to manage and install multiple versions of plugins in local Python package repository. It is rather hard to create an alternative approach, because you are forced to maintain external meta-data about your plugin modules even in case it is already available inside the module. With this PEP, Python Application will be able to inspect meta-data embedded inside of plugins before choosing which version to load. This will also provide a standard mechanism for applications to check modules returned by packaging tools without executing them. This will greatly simplify writing and debugging custom plugins loaders on different platforms. *Feedback goal* At this stage I'd like to a community response to two separate questions: 1. If everybody feels this functionality will be useful for Python 2. If the solution is technically feasible [View Less]

4 5

make __closure__ writable
by Yury Selivanov March 29, 2012

March 29, 2012

Can we make the __closure__ attribute writeable? Since __code__ already is, and it is possible to tackle with the opcodes, having no way of rewriting __closure__ (except creating a completely new function) is annoying. I don't think it will somehow harm python, as those who want to break it can do it already in multiple ways, easier than playing with __closure__. - Yury

6 9

A more useful command-line wsgiref.simple_server?
by Masklinn March 28, 2012

March 28, 2012

Currently, calling wsgiref.simple_server simply mounts the (bundled) demo app. I think that's a bit of a lost opportunity: as the community has mostly standardized on a *.wsgi/wsgi.py script providing an `application` name in its global namespace, it would be nice if wsgiref.simple_server could take such a file as parameter and mount the application provided: * This would allow testing that the script has no error without having to go through mounting it in e.g. mod_wsgi * It would make … [View More]

3 5

Standard way to get caller name and easy call stack access
by anatoly techtonik March 28, 2012

March 28, 2012

Seems like the only way to get caller name in Python is to use inspect module [1] It seems that this way is not recommended (I wonder why?) and there is no other. The stackoverflow question about how to get callers method namd [1] got 3k views over 1 year, so the recipe seems to be useful. I've developed a similar snippet [2] that also extracts a module and class name in addition to method. To me this snippet is very handy to insert in print statements to see who uses a certain function at run-… [View More]time. The output from this function is: spyderlib.widgets.externalshell.introspection.NotificationThread.run Which no function of `inspect` and `traceback` modules can provide (correct me if I wrong, but I am pretty confident). The stuff they propose will look like: File "/mount/sdb5/projects/spyderlib/spyderlib/widgets/externalshell/introspection.py", line 183, in run write_packet(self.notify_socket, output) As a 'software engineer' I am more interested to get logical structure of call stack rather than physical location of code text pieces (which is important too, but secondary). Neither `traceback` nor `inspect` seems to be designed with this use case, and if you'll look closely - the traceback above misses class info completely. To get the name of the class from this traceback you need to know its location withing the lines of the file. So, I'd propose to include caller_name() function somewhere and name it somehow. But there is more to that. Maybe too late for Python 3, but still an idea - make call stack a normal Python feature (optional for stackless, but still a feature) and describe a standard for call stack names, to provide everybody a simple and safe way to see what's going on with execution stack (and an easy way to get caller names). Making it a feature means that there will be almost no overhead when looking up the name (id) of the caller callers. This will also be handy for logging. I wish I could shorten this proposal. The picture in my head is something like: __main__ spyderlib.widgets.externalshell.introspection.NotificationThread.run spyderlib.utils.bsdsocket.write_packet Every indented string is an unique id of function or other closure that makes up Python code. Would it rock? This will probably require describing all possible ways to run Python code to see where a call to caller_name() can appear to cover all possible situations. Is there already a list of these ways? 1. http://stackoverflow.com/questions/2654113/python-how-to-get-the-callers-me… 2. https://gist.github.com/2151727 -- anatoly t. [View Less]

11 19

Re: [Python-ideas] My objections to implicit package directories
by Guido van Rossum March 28, 2012

March 28, 2012

On Tue, Mar 27, 2012 at 1:20 PM, Phil Vandry <vandry(a)tzone.org> wrote: > On 2012-03-26 10:57 , Guido van Rossum wrote: >> >> On Mon, Mar 26, 2012 at 1:45 AM, Ronald Oussoren<ronaldoussoren(a)mac.com> >> wrote: >>> >>> Yes. On what platform are you? On unixy platforms filename extensions are >>> just a naming convention that can just as easily be used with directories. >> >> >> IIUC that's how almost all … [View More]

2 1

Add socketserver running property
by Giampaolo Rodolà March 27, 2012

March 27, 2012

Hi all, I would like to attract some attention to: http://bugs.python.org/issue14375 Would this be acceptable? Regards, --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ http://code.google.com/p/pysendfile/

3 2

My objections to implicit package directories
by Nick Coghlan March 26, 2012

March 26, 2012

It seems the consensus at the PyCon US sprints is that implicit package directories are a wonderful idea and we should have more of those. I still disagree (emphatically), but am prepared to go along with it so long as my documented objections are clearly and explicitly addressed in the new combined PEP, and the benefits ascribed to implicit package directories in the new PEP are more compelling than "other languages do it that way, so we should too". To save people having to trawl around … [View More]various mailing list threads and reading through PEP 395, I'm providing those objections in a consolidated form here. If reading these objections in one place causes people to have second thoughts about the wisdom of implicit package directories, even better. 1. Implicit package directories go against the Zen of Python Getting this one out of the way first. As I see it, implicit package directories violate at least 4 of the design principles in the Zen: - Explicit is better than implicit (my calling them implicit package directories is a deliberate rhetorical ploy to harp on this point, although it's also an accurate name) - If the implementation is hard to explain, it's a bad idea (see the section about backwards compatibility challenges) - Readability counts (see the section about introducing ambiguity into filesystem layouts) - Errors should never pass silently (see the section about implicit relative imports from main) 2. Implicit package directories pose awkward backwards compatibility challenges It concerns me gravely that the consensus proposal MvL posted is *backwards incompatible with Python 3.2*, as it deliberately omits one of the PEP 402 features that provided that backwards compatibility. Specifically, under the consensus, a subdirectory "foo" of a directory on sys.path will shadow a "foo.py" or "foo/__init__.py" that appears later on sys.path. As Python 3.2 would have found that latter module/package correctly, this is an unacceptable breach of the backwards compatibility requirements. PEP 402 at least got this right by always executing the first "foo.py" or "foo/__init__.py" it found, even if another "foo" directory was found earlier in sys.path. We can't just wave that additional complexity away if an implicit package directory proposal is going to remain backwards compatible with current layouts (e.g. if an application's starting directory included a "json" subfolder containing json files rather than Python code, the consensus approach as posted by MvL would render the standard library's json module inaccessible) 3. Implicit package directories introduce ambiguity into filesystem layouts With the current Python package design, there is a clear 1:1 mapping between the filesystem layout and the module hierarchy. For example: parent/ # This directory goes on sys.path project/ # The "project" package __init__.py # Explicit package marker code.py # The "project.code" module tests/ # The "project.tests" package __init__.py # Explicit package marker test_code.py # The "projects.tests.test_code" module Any explicit package directory approach will preserve this 1:1 mapping. For example, under PEP 382: parent/ # This directory goes on sys.path project.pyp/ # The "project" package code.py # The "project.code" module tests.pyp/ # The "project.tests" package test_code.py # The "projects.tests.test_code" module With implicit package directories, you can no longer tell purely from the code structure which directory is meant to be added to sys.path, as there are at least two valid mappings to the Python module hierarchy: parent/ # This directory goes on sys.path project/ # The "project" package code.py # The "project.code" module tests/ # The "project.tests" package test_code.py # The "projects.tests.test_code" module parent/ project/ # This directory goes on sys.path code.py # The "code" module tests/ # The "tests" package test_code.py # The "tests.test_code" module What are implicit package directories buying us in exchange for this inevitable ambiguity? What can we do with them that can't be done with explicit package directories? And no, "Java does it that way" is not a valid argument. 4. Implicit package directories will permanently entrench current newbie-hostile behaviour in __main__ It's a fact of life that Python beginners learn that they can do a quick sanity check on modules they're writing by including an "if __name__ == '__main__':" section at the end and doing one of 3 things: - run "python mymodule.py" - hit F5 (or the relevant hot key) in their IDE - double click the module in their filesystem browser - start the Python REPL and do "import mymodule" However, there are some serious caveats to that as soon as you move the module inside a package: - if you use explicit relative imports, you can import it, but not run it directly using any of the above methods - if you rely on implicit relative imports, the above direct execution methods should work most of the time, but you won't be able to import it - if you use absolute imports for your own package, nothing will work (unless the parent directory for your package is already on sys.path) - if you only use absolute imports for *other* packages, everything should be fine The errors you get in these cases are *horrible*. The interpreter doesn't really know what is going on, so it gives the user bad error messages. In large part, the "Why are my imports broken?" section in PEP 395 exists because I sat down to try to document what does and doesn't work when you attempt to directly execute a module from inside a package directory. In building the list of what would work properly ("python -m" from the parent directory of the package) and what would sometimes break (everything else), I realised that instead of documenting the entire hairy mess, the 1:1 mapping from the filesystem layout to the Python module hierarchy meant we could *just fix it* to not do the wrong thing by default. If implicit package directories are blessed for inclusion in Python 3.3, that opportunity is lost forever - with the loss of the unambiguous 1:1 mapping from the filesystem layout to the module hierarchy, it's no longer possible for the interpreter to figure out the right thing to do without guessing. PJE proposed that newbies be instructed to add the following boilerplate to their modules if they want to use "if __name__ == '__main__':" for sanity checking: import pkgutil pkgutil.script_module(__name__, 'project.code.test_code') This completely defeats the purpose of having explicit relative imports in the language, as it embeds the absolute name of the module inside the module itself. If a package subtree is ever moved or renamed, you will have to manually fix every script_module() invocation in that subtree. Double-keying data like this is just plain bad design. The package structure should be recorded explicitly in exactly one place: the filesystem. PJE has other objections to the PEP 395 proposal, specifically relating to its behaviour on package layouts where the directories added to sys.path contain __init__.py files, such that the developer's intent is not accurately reflected in their filesystem layout. Such layouts are *broken*, and the misbehaviour under PEP 395 won't be any worse than the misbehaviour with the status quo (sys.path[0] is set incorrectly in either case, it will just be fixable under PEP 395 by removing the extraneous __init__.py files). A similar argument applies to cases where a parent package __init__ plays games with sys.path (although the PEP 395 algorithm could likely be refined to better handle that situation). Regardless, if implicit package directories are accepted into Python 3.3 in any form, I *will* be immediately marking PEP 395 as Rejected due to incompatibility with an accepted PEP. I'll then (eventually, once I'm less annoyed about the need to do so) write a new PEP to address a subset of the issues previously covered by PEP 395 that omits any proposals that rely on explicit package directories. Also, I consider it a requirement that any implicit packages PEP include an update to the tutorial to explain to beginners what will and won't work when they attempt to directly execute a module from inside a Python package. After all, such a PEP is closing off any possibility of ever fixing the problem: it should have to deal with the consequences. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia [View Less]

13 26

EBNF-module in stdlib
by Lukas Lueg March 23, 2012

March 23, 2012

Hi. By all accounts, Python has many strong and flexible ways to deal with parsing of semi-structured data. Applications range from csv- and configuration-files over log- and report-data to all kinds of semi-structured formats. As far as I can see the standard library however either provides highly specialized modules (e.g. configparser, csv, json) or drives you off into very generic approaches (e.g. re) for you to implement the rest or use external modules. I started looking into RPython … [View More]

3 2

Add "default" keyword to itemgetter and attrgetter
by Miki Tebeka March 23, 2012

March 23, 2012

Greetings, I apologize if this appears twice, Google groups gave me an error on the first one and I want to make sure this makes it through. Repeating http://bugs.python.org/issue14384 .... This way they will behave more like getattr and the dictionary get. If default is not specified, then if the item/attr not found, an execption will be raised, which is the current behavior. However if default is specified, then return it in case when item/attr not found - default value will be returned.… [View More]

3 2

Save memory when forking with *really* immutable objects
by Larry Hastings March 23, 2012

March 23, 2012

I'll admit in advance that this is in all likelyhood a terrible idea. What I'm curious about is why it wouldn't work, or if it wouldn't even help ;-) One problem for CPython is that it can't share data across processes very often. If you have an application server, and you fork a hundred processes to handle requests, your memory use will be "C * n * p" where C is a constant, n is the number of processes, and p is the average memory consumption of your app. I fear C is very nearly near … [View More]

9 8

Exact integral types in struct
by Serhiy Storchaka March 22, 2012

March 22, 2012

The struct module works only with natural platform-specific integers. As a result, a lot of code in the standard library and third-party applications are forced either to rely on unreliable assumptions (short is always 2-byte, long is always 4-byte), which is not always true, either explicitly construct the integer from bytes (b[0]+(b[1]<<8)+(b[2]<<16)+...). I propose to introduce a special notation formats for signed and unsigned integers of arbitrary exact size (which is … [View More]

8 14

Allow function __globals__ to be arbitrary mapping not just dict
by Steven D'Aprano March 21, 2012

March 21, 2012

Currently, if you try to construct a function from parts, the mapping that becomes func.__globals__ must be an actual dict: py> class Mapping: ... def __getitem__(self, key): ... if key == 'y': ... return 42 ... raise KeyError(key) ... py> from types import FunctionType py> f = lambda x: x + y py> g = FunctionType(f.__code__, Mapping(), 'g') Traceback (most recent call last): File "<stdin>", line 1, in <module> … [View More]

7 9

Logging2 with default NullHandler
by anatoly techtonik March 18, 2012

March 18, 2012

Badly need `logging2` module that has NullHandler assigned by default for all loggers. http://packages.python.org/Logbook/api/handlers.html#logbook.NullHandler Why? Because logging fails to play well with libraries: import logging log = logging.getLogger(__name__) log.warn("WARN") No handlers could be found for logger "spyderlib.utils.bsdsocket" What do I want from library logging as a Python application developer? Nothing until I explicitly setup default behaviour. logging can … [View More]

6 15

Combining stat/lstat/fstatat etc.
by Serhiy Storchaka March 16, 2012

March 16, 2012

In Python3 added a large number of "at"-functions from the latter Posix standard. Such a large number of names only litters namespace. In C it is necessary for historical reasons (note that fstatat combines the stat and lstat and includes the possibility of extension) and because of static typing. But in Python because of dynamic typing we can extend existing functions. So instead of stat, lstat, and fstatat could use the same function `stat(path, *, dirfd=None, followlinks=True)`. Then `lstat(… [View More]

2 2

set.add could return True or False
by Matt Joiner March 16, 2012

March 16, 2012

set.add(x) could return True if x was added to the set, and False if x was already in the set. Adding an element that is already present often constitutes an error in my code. As I understand, set.add is an atomic operation. Having set.add return a boolean will also allow EAFP-style code with regard to handling duplicates, the long winded form of which is currently: if a not in b: b.add(a) <-- race condition do_c() Which can be improved to: if b.add(a): do_c() Advantages: *… [View More]

8 13