Mailman 3 June 2018 - Python-ideas

Python Decorator Improvement Idea
by Brian Allen Vanderburg II June 17, 2018

June 17, 2018

Just a small idea that could possibly be useful for python decorators. An idea I had is that it could be possible for a decorator function to declare a parameter which, when the function is called as a decorator, the runtime can fill in various information in the parameters for the decorator to use. Some of the information would be available in all contexts, while other information may only be available in certain contexts.The parameter's value cannot be explicitly specified, defaults to … [View More]Null except when called as a decorator, and can only be specified once in the function's parameter list. Called as a decorator implies: @decorator def decorated(): pass These are not called as a decorator. The first item's return value would be called as a decorator, thus if it has a decorator parameter, it would be used. @decorator(...) def decorated(): pass def decorated(): pass decorated = decorator(decorated) Any declared callable (function, class instance with __call__, etc) can have an explicitly declared parameter called a decorator information parameter. The syntax could be as follows. "info" is just a name I've chosen and could be any legal name. def decorator(..., @info): pass def wrapper(..., @info): def decorator(obj, @info): ... return obj if info: called directly as decorator, do something else: return decorator Rules: 1. It is not possible for the parameter's value to be directly specified. You can't call fn(info=...) 2. The parameters value is Null except in the cases where it is invoked (the callable called a a decorator). If used in a partial, the decorator parameter would be Null. etc. Information that could be contained in the parameters for all contexts: Variable name Module object declared in Module globals (useful for @export/@public style decorators) Etc Using the decorator in a class context, pass the class object. While the class object hasn't been fully created yet, this could allow accessing attributes of the class (like a registry or such) def decorator(fn, @info): if hasattr(info, "class_obj"): registry = info.class_obj.__dict__.setdefault("_registry", []) registry.append(fn) return fn class MyClass(Base): # Add "method" to the MyClass._registry list @decorator def method(...): pass def call_all(cls): for method in self._registry: method(self) This could also make it possible to use decorators on assignments. Information could be passed to the decorator by the runtime: script_vars = {} def expose(obj, @info): script_vars[info.name] = obj return obj def load(filename): # load script and compile exec(code, script_vars) @expose def script_function(...): pass # This will call the decorator passing in 200 as the object, as well as info.name as the variable being assigned. @expose SCRIPT_CONSTANT = 200 # If stacked, only the first would be used as info.name, in this case SCRIPT_CONSTANT2 @expose SCRIPT_CONSTANT2 = A_VAR = 300 def default(obj, @info): if info.name in info.ctx.vars: return info.ctx.vars[info.name] if info.name in info.globals: return info.globals[info.name] return obj @default X = 12 @default X = 34 print(X) # print 12 since during the second call, X existed and it's value was returned instead of 34, and was assigned to X The two potential benefits I see from this are: 1. The runtime can pass certain information to the decorator, some information in all contexts, and some information in specific contexts such as when decorating a class member, decorating a function defined within another function, etc 2. It would be possible to decorate values directly, as the runtime can pass relevant information such as the variables name This was just an idea I had that may have some use. Thanks, Brian Vanderburg II [View Less]

4 4

Approximately equal operator
by Andre Roberge June 16, 2018

June 16, 2018

I have a suggestion to make inspired by the current discussion about trigonometric functions in degrees, and the desire to have them show "exact" values in some special cases. I suggest that it would be useful to have operators for performing **approximate** comparisons. I believe that such operators would be useful both for students learning using Python as well as experts doing numerical computations. For discussion purpose, I will use ~= as representing an operator testing for approximate … [View More]equality. (I will show some sample usage below). When teaching students, the availability of both == and ~= would give the opportunity to discuss the fact that numerical computations using floats are approximate, while having the possibility to write code that is readable using the approximate equality operator instead of the strict equality operator when needed. Before I started writing this email, I had noticed that numpy includes at least two functions (isclose and allclose) whose purpose is to perform such approximate comparisons. [1] I had completely missed the fact that Python added the function isclose() in the math module in version 3.5, as described in PEP 485 [0]. I would suggest that the possibility of using operators instead of explicit function calls could make programs easier to write and read, both for beginners and experts alike. I note that PEP 485 makes no mention of introducing operators as a possibility. In addition to an approximate equality operator, it would be natural to include two additional operators, greater than or approximately equal, and lesser than or approximately equal. These could be written respectively as >~= and <~=. I did consider using some relevant utf-8 symbol instead of combination of ascii characters, but I think that it would be easier to write programs if one does not require characters nor found on any normal keyboard. Some time ago, I created a toy module [2] to enable easy experiments with some syntactic additions to Python. Using this module, I created a very poor and limited implementation that shows what using these proposed o[erators might look like [3] ... My current implementation is slightly different from either Numpy or Python's math.isclose() function [This may no longer be the case soon as I plan to change it to use Python's version instead.] . As is the case for isclose(), there are two paramaters to be set to determine if the values are close enough to be considered approximately equal: an absolute tolerance and a relative one. Given that one cannot pass parameters to an operator, my implementation includes a function which can change the values of these parameters for a given session. If these new operators were to be added to Python, such a function would either have to be added as a builtin or as a special function in the math module. Here's a sample session for demonstration purpose... $ python -m experimental experimental console version 0.9.5. [Python version: 3.6.1] ~~> 0.1 + 0.2 0.30000000000000004 ~~> 0.1 + 0.2 == 0.3 False ~~> from __experimental__ import approx ~~> 0.1 + 0.2 ~= 0.3 # use approximately equal operator True ~~> 0.1 + 0.2 <~= 0.3 True ~~> 0.1 + 0.2 >~= 0.3 True ~~> 2 ** 0.5 1.4142135623730951 ~~> 2**0.5 ~= 1.414 False ~~> set_tols(0.001, 0.001) ~~> 2**0.5 ~= 1.414 True André Roberge [0] https://www.python.org/dev/peps/pep-0485/ [1] See for example https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.isclose.h… [2] https://github.com/aroberge/experimental [3] https://github.com/aroberge/experimental/blob/master/experimental/transform… [View Less]

