Mailman 3 April 2018 - Python-ideas

Change magic strings to enums
by Jacco van Dorp April 30, 2018

April 30, 2018

A bit ago I was reading some of the python docs ( https://docs.python.org/3.6/library/warnings.html ), the warning module, and I noticed a table of magic strings. I can think of a few other places where magic strings are used - for example, string encoding/decoding locales and strictness, and probably a number of other places. Since Python 3.4, We've been having Enums. Wouldn't it be cleaner to use enums by default instead of those magic strings ? for example, for warnings filter actions, (section 29.5.2), quite near the top of the page. You could declare in the warnings module: class FilterAction(Enum): Error = 'error' Ignore = 'ignore' Always = 'always' Default = 'default' Module = 'module' Once = 'once' And put in the docs that people should use enums. For as long as a transition period would last, any entrypoint into the module where currently the magic string is used, you could transform it with the single line: action = FilterAction(action) # transforms from old magic string to shiny new enum member Then whenever enough people have shifted/4.0 comes around, the string argument version can be deprecated. Pro's - no magic strings - more clarity - easier to get all possible values with for example type checking editors (because of the type annotation) Con's : - implementation effort (as long as the modules are in pure Python, I could perhaps help. Im not to confident about my C skills tho) Backwards compatibility wouldn't be an issue because of the easy transformation from the old string as long as we use those string as the enum values. ofc, precise names of enums/members is up for debate. I personally prefer the above version to ALLCAPS, but that might be my comparitive lack of C experience. These named constants are generally done in all caps, but they're also often because of lack of a simple enum class. I tried to search for this, but couldn't find any discussion about it. Apologies if this has been rejected before. Jacco

11 30

Re: [Python-ideas] A "local" pseudo-function
by Ken Hilton April 29, 2018

April 29, 2018

> local { m = re.match(regexp, line) > if m: > print(m.group(0)) > } Or how about making "local" a pseudo-statement of sorts? local (m=re.match(exp, string)) { if m: print(m.group(0)) } The grammar would be as follows: local_stmt = "local" "(" local_assignments [ "," local_assignments ... ] ")" "{" BLOCK "}" local_assignments = NAME "=" EXPR There would be no question about the scope of things in BLOCK - the variables would disappear after the closing "}". I say "pseudo"-statement because I'm wondering if something like this would be legal: things = list(map(lambda m: local (gp1=m.group(1)) { result = gp1 + ''.join(reversed(gp1)) result += gp1.replace('some', 'thing') return result }, re.finditer(exp, string))) I'm thinking specifically about the "lambda m: local (...) {...}". If that was made legal, it would finally allow for full-fledged anonymous functions. Indeed, the "local" (statement?) itself is actually almost equivalent to defining an anonymous function and executing it immediately, i.e. this: (lambda x=5: x*x)() would be equivalent to this: local (x=5) { return x * x } both evaluating to 25. Just some random thoughts! Sincerely, Ken Hilton ;

2 1

Re: [Python-ideas] __loader__.get_source(): semantics of returning None
by Jeroen Demeyer April 29, 2018

April 29, 2018

On 2018-04-28 18:26, Paul Moore wrote: > """ > If a file named filename is not found, the function will look for it > in the module search path, sys.path, after first checking for a PEP > 302 __loader__ in module_globals, in case the module was imported from > a zipfile or other non-filesystem import source. > """ Sorry, I should have been more precise. linecache does the following (which is what is in the doc you quoted above): (1) Look for the filename exactly as given. (2) Look for a loader and call its get_source() method. (3) Look for the filename under all sys.path entries. The difference between (1) and (3) is when a relative filename is given, typically relative to site-packages. And I'm actually interested in that third case. So the question is really: should (3) still be tried if __loader__.get_source() returns None? Jeroen.

2 1

__loader__.get_source(): semantics of returning None
by Jeroen Demeyer April 28, 2018

April 28, 2018

The documentation of __loader__.get_source() says "Returns None if no source is available (e.g. a built-in module)." But what does "no source is available" mean precisely? It could mean either of two things: (A) I am absolutely certain that there is no source anywhere to be found. (B) I don't know where to find the source, but if you look hard enough, you may find it. Currently, linecache interprets it as (A). Is there any chance that we can either change the interpretation for returning None to (B) or to provide an officially documented way to answer (B)? This could be using a new return value (say, NotImplemented) or by not implementing get_source at all (such that __loader__.get_source raises AttributeError). The latter is probably how things already work in practice, but it isn't really documented that way. The context for this question/proposal is https://bugs.python.org/issue32797 When the linecache module is asked for the source code of a certain file, it queries the __loader__.get_source() for the source code. If this returns None, that's the end: no source is returned. However, linecache is also passed the filename! So even if it could find the source by filename, it won't even try that if get_source() returns None. Jeroen.

2 1

Re: [Python-ideas] Should __builtins__ have some kind of pass-through print function, for debugging?
by Ken Hilton April 28, 2018

April 28, 2018

Perhaps there could be a special magic method that classes could implement for such a function? I.e. something like this: class Pizza(object): diameter = 1 toppings = [] def __init__(self, diameter=1, toppings=[]): self.diameter = diameter self.toppings = toppings def __str__(self): return '{}-inch pizza, toppings: {}'.format(self.diameter, ', '.join(self.toppings)) def __repr__(self): return '<{}-inch Pizza>'.format(self.diameter) def __dprint__(self): return '<Pizza: {}>'.format(self.__dict__) This is just an idea on the side - basically, have a new magic method for "dprint" (or whatever it should be called) that returns a separate string form of an object to be debug-printed. So the following example (following up from the Pizza example): def cheesepizza(size): return Pizza(size, ['cheese']) print(cheesepizza(1)) print(repr(cheesepizza(1))) print(dprint(cheesepizza(1))) Should produce the following output: 1-inch pizza, toppings: cheese <1-inch Pizza> <Pizza: {'toppings': ['cheese'], 'diameter': 1}> 1-inch pizza, toppings: cheese Note the last line - remember, dprint passes through the first argument, printing it in the process. So ``print(dprint(x))`` should first output ``x.__dprint__ + '\n'`` then output ``x.__str__ + '\n'``. Behavior note: if __dprint__ is not available, fall back to __str__. Such an extra magic method would be useful if the class should have a different representation when debugging (i.e. maybe something makes use of repr(x), but dprint(x) should only be used for debugging so it shows more information). Also remember that it's totally plausible to simply state dprint(cheesepizza(1)) and thereby throw away the return value; such use would be like "print" but more verbose (again assuming __dprint__ is implemented). I would also like to ask whether "dprint" should support the same keyword arguments as "print" - i.e. "end", "file", and so on. IMO it should, as the only difference is that "dprint" returns its first argument while "print" returns None. But what are your thoughts? Sincerely, Ken Hilton ;

2 1

Re: [Python-ideas] [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
by Steven D'Aprano April 28, 2018

April 28, 2018

On Fri, Apr 27, 2018 at 04:24:35PM -0400, Wes Turner wrote: > if ((1) or (x := 3)): > if ((y := func(x)) if x else (x := 3)) Wes, there is *absolutely nothing new* here. This sort of error is already possible in Python. Do you see a lot of code like: if (1 or sequence.append(3) or sequence[-1]): in real life? If you do, then I'm really, really sorry that you are forced to deal with such rubbish code, but honestly, the vast bulk of Python programmers do not write like that, and they won't write this either: if (1 or (x := 3)): [...] > Assignment expressions, though they are noticeable :=, may not actually > define the variable in cases where that part of the line doesn't run but > reads as covered. The same applies to any operation at all. /sarcasm I guess adding print() to the language was a mistake, because we can write rubbish code like this: if 1 or print(x): and then be confused by the fact that x doesn't get printed. /end sarcasm In another post, you insisted that we need to warn in the PEP and the docs not to do this sort of thing. Should we also go through and add these warnings to list.append, dict.update, set.add, etc? I trust that the answer to that is obviously no. And neither do we have to assume that people who use binding-expressions will lose their minds and start writing the sort of awful code that they don't write with anything else. -- Steve

1 1

Re: [Python-ideas] Change magic strings to enums
by Jeroen Demeyer April 25, 2018

April 25, 2018

On 2018-04-25 09:57, Ivan Levkivskyi wrote: > In the latter case rewriting EnumMeta in C ... or Cython. It's a great language and I'm sure that the Python standard library could benefit a lot from it.

2 1

collections.Counter should implement __mul__, __rmul__
by Peter Norvig April 23, 2018

April 23, 2018

For most types that implement __add__, `x + x` is equal to `2 * x`. That is true for all numbers, list, tuple, str, timedelta, etc. -- but not for collections.Counter. I can add two Counters, but I can't multiply one by a scalar. That seems like an oversight. It would be worthwhile to implement multiplication because, among other reasons, Counters are a nice representation for discrete probability distributions, for which multiplication is an even more fundamental operation than addition. Here's an implementation: def __mul__(self, scalar): "Multiply each entry by a scalar." result = Counter() for key in self: result[key] = self[key] * scalar return result def __rmul__(self, scalar): "Multiply each entry by a scalar." result = Counter() for key in self: result[key] = scalar * self[key] return result

10 37

Checking interned string after stringobjects concat?
by Yinbin Ma April 22, 2018

April 22, 2018

Hi all: I notice that if concatenating two stringobjects, PVM will not check the dictionary of interned string. For example: >>> a = "qwerty" >>> b = "qwe" >>> c = "rty" >>> d = b+c >>> id(a) 4572089736 >>> id(d) 4572111176 >>> e = "".join(["qwe","rty"]) >>> id(e) 4546460280 But if concatenating two string directly, PVM would check the dictionary: >>> a = "qwerty" >>> b = "qwe"+"rty" >>> id(a) 4546460112 >>> id(b) 4546460112 It happens in Py2 and Py3 both. Is it necessary for fixing this bug or not? Cheers! --- Yinbin

5 6

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)
by Thautwarm Zhao April 19, 2018

April 19, 2018

> > > 0. > > while (items[i := i+1] := read_next_item()) is not None: > print(r'%d/%d' % (i, len(items)), end='\r') > > 1. > > while (read_next_item() -> items[(i+1) -> i]) is not None: > print(r'%d/%d' % (i, len(items)), end='\r') > > 2. > > while (item := read_next_item()) is not None: > items[i := (i+1)] = item > print(r'%d/%d' % (i, len(items)), end='\r') > > 3. > > while (read_next_item() -> item) is not None: > items[(i+1) -> i] = item > print(r'%d/%d' % (i, len(items)), end='\r') > > 4. > > while (item := read_next_item()) is not None: > i = i+1 > items[i] = item > print(r'%d/%d' % (i, len(items)), end='\r') > > 5. > > while (read_next_item() -> item) is not None: > i = i+1 > items[i] = item > print(r'%d/%d' % (i, len(items)), end='\r') > > Also 2 or 3. The 3rd one is in the order of natural language, just like: while get then next item and assign it to `item`, if it's not None, do some stuff. However just as we have pointed out, the semantics of '->' is quite different from the cases it's currently used at, so it should be handled much more carefully. I think maybe we can use unicode characters like ≜ (\triangleq) and add the support of unicode completion to python repl. The unicode completion of editors or ides has been quite mature.

4 3