Mailman 3 February 2017 - Python-ideas

__repr__: to support pprint
by 语言破碎处 01 Mar '17

01 Mar '17

Hi, everyone! Oftenly, __repr__ return "{type}({args}, {kws})" problem: 1) to call .format() myself is tedious I have seen someone do it wrong: "T(1,)"! I write a helper function myself, but to import such tiny function everywhere isnot good. 2) pprint cannot dive into string that from repr() To use pprint, I sometimes have to recursively turn objects into builtin containers: (type_name, args...) solution: allow __repr__ to return str OR tuple: (args, kws) Better, isn't it?

8 10

Expose a child factory using MappingProxyType in builtins
by Michel Desmoulin 01 Mar '17

01 Mar '17

We have the immutable frozenset for sets and and tuples for lists. But we also have something to manipulate dict as immutable datastructures: >>> from types import MappingProxyType as idict >>> d = idict({'a':1, 'b':2, 'c':3}) >>> d['a'] = 4 Traceback (most recent call last): File "<ipython-input-3-c6f93d6278af>", line 1, in <module> d['a'] = 4 TypeError: 'mappingproxy' object does not support item assignment We could expose this as a built type to allow the last of the most important data structure in Python to be easily immutable.

7 7

unify usage of mutable and immutable objects
by 语言破碎处 28 Feb '17

28 Feb '17

Hi! I write a '<'-based immutable set class. But it is quit different from the standard set class. I wish collections.abc.Set be more friendly to immutable tree sets or Python add new syntax to unify such difference. good example: a = [] a += a # "a" is the original list a = () a += a # "a" is a new tuple bad example: a = set() a.add(1) # return None; "a" changed e = a.pop(); a = frozen_tree_set() a = a.add(1) # return another set; e, a = a.ipop() # return two objects instead of one! solution I used: a <<= 1 # <==> a = a.add(1) but "a.ipop()" .... my current solution is to write a wrapper class to turn immutable set into mutable set, but it is so noisy to box and unbox. solution that I wish: a :=.add(1) # "=." mimic "+="; return the result object e ~ a :=.pop() d[key] :=.add(1) # in dict if only python add following features: 1) modify the original object 1-0) 1) define: def .method(self):... # "." means "intend to modify self" # return any thing # to avoid immutable method # which was intended to return new object # leave self unchanged 2) invoke: r = a..method(); 1-1) ignore result # no matter what returned, discard it a.-.method(); # <==> [a..method(), None][-1] 1-2) return self # no matter what returned, return self a.>.method().>.method();# <==> [a..method(), a..method(), a][-1] 2) create new object 2-0) 1) define # intend to return (result, new object) def ^method():... 2)invoke: r, a' = a.^method(); 2-1) return other, discard result a.-^method().-^method();# <==> a.^method()[1].^method()[1]; 2-2) assign other to original variable a=^method(); # <==> a = a.^method()[1]; 3) unify both: a :=.method(); # if defined ".method" then "a..method();" # elif defined "^method" then "a = a.^method()[1];" # elif defined "method" then "a.method();" # else error r ~ a :=.method(); # if defined ".method" then "r = a..method();" # elif defined "^method" then "r, a = a.^method();" # elif defined "method" then "r = a.method();" # else error

4 7

Optional argument to fnmatch functions treat * and ** differently
by Aaron 28 Feb '17

28 Feb '17

Hello, I would like fnmatch.fnmatch to have a mode where: ** matches any files and zero or more directories and subdirectories (i.e. the current behaviour of *) * matches in one path level/only to the next path separator This is essentially achievable in glob.glob from version 3.5 (with recursive=True), but glob is not suitable for my use case, as I need to work with strings and not files. I would like to gauge whether adding such behaviour behind an optional argument similar to glob's "recursive" (e.g. "glob_asterisks=False") is likely to be accepted into the standard library, before I start working on a patch. I have seen people raise the question of how to achieve this in a number of places. Somebody has also forked the Python 2 standard library fnmatch module to implement this as a standalone library: https://github.com/kianxineki/python-wildcard (which shows that the actual changes are likely to be pretty small). This request is also discussed in the following bug: http://bugs.python.org/issue28718 Not directly on point, but some may find the discussion interesting: http://stackoverflow.com/questions/18341848/fnmatch-and-recursive-path-matc… http://stackoverflow.com/questions/27726545/python-glob-but-against-a-list-… I would appreciate any thoughts. Kind regards, Aaron

1 0

Another use case for the 'lazy' (aka 'delayed') keyword
by Michel Desmoulin 28 Feb '17

28 Feb '17

The debate on the 'lazy' keyword seems to have settled, but I don't know if somebody is trying to write a PEP about it. Anyway, I was doing something like this the other day: conf.get('setting_name', load_from_db('setting_name')) And then realized I could save a query not doing the load_from_db() call most of the time. But dict.get didn't accept callable so I couldn't do: conf.get('setting_name', lambda key: load_from_db('setting_name')) Which is standard practice in a lot of popular Python libs on Pypi. Instead I did: val = conf.get('setting_name') if val is None: val = load_from_db('setting_name') Which is way more verbose. It also has a bug if None is a valid configuration value or if I expect my code to be thread safe. It was not a problem for me, but in that case one would even have to do: try: val = conf['setting_name'] except KeyError: val = load_from_db('setting_name') Which is even more verbose. I was going to suggest to python-ideas to update the dict.get() signature to accept a callable, but it would break compatibility with many code actually getting a callable. We could do it for Python 4, but it's far way. Instead, I think it's a good example of were 'lazy' could help. You can't get simpler than: conf.get('setting_name', lazy load_from_db('setting_name'))