6 6

Loosen 'as' assignment
by Rin Arakaki June 16, 2018

June 16, 2018

Hi, I'm wondering if it's possible and consistent that loosen 'as' assignment, for example: >>> import psycopg2 as pg >>> import psycopg2.extensions as pg.ex You can't now assign to an attribute in as statement but are there some reasons? To be honest, I'll be satisfied if the statement above become valid, but also interested in general design decisions about 'as' functionality, I mean, it can be applicable to all expression that can be left side of '=' such as 'list[n]' one,… [View More]

2 1

Allow filtered dir built in
by Steve Barnes June 15, 2018

June 15, 2018

Currently when working with interactive sessions using the dir() or dir(module) built in is incredibly useful for exploring what functionality is available in a module. (Especially the regrettable libraries or modules that add really valuable functionality but have no or limited docstrings). However I often find that when a module adds a lot of functions I need to filter those entries to be able to find the one that I need, e.g.: >>> import mpmath >>> dir(mpmath) # … [View More]

4 5

Give regex operations more sugar
by Ken Hilton June 15, 2018

June 15, 2018

Hi all, Regexes are really useful in many places, and to me it's sad to see the builtin "re" module having to resort to requiring a source string as an argument. It would be much more elegant to simply do "s.search(pattern)" than "re.search(pattern, s)". I suggest building all regex operations into the str class itself, as well as a new syntax for regular expressions. Thus a "findall" for any lowercase letter in a string would look like this: >>> "1a3c5e7g9i".findall(!%[a-z]%) … [View More]

16 39

Multiple replacement in one call [was: Give regex operations more sugar]
by Ken Hilton June 14, 2018

June 14, 2018

Just changing the subject line here, to keep things on topic Sincerely, Ken; ---------- Forwarded message --------- Date: Thu, 14 Jun 2018 17:29:03 +1000 From: Steven D'Aprano <steve(a)pearwood.info> To: python-ideas(a)python.org Subject: Re: [Python-ideas] Give regex operations more sugar Message-ID: <20180614072902.GH12683(a)ando.pearwood.info> Content-Type: text/plain; charset=us-ascii On Thu, Jun 14, 2018 at 06:33:14PM +1200, Greg Ewing wrote: > Steven D'Aprano wrote: &… [View More]

1 0

Re: [Python-ideas] Add hooks to asyncio lifecycle
by Michel Desmoulin June 13, 2018

June 13, 2018

Le 09/06/2018 à 12:33, Andrew Svetlov a écrit : > If we consistently apply the idea of hook for internal python structure > modification too many things should be changed. Import > machinery, tracemalloc, profilers/tracers, name it. > If your code (I still don't see the real-life example) wants to check a > policy change -- just do it. > > # on initialization > policy = asyncio.get_event_loop_policy() > > # somewhere in code > if … [View More]

5 12

Link accepted PEPs to their whatsnew section?
by Neil Schemenauer June 13, 2018

June 13, 2018

I'm testing "Data Classes" for Python 3.7. Awesome new feature, BTW. The PEP is the first search result when I lookup "dataclass python". Given that the PEP is not the best documentation for an end user, I wonder if we should have a link in the header section of the PEP that goes to better documentation. We could link accepted PEPs to their section of the whatsnew. Or, link to the language documentation that describes the feature.

5 4

A PEP on introducing variables on 'if' and 'while'
by Juancarlo Añez June 11, 2018

June 11, 2018

Hello @here, Is there a guide about writing (and publishing) PEPs? I'd like to write one on `while expre as v: ...` using the context semantics of `with expr as v` (not `except E as e`). Cheers,

4 8

A "within" keyword
by David Teresi June 11, 2018

June 11, 2018

One of the features I miss from languages such as C# is namespaces that work across files - it makes it a lot easier to organize code IMO. Here's an idea I had - it might not be the best idea, just throwing this out there: a "within" keyword that lets you execute code inside a namespace. For example: # A.py import types cool_namespace = types.SimpleNamespace() within cool_namespace: def foo(): print("foo run") #B.py import A within A.cool_namespace: foo() # prints "foo run" Thoughts?

11 12