Mailman 3 September 2016 - Python-ideas

Suggestion: Clear screen command for the REPL
by João Matos Oct. 4, 2016

Oct. 4, 2016

Hello, I would like to suggest adding a clear command (not function) to Python. It's simple purpose would be to clear the REPL screen, leaving the >>> prompt at the top left of the screen. This is something very basic but also very useful for newbies learning Python from the REPL. After some trial and errors it is best to start with a clean screen. Clearing the screen helps clear your mind. Historically it is a common command in interpreted languages. Best regards, JM

16 52

Delay evaluation of annotations
by אלעזר Sept. 27, 2016

Sept. 27, 2016

Hi all, Annotations of function parameters and variables are evaluated when encountered. This makes it necessary to use string representation for names that are not yet bound, which affects almost every class definition. It is also easy to forget, and the result might be a (very uninteresting) exception in certain untested paths, e.g. inside functions. Editors and IDEs also don't handle it well; for example, PyDev does not consider string-annotations as an occurrence of the name, and warns about unused imports. I propose delaying evaluation of annotation-expressions by either keeping the AST of the annotation, or turning it implicitly from EXP into "lambda: EXP". Inspection code that is interested in this information can access it be calling (or evaluating) it. It certainly isn't a backward compatible change, but I think it won't affect too much code. On the positive side, it will make annotated code much more pleasing to read, will be less surprising for beginners, and will help editors in syntax highlighting and name lookup. In short, it will shift the burden of handling type annotations from standard code to inspection code, which is where I believe it should rest. While this idea is quite obvious, I've found no clue in PEP-3107 as to why will it be a bad one (no such "rejected proposal" there), so I raise the question here. Elazar

15 72

Re: [Python-ideas] Delay evaluation of annotations
by David Mertz Sept. 25, 2016

Sept. 25, 2016

On Sep 25, 2016 11:54 AM, "אלעזר" <elazarg(a)gmail.com> wrote: > Not that I think it's a killer argument, but why a red herring? Quick search does not find such an explicit option in Gedit, PyDev and yes, Notepad++.exe. It is not a common or default option. This would equally be an argument against any syntax change, any new keyword, and likewise any new built-in. Depending on what your editor does, it would perhaps be an argument against new common names in the standard library. All of those might promote changes in tools. But the tools exist to aid working with a language, not the other way around. I would not want my editor to do that much highlighting distinction, but assuming you do, all your comments defeat your own point. If an expression being within an annotation merits different evaluation semantics, it is a vastly smaller change to say a string being in an annotation merits different syntax highlighting.

2 1

Fwd: Re: Delay evaluation of annotations
by David Mertz Sept. 25, 2016

Sept. 25, 2016

> 1. Please consider disallowing the use of side effects of any kind in annotations, in that it is not promised when it will happen, if at all. So that a change 3 years from now will be somewhat less likely to break things. Please consider doing this for version 3.6; it is feature-frozen, but this is not (yet) a feature, and I got the feeling it is hardly controversial. What you are proposing is a very large and controversial feature change. Just repeating that you think there documented 10-year old behavior is an accident doesn't make it so. This is ABSOLUTELY impossible for 3.6. my feeling is is probably oppose it for 3.7, bit that is the soonest timeframe that is even conceivable. Here's a quick, only slightly contrived, example where i want an annotation to have a side effect: def foo(a, b) -> logdef(): ... This might be used as part of a tracing, cod coverage, or timing library. Obviously it would need to do some magic to get more info about the function being logged, bit that's possible. And yes, I can think of other ways to achieve this effect (decorators maybe), but you want to make change to prohibit this use that might be in production for ten years.

1 0

Re: [Python-ideas] Python-ideas Digest, Vol 118, Issue 124
by Святослав Молодских Sept. 24, 2016

Sept. 24, 2016