8 20

math.nextafter
by Juraj Sukop 28 Feb '17

28 Feb '17

Hello! Function `nextafter(x, y)` returns the next representable value of `x` in the direction of `y`, and if `x` equals to `y`, `y` is returned. [1] It is useful for incrementing/decrementing floating-point number by the smallest amount possible or for testing if two numbers are closest to each other without being the same. The following snippet written by Mark Dickinson emulates the functionality in pure Python [2]: import math import struct def next_up(x): # NaNs and positive infinity map to themselves. if math.isnan(x) or (math.isinf(x) and x > 0): return x # 0.0 and -0.0 both map to the smallest +ve float. if x == 0.0: x = 0.0 n = struct.unpack('<q', struct.pack('<d', x))[0] if n >= 0: n += 1 else: n -= 1 return struct.unpack('<d', struct.pack('<q', n))[0] def next_down(x): return -next_up(-x) def next_after(x, y): # If either argument is a NaN, return that argument. # This matches the implementation in decimal.Decimal if math.isnan(x): return x if math.isnan(y): return y if y == x: return y elif y > x: return next_up(x) else: return next_down(x) Other implementations can be found at [3], [4] or [5], for example. It would be useful to have `math.nextafter` function available in standard library, it also is provided by C99 <math.h>, and is similar in spirit to `math.copysign` or `math.isclose`. As to why to include it by default when the above snippet works just fine, a C implementation is likely to be much faster than using `struct.pack` and `struct.unpack`. Thank you for considering this proposal and any feedback is greatly welcomed! Juraj Sukop [1] http://en.cppreference.com/w/c/numeric/math/nextafter [2] http://stackoverflow.com/a/10426033 [3] http://git.musl-libc.org/cgit/musl/tree/src/math/nextafter.c [4] https://github.com/android/platform_bionic/blob/master/libm/upstream-freebs… [5] https://github.com/golang/go/blob/master/src/math/nextafter.go

13 22

Make Path objects iterable
by Vamsi Krishna Avula 27 Feb '17

27 Feb '17

This is somewhere between a question and a proposal. I'm just trying to understand why Path objects use an explicit iterdir method. Why not make them iterable? -- Vamsi

3 2

if in for-loop statement
by Henk-Jaap Wagenaar 24 Feb '17

24 Feb '17

Hi all, Often I have typed something like for x in range(100) if is_prime(x): # do things with x to find that this does not work, instead resorting to: for x in range(100): if is_prime(x): # do things with x or for x in range(100): if not is_prime(x): continue # do things with x Other solutions to another case of this 'problem' are discussed has been discussed on StackOverflow ( http://stackoverflow.com/questions/6981717/pythonic-way-to-combine-for-loop…) where it is suggested one uses a generator expression before the loop. None of these solutions seem very Pythonic to me. I appreciate there is a cost associated with changing the language syntax, and I do not understand all the finer details of the inner workings involved with the Python language development, however in my limited understanding in it would be: - fully backwards compatible, - require one to change "expression_list" to "or_test [comp_iter]" in the syntax of the for statement (if I got it right). - it would mean there is a Pythonic solution to a current 'problem' that does not have one. A few problems I foresee: - One wants for loops to bleed their target_list (that is the point normally), so this is different from generators, - This allows for nesting of generators, like in a generator expression which might be hard to implement? Note that this has been suggested before at least once ( https://mail.python.org/pipermail/python-dev/2007-November/075257.html), and that thread itself suggests it has been suggested before and shutdown by Guido (though no source is given for this). All the best, Henk-Jaap Wagenaar

7 16

Fwd: Define a method or function attribute outside of a class with the dot operator
by Markus Meskanen 23 Feb '17

23 Feb '17

> > That saves one line, at the cost of introducing even more complexity to > the language. > > Are these use-cases common enough to justify the extra syntax? > Keep in mind that the extra syntax is *very* minor, and goes hand-to-hand with the existing attribute access syntax. Basically it's taking the existing syntax to one more place, where it in my opinion should have been since long ago. > What advantage does this proposed syntax have? > > Since that's not actually a rhetorical question, I'll answer it myself: > > def Spam.method(self) not only saves the line > > Spam.method = method > > but it also avoids leaving a global name "method" in the namespace (no > need to follow with `del method`); it makes it explicit from the > beginning that the function is an attribute of Spam. > Yeah this is a major reason why I want this, and the reason I mentioned "unnatural order" in the original mail. Having the class's name in the beginning just makes it feel right.. > If the implementation is clever enough, it can avoid clashing with a > global of the same name: > > eggs = "something" > > def Spam.eggs(self): > ... > > def Cheese.eggs(self): > ... > > assert eggs == "something" > > > So the idea isn't without merit; but the question in my mind is whether > the advantages outweigh the extra complexity. I didn't even realize you would avoid the global namespace issue too, this makes me fall in love with the idea even more. I really think the added complexity isn't much. One thing to consider, however, is what would happen if someone attempted to use this in a class definition: class Foo: ... class Bar: def Foo.meth(self): ...

24 63

Re: [Python-ideas] if in for-loop statement
by Régis Martin 23 Feb '17

23 Feb '17

Hello, why not using the filter function? for x in filter(is_prime, range(100)): # do something with x This is equivalent as was mentionned at first: for x in range(100) if is_prime(x): # do things with x Régis -- Régis Martin Directeur de Projets Astek Industrie Tel: 06-83-53-15-05 http://www.groupeastek.com/

2 1