Mailman 3 May 2018 - Python-ideas

Yet another idea for assignment expressions
by Ken Hilton 02 May '18

02 May '18

Hi all, I've been following the discussion of assignment expressions and what the syntax for them should be for awhile. The ones that seem to crop up most are the original spelling, :=, the "as" keyword (and variants including it), and the recently "local" pseudo-function idea. I have another idea for a spelling of assignment expressions, mostly inspired by real sentence structure. In a review I was writing recently, I referred to CGI, Computer Generated Imagery. As a way of introducing the full term and its abbreviation, I said "Computer Generated Imagery (CGI)". That got me thinking: why not have something similar in Python? Obviously simple parentheses ("expr(name)") definitely wouldn't work, that's a function call. Similarly, brackets ("expr[name]") would be interpreted as subscription. So why not use curly brackets, "expr{name}"? That doesn't conflict with anything (currently it's a syntax error), and could be documented appropriately. Going back to the regex example, this is how it would look in that case: if re.match(exp, string){m}: print(m.group(0)) I am currently unsure how it would affect scope. I think it should be effectively equivalent to a regular assignment statement (and hence follow identical scope rules), i.e. the above example would be equivalent to the following in all ways except syntax: m = re.match(exp, string): if m: print(m.group(0)) Thoughts? Please do let me know if there's some critical flaw with this idea that I missed (or tell me if it's an amazing idea ;)), and just give feedback, I guess. Sincerely, Ken;

3 2

Objectively Quantifying Readability
by Matt Arcidy 02 May '18

02 May '18

The number and type of arguments about readability as a justification, or an opinion, or an opinion about an opinion seems counter-productive to reaching conclusions efficiently. I think they are very important either way, but the justifications used are not rich enough in information to be very useful. A study has been done regarding readability in code which may serve as insight into this issue. Please see page 8, fig 9 for a nice chart of the results, note the negative/positive coloring of the correlations, grey/black respectively. https://web.eecs.umich.edu/~weimerw/p/weimer-tse2010-readability-preprint.p… The criteria in the paper can be applied to assess an increase or decrease in readability between current and proposed changes. Perhaps even an automated tool could be implemented based on agreed upon criteria. Opinions about readability can be shifted from: - "Is it more or less readable?" to - "This change exceeds a tolerance for levels of readability given the scope of the change." Still need to argue "exceeds ...given" and "tolerance", but at least the readability score exists, and perhaps over time there will be consensus. Note this is an attempt to impact rhetoric in PEP (or other) discussions, not about supporting a particular PEP. Please consider this food for thought to increase the efficacy and efficiency of PEP discussions, not as commenting on any specific current discussion, which of course is the motivating factor of sending this email today. I think using python implicitly accepts readability being partially measurable, even if the resolution of current measure is too low to capture the changes currently being discussed. Perhaps using this criteria can increase that resolution. Thank you, - Matt

13 24

Re: [Python-ideas] A way to subscript a single integer from bytes
by Ken Hilton 02 May '18

02 May '18

Whoops! Never seen that before. Nothing I searched up pointed me to it. Sorry for wasting your time! Ken; -- Sincerely, Ken;

3 2

Should __builtins__ have some kind of pass-through print function, for debugging?
by Nathaniel Smith 01 May '18

01 May '18

Hi all, This came up in passing in one of the PEP 572 threads, and I'm curious if folks think it's a good idea or not. When debugging, sometimes you have a somewhat complicated expression that's not working: # Hmm, is func2() returning the right thing? while (func1() + 2 * func2()) < func3(): ... It'd be nice to print out what func2() returns, but to do that we have to refactor this code, which might be rather tricky in a case like this. I think if you want to use print() directly here, the simplest way to do that is: while True: tmp = func2() print(tmp) if not (func1() + 2 * func2()) < func3()): break ... Obviously this is annoying and error prone – especially for beginners, who are the ones most likely to need to print out lots of stuff to figure out why their code isn't working. (Chris Angelico mentioned that he finds this to be a common problem when teaching beginners.) There is a better way: if you define a trivial helper like: # "debug print": prints and then returns its argument def dp(obj): print(repr(obj)) return obj then the rewritten code becomes: while (func1() + 2 * dp(func2())) < func3(): ... Of course, this is trivial -- for me or you. But the leap to first realize that this is a useful thing, and then implement it correctly, is really asking a lot of beginners, who by assumption are struggling to do *anything* with Python syntax. And similarly, putting a package on PyPI is useful (cf. the venerable 'q' package), but still adds a significant barrier to entry: you need to be able to install packages, and you need to add an import. In fact, I can imagine that you might want to teach this trick even before you teach what imports are. So, would it make sense to include a utility like this in __builtins__? PEP 553, the breakpoint() builtin, provides some relevant precedent. Looking at it, I see it also emphasized the value of letting IDEs override the debugger, and I can see some similar value here: e.g. fancy REPLs like Spyder or Jupyter could potentially capture the objects passed to dp() and make them available for interactive viewing (imagine if they're like a large dataframe or something). Points to argue over if people like the general idea: - The name: p(), dp(), debug(), debugprint(), ...? - __str__ or __repr__? Presumably __repr__ since it's a debugging tool. - Exact semantics: there should probably be some way to add a bit of metadata that gets printed out, for cases like: while (dp(func1(), "func1") + 2 * dp(func2(), "func2")) < dp(func3(), "func3"): ... Maybe other tweaks would be useful as well. -n -- Nathaniel J. Smith -- https://vorpus.org

9 16

A way to subscript a single integer from bytes
by Ken Hilton 01 May '18

01 May '18

Hi all, So I'm pretty sure everyone here is familiar with how the "bytes" object works in Python 3. It acts mostly like a string, with the exception that 0-dimensional subscripting (var[idx]) returns an integer, not a bytes object - the integer being the ordinal number of the corresponding character. However, 1-dimensional subscripting (var[idx1:idx2]) returns a bytes object. Example: >>> a = b'hovercraft' >>> a[0] 104 >>> a[4:8] b'rcra' Though this isn't exactly unexpected behavior (it's not possible to accidentally do 1-dimensional subscripting and expect an integer it's a different syntax), it's still a shame that it isn't possible to quickly and easily subscript an integer out of it. Following up from the previous example, The only way to get 493182234161465432041076 out of b'hovercraft' in a single expression is as follows: list(__import__('itertools').accumulate((i for i in a), lambda x, y: (x << 8) + y))[-1] Now, I'm not proposing changing the 1-dimensional subscripting syntax to return an integer - that would be backwards incompatible, tsk tsk! No, instead, I'm simply suggesting a method of bytes objects, which would do something like this (assume the method is called "subint"): >>> a = b'hovercraft' >>> a.subint(0, -1) # -1 is equivalent to len(a) 493182234161465432041076 Much as I would think that such subscripting would deserve special syntax (perhaps bytes{idx1:idx2}), I don't think this special case is special enough to break the rules. So I'm sticking with the method idea. What are your thoughts? Sincerely, Ken;

4 3