23 сент. 2016 г. 20:00 пользователь <python-ideas-request(a)python.org> написал: > > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > Today's Topics: > > 1. Re: Delay evaluation of annotations (Chris Angelico) > > > ---------- Пересылаемое сообщение ---------- > From: Chris Angelico <rosuav(a)gmail.com> > To: python-ideas <python-ideas(a)python.org> > Cc: > Date: Sat, 24 Sep 2016 01:58:59 +1000 > Subject: Re: [Python-ideas] Delay evaluation of annotations > On Fri, Sep 23, 2016 at 11:58 PM, אלעזר <elazarg(a)gmail.com> wrote: > > What other context you see where the result of an expression is not intended > > to be used at all? Well there's Expression statements, which are evaluated > > for side effect. There's docstrings, which are a kind of annotations. What > > else? The only other that comes to mind is reveal_type(exp)... surely I > > don't need evaluation there. > > Function annotations ARE used. They're stored as function attributes, > just as default argument values and docstrings are. (It's not the > language's problem if you never use them.) > > >> The PEP that introduced them describes them as expressions: > > > > Syntactically, yes. Just like X in "a = lambda: X" is an expression, but you > > don't see it evaluated, do you? And this is an _actual_ expression, > > undeniably so, that is intended to be evaluated and used at runtime. > > And the X in "if False: X" is a statement, but you don't see it > evaluated either. This is an actual expression that has to be > evaluated and used just like any other does. > > >> I think its time to give up arguing that annotations aren't expressions. > >> > > > > I don't care if you call them expressions, delayed-expressions, or flying > > monkeys. The allowed syntax is exactly that of an expression (like inside a > > lambda). The time of binding of names to scope is the same (again like a > > lambda) but the evaluation time is unknown to the non-reflecting-developer. > > Decorators may promise time of evaluation, if they want to. > > Thing is, literally every other expression in Python is evaluated at > the point where it's hit. You can guard an expression with control > flow statements or operators, but other than that, it will be hit when > execution reaches its line: > > def func(x): > expr # evaluated when function called > > if cond: > expr # evaluated if cond is true > > [expr for x in range(n)] # evaluated if n > 0 > (expr for x in [1]) # evaluated when genexp nexted > expr if cond else "spam" # evaluated if cond is true > lambda: expr # evaluated when function called > > def func(x=expr): pass # evaluated when function defined > def func(x: expr): pass # evaluated when function defined > > Default arguments trip some people up because they expect them to be > evaluated when the function's called, but it can easily be explained. > Function annotations are exactly the same. Making them magically > late-evaluate would have consequences for the grokkability of the > language - they would be special. Now, that can be done, but as > Rumplestiltskin keeps reminding us, all magic comes with a price, so > it has to be strongly justified. (For instance, the no-arg form of > super() is most definitely magical, but its justification is obvious > when you compare Py2 inheritance with Py3.) > > > "Unknown evaluation time" is scary. _for expressions_, which might have side > > effects (one of which is running time). But annotations must be pure by > > convention (and tools are welcome to warn about it). I admit that I propose > > breaking the following code: > > > > def foo(x: print("defining foo!")): pass > > > > Do you know anyone who would dream about writing such code? > > Yes, side effects make evaluation time scary. But so do rebindings, > and any other influences on expression evaluation. Good, readable code > generally follows the rule that the first instance of a name is its > definition. That's why we put imports up the top of the script, and so > on. Making annotations not work that way isn't going to improve > readability; you'd have to search the entire project for the class > being referenced. And since you can't probe them at definition time, > you have to wait until, uhh, SOME time, to do that search - you never > know where the actual name binding will come from. (It might even get > injected from another file, so you can't statically search the one > file.) > > >> You want to make them fancy, give them super-powers, in order to solve > >> the forward reference problem. I don't think that the problem is serious > >> enough to justify changing the semantics of annotation evaluation and > >> make them non-standard, fancy, lazy-evaluated expressions. > >> > > > > My proposal solves the forward reference problem, but I believe in it > > because I believe it is aligned with what the programmer see. > > This is on par with a proposal to make default argument values > late-bind, which comes up every now and then. It's just not worth > making these expressions magical. > > >> > > class MyClass: > >> > > pass > >> > > > >> > > def function(arg: MyCalss): > >> > > ... > >> > > > >> > > I want to see an immediate NameError here, thank you very much > >> > > >> > Two things to note here: > >> > A. IDEs will point at this NameError > >> > >> Some or them might. Not everyone uses an IDE, it is not a requirement > >> for Python programmers. Runtime exceptions are still, and always will > >> be, the primary way of detecting such errors. > > > > How useful is the detection of this error at production? > > The sooner you catch an error, the better. Always. > > > Can you repeat that? NameError indeed happens at runtime, but the scope in > > which MyCalss was looked up for is determined at compile time - as far as I > > know. The bytecode-based typechecker I wrote rely on this information being > > accessible statically in the bytecode. > > > > def foo(): > > locals()['MyType'] = str > > def bar(a : MyType): pass > > > >>>> foo() > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > File "<stdin>", line 4, in foo > > NameError: name 'MyType' is not defined > > > > What do I miss? > > That locals() is not editable (or rather, that mutations to it don't > necessarily change the actual locals). This is equivalent to: > > def foo(): > locals()['MyType'] = str > print(MyType) > > >>> foo() > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "<stdin>", line 3, in foo > NameError: name 'MyType' is not defined > > In each case, you have to *call* foo() to see the NameError. It's > happening at run time. > > > This way or the other, the very least that I hope, is explicitly forbidding > > reliance on side-effect or any other way to distinguish evaluation time of > > annotation expressions. Annotations must be pure, and the current promise of > > evaluation time should be deprecated. > > Define "pure". Function decorator syntax goes to some lengths to > ensure that this is legal: > > @deco(arg) > def f(): pass > > PEP 484 annotations include subscripting, even nested: > > def inproduct(v: Iterable[Tuple[T, T]]) -> T: > > so you'd have to accept some measure of run-time evaluation. > > It's worth reiterating, too, that function annotations have had the > exact same semantics since Python 3.0, in 2008. Changing that now > would potentially break up to eight years' worth of code, not all of > which follows PEP 484. When Steve mentioned 'not breaking other uses > of annotations', he's including this large body of code that might > well not even be visible to us, much less under python.org control. > Changing how annotations get evaluated is a *major, breaking change*, > so all you can really do is make a style guide recommendation that > "annotations should be able to be understood with minimal external > information" or something. > > > Additionally, before making it impossible to go back, we should make the new > > variable annotation syntax add its annotations to a special object > > __reflect__, so that __reflect__.annotations__ will allow forcing evaluation > > (since there is no mechanism to do this in a variable). > > Wow, lots of magic needed to make this work. Here's my > counter-proposal. In C++, you can pre-declare a class like this: > > class Mutual2; //Pre-declare Mutual2 > class Mutual1 { > Mutual2 *ptr; > }; > class Mutual2 { > Mutual1 *ptr; > } > > Here's how you could do it in Python: > > Mutual2 = "Mutual2" # Pre-declare Mutual2 > class Mutual1: > def spam() -> Mutual2: pass > class Mutual2: > def spam() -> Mutual1: pass > > Problem solved, no magic needed. > > ChrisA > > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas >

1 0

from __pip__ import
by אלעזר Sept. 21, 2016

Sept. 21, 2016

Many proposals to add something to stdlib are rejected here with the suggestion to add such library to pypi first. As noted by someone, pypi is not as reachable as stdlib, and one should install that package first, which many people don't know how. Additionally, there is no natural distinction between 3rd party dependencies and in-project imports (at least in tiny projects). This can be made easier if the first line of the program will declare the required library, and executing it will try to download and install that library if it is not installed yet. Additionally, the 3rd party dependencies will be more explicit, and editors can then allow you to search for them as you type. Of course it is *not* an alternative for real dependency management, but it will ease the burden on small scripts and tiny projects - which today simply break with errors that many users does not understand, instead of simply asking permission to install the dependency. Elazar

15 60

Make partial a built-in
by Michel Desmoulin Sept. 21, 2016

Sept. 21, 2016

While lambda are a great tools that can do the job of partial, partial is always a superior solution when trying to curry a Python function because it's explicit and easier to debug. Having to import it everytime means I usually go for a lambda out of lazyness, but also means that most people don't know about it. If think having it in the builtins would promote cleaner, faster code, but would also facilitate and encourage coding patterns using curried functions.

15 28

Overloading operators for testing
by Arek Bulski Sept. 21, 2016

Sept. 21, 2016

I am using declarative testing a lot and I found out why unit tests are so clunky. The reason why assertEquals(a,b) is used is because if we put `assert a==b` then nose can catch the AssertionError but wont find out what was returned or expected. This could be easily overcome if we allow oveloading == operator from outside. Right now == would have to be changed for every lefhand object that is compared in the tests, builtin types including. We could use a way to change it from above, so to speak. Consider this: def __glob_eq__(a,b): if not a == b: raise FoundInequalityError(a,b) return True assert obj1 == obj2 #<-- using eq above Nose could easily catch FoundInequalityError and print whatever assertEquals would. This goes very handy when you consider declarative unit testing that I use in my project. I have a unitest.TestCase derivative and the actual testcase has a method that yields individual comparisons, like this: class TestBinary(declarativeunittest.TestCase): def alltestsinteractive(self): yield [func(1) == 2] shuffle(alist) yield [sorted(alist) == [1,2,3]] Notice that this allows to put imperative statements in between declarative cases. So shuffled() is no longer necessary in this code. :) pozdrawiam, Arkadiusz Bulski

6 5

___repr__ on collections.UserDict, collections.UserList, collections.UserString
by David Kendal Sept. 19, 2016

Sept. 19, 2016

Hi, the UserDict, UserList, and UserString classes in the collections module ought to provide __repr__ implementations along the following lines: def __repr__(self): return '%s(%r)' % (type(self).__name__, self.data) so that they give useful immediate information in the repl to the effect that they are not mere dicts/lists/strs but user-defined container types. dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/ The reason we had no idea how cats worked was because, since Newton, we had proceeded by the simple principle that essentially, to see how things work, we took them apart. If you try and take a cat apart to see how it works, the first thing you have on your hands is a non- working cat. -- Douglas Adams

1 0

divmod(): fallback to __floordiv__ and __mod__?
by Spencer Brown Sept. 19, 2016

Sept. 19, 2016

Currently, calling divmod() on a class with __floordiv__ and __mod__ defined, but not __divmod__ raises a TypeError. Is there any reason why it doesn't fallback to (self // x, self % x)? The invariants described in the function documentation should still apply (with well behaved % and //). If divmod() doesn't make sense setting it to None should be permitted. - Spencer

6 9