Mailman 3 May 2017 - Python-ideas

pdb / bdb adding watchpoint ability
by Louie Lu 25 May '17

25 May '17

Hi all, Current pdb and bdb didn't have the ability to create a watchpoint for variable. Such in gdb, it have a series of watchpoint function*: * watch : break when expression value changed * rwatch : break when read value from expression * awatch: breka when read or write value to expression In Python, there have some problem in rwatch implement, that we can't directly know what variable is been read or not. This will need to used the dis module to get the bytecode and to know if the variable is been read (load) or not. The b.p.o issue is open at here: http://bugs.python.org/issue30429 And the current implement is at: https://github.com/python/cpython/pull/1756 How do you think about this ability to put in pdb/bdb? -Louie

1 0

Suggestion: push() method for lists
by Paul Laos 22 May '17

22 May '17

It would be nice to have the opposite of the pop() method: a push() method. While insert() and append() already exist, neither is the opposite of pop(). pop() has a default index parameter -1, but neither insert() nor append() has a default index parameter. push(obj) would be equivalent to insert(index = -1, object), having -1 as the default index parameter. In fact, push() could replace both append() and insert() by unifying them. By default push(obj) would insert an object to the end of the list, while push(obj, index) would insert the object at index, just like pop() removes (and returns) the object at the end of the list, and pop(index) removes (and returns) the object at the index. I found little discussion on this, just this SO thread http://stackoverflow.com/questions/1566266/why-is-pythons-append-not-push which lead to a discussion from 20 years ago (1997): <https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYm> https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg <https://groups.google.com/forum/#!topic/comp.lang.python/SKJq3S2ZYmg> Some key arguments from the thread: >it would be an >easy and obvious improvement to make popend an explicit builtin, and >that this would make Python even more attractive to newcomers who want >to use what they already know and be immediately productive. - Terry Reedy >append() is a special case of insert(). The inverse of insert() is >the del function. The specific inverse of append() is del list[-1]. - Michael W. Ryan >but I'm not a big fan of multiple names for the same operation -- >sooner or later you're going to read code that uses the other one, so >you need to learn both, which is more cognitive load. - Guido van Rossum So while it has been discussed before, it's worth bringing up again, since this was before the release of Python 2.0. Pros: - Would simplify the language by having a symmetric relation to pop(). - Would make it easy to use lists as stacks. - Saves at least two characters - If append()/insert() are being removed and replaced, the complexity of lists is slightly reduced. Cons: - Would blur the line between lists and stacks. - The order of the parameters in push(obj, index = -1) would be the opposite of the parameters in insert(index, obj), because defaulted parameters come last. - If append()/insert() are being removed and replaced, backwards compatability breaks. - If append()/insert() are kept instead of being replaced, the complexity of lists is slightly increased. While it isn't a necessity, I believe the benefit of push() method outweighs its cons. ~Paul

5 5

fnmatch.filter_false
by Alex Walters 21 May '17

21 May '17

Fnmath.filter works great. To remind people what it does, it takes an iterable of strings and a pattern and returns a list of the strings that match the pattern. And that is wonderful However, I often need to filter *out* the items that match the pattern (to ignore them). In every project that I need this I end up copying the function out of the fnmatch library and adding 'not' to the test clause. It would be wonderful if there was a filter_false version in the standard library. Or in inversion Boolean option. Or something, to stop from having to copy code every time I need to ignore files.

7 15

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)
by Tin Tvrtković 19 May '17

19 May '17

Hello, I'm an attrs contributor so maybe I can clear up any questions. Convert callables are only called in __init__, not in the setters. We've had this requested a number of times and we will almost certainly support it in the future, probably on an opt-in basis. The reason we don't currently support it is mostly technical. We try really hard for our features to not add significant overhead to the generated classes, and doing this with minimal overhead for slot classes basically requires C/Cython or attribute *access* becomes significantly slower. But this is implementation stuff and not pertinent here. Date: Fri, 19 May 2017 20:49:08 +0200 > From: Stephan Houben <stephanh42(a)gmail.com> > To: guido(a)python.org > Cc: "Eric V. Smith" <eric(a)trueblade.com>, Python-Ideas > <python-ideas(a)python.org> > Subject: Re: [Python-ideas] JavaScript-Style Object Creation in Python > (using a constructor function instead of a class to create objects) > Message-ID: > <CAOOa=pOBk8i1+sy+sZ4C+oLwhZzhLAjNRNiaEh8N9Srv= > pxDNw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Guido, > > Yes indeed, *only* invoked by __init__ . > > See my test below. > ===== > import attr > > @attr.s > class Foo: > x = attr.ib(convert=str) > > foo = Foo(42) > print(repr(foo.x)) > # prints '42' > foo.x = 42 > print(repr(foo.x)) > # prints 42 > ====== > > Not sure if this is a good design but it matches the docs. > > Stephan > > Op 19 mei 2017 20:36 schreef "Guido van Rossum" <guido(a)python.org>: > > So it is only called by __init__ and not by __setattr__? > > On Fri, May 19, 2017 at 11:32 AM, Stephan Houben <stephanh42(a)gmail.com> > wrote: > > > Let me quote the attrs docs: > > > > "" > > convert (callable) ? callable() that is called by attrs-generated > __init__ > > methods to convert attribute?s value to the desired format. It is given > the > > passed-in value, and the returned value will be used as the new value of > > the attribute. The value is converted before being passed to the > validator, > > if any. > > """ > > > > So the signature is essentially: > > > > self.myattrib = callable (myattrib) > > > > Stephan > > > > Op 19 mei 2017 20:25 schreef "Guido van Rossum" <guido(a)python.org>: > > > > For people who don't want to click on links: > >> > >> 1. Allow hash and equality to be based on object identity, rather than > >> structural identity, > >> this is very important if one wants to store un-hashable objects in > >> the instance. > >> (In my case: mostly dict's and numpy arrays). > >> > >> 2. Not subclassed from tuple. I have been bitten by this subclassing > >> when trying to set up > >> singledispatch on sequences and also on my classes. > >> > >> 3. Easily allow to specify default values. With namedtuple this > >> requires overriding __new__. > >> > >> 4. Easily allow to specify a conversion function. For example I have > >> some code like below: > >> note that I can store a numpy array while keeping hashability and > >> I can make it convert > >> to a numpy array in the constructor. > >> > >> @attr.s(cmp=False, hash=False) > >> class SvgTransform(SvgPicture): > >> child = attr.ib() > >> matrix = attr.ib(convert=numpy.asarray) > >> > >> > >> I have one question about (4) -- how and when is the conversion > function used, and what is its signature? > >> > >> > >> On Fri, May 19, 2017 at 5:42 AM, Eric V. Smith <eric(a)trueblade.com> > >> wrote: > >> > >>> Could you point me to this 4-point list of Stephan's? I couldn't find > >>>> anything in the archive that you might be referring to. > >>>> > >>> > >>> Never mind, I found them here: > >>> https://mail.python.org/pipermail/python-ideas/2017-May/045679.html > >>> > >>> Eric. > >>> > >>> > >>> _______________________________________________ > >>> Python-ideas mailing list > >>> Python-ideas(a)python.org > >>> https://mail.python.org/mailman/listinfo/python-ideas > >>> Code of Conduct: http://python.org/psf/codeofconduct/ > >>> > >> > >> > >> > >> -- > >> --Guido van Rossum (python.org/~guido) > >> > >> _______________________________________________ > >> Python-ideas mailing list > >> Python-ideas(a)python.org > >> https://mail.python.org/mailman/listinfo/python-ideas > >> Code of Conduct: http://python.org/psf/codeofconduct/ > >> > >> > >

1 0

PEP 526: why ClassVar instead of ClassAttr?
by Steven D'Aprano 18 May '17

18 May '17

Since PEP 526 is already provisionally accepted, it may be too late to bring this up, but I have a question and suggestion about the name ClassVar. I've read the PEP but didn't see an answer or rejection to this. https://www.python.org/dev/peps/pep-0526/ Why choose ClassVar over ClassAttr when the usual terminology used in the Python community is class and instance *attributes* rather than "variables"? I understand that, in a sense, attributes are variables (unless they're constants *wink*) but the term "class variable" sounds very Java-esque rather than Pythonic. And it is an uncomfortable fit with a language like Python where classes are first class values like ints, strings, floats etc: - we talk about a string variable meaning a variable holding a string; - a float variable is a variable holding a float; - a list variable is a variable holding a list; - so a class variable ought to be a variable holding a class. I get the intention: we have local, global, instance and class variables. But I feel that grouping instance/class with local/global is too abstract and "computer sciencey": in practice, instance/class vars are used in ways which are different enough from global/local vars that they deserve a different name: attributes, members or properties are common choices. (Python of course uses attributes, and properties for a particular kind of computed attribute.) This introduces split terminology: we now talk about annotating class attributes with ClassVar. Since there's no GlobalVar, NonLocalVar or LocalVar, there doesn't seem to be any good reason to stick with the FooVar naming system. Can we change the annotation to ClassAttr instead? -- Steve

6 8

Tighten up the formal grammar and parsing a bit?
by Hugh Fisher 18 May '17

18 May '17

I wrote this little Python program using CPython 3.5.2. It's ... interesting ... that we apparently don't need comments or pass statements any more. Anyone else think it might be worth tightening up the grammar definition and parser a bit? def empty(): """Don't do anything""" def helloWorld(): """Docstring""" x = 0 if x > 0: """Pass""" else: x += 1 print(x) """Comment that is a string or vice versa""" x = 2 print(x) if x == 2: x += 1 ;"Add 1 to x" print(x) if x == 3: 42 print("Answered everything") if __name__ == "__main__": helloWorld() print(empty()) -- cheers, Hugh Fisher

6 9

Running C extension modules using -m switch
by gmarcel.plch＠gmail.com 17 May '17

17 May '17

Greetings, I'm a student that has been working lately on feature of the runpy module that I have been quite interested in: execution of extension modules using the -m switch. Currently this requires access to the module's code, so it only works for modules written in Python. I have a proof-of-concept implementation that adds a new ExtensionFileLoader method called "exec_as_main". The runpy module then checks if the loader has this method, and if so, calls it instead of getting the the code and running that. This new method calls into the _imp module, which executes the module as a script. I can see two ways of doing this. Both expect that the module uses PEP 489 multi-phase initialization. The first way is having a new PyModuleDef_Slot called Py_mod_main, which names a function to execute when run as main. The second way is running a module's Py_mod_exec inside the __main__ module's namespace, as it's done for normal modules. The module would then do a `if __name__ == "__main__"` check. This is possible for modules that don't define Py_mod_create: they expect a default module object to be created for them, so we can pass the __main__ module to their Py_mod_exec function. This way would mean that, for example, modules written in Cython would behave like their Python counterparts. Another possibility would be to use both, allowing both easy Cython- style modules and a dedicated slot for modules that need custom Py_mod_create. My proof of concept uses another combination: it requires Py_mod_main and runs it in the __main__ namespace. But that can change based on discussion here. Link to the implementation: https://github.com/Traceur759/cpython/tree/ main_c_modules Diff from master: https://github.com/python/cpython/compare/master...Tr aceur759:main_c_modules You can quickly test it with: $ ./python -m _testmultiphase This is an extension module named __main__

1 0

Re: [Python-ideas] Python-ideas Digest, Vol 126, Issue 35
by Tin Tvrtković 16 May '17

16 May '17

I have it on good authority both Hynek (the author of attrs) and Glyph will be attending PyCon. I think it'd be a shame if they weren't involved with this effort somehow. > Message: 2 > Date: Tue, 16 May 2017 07:53:50 -0700 > From: Guido van Rossum <guido(a)python.org> > To: Ivan Levkivskyi <levkivskyi(a)gmail.com> > Cc: ????? <elazarg(a)gmail.com>, "python-ideas(a)python.org" > <python-ideas(a)python.org> > Subject: Re: [Python-ideas] JavaScript-Style Object Creation in Python > (using a constructor function instead of a class to create objects) > Message-ID: > <CAP7+vJJynk+mQTJfVxaVxXO5QNbE2sU0MrXhJZweP > kmcD7hSKA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I could also try this myself in my spare time at PyCon (surprisingly, I > have some!). It sounds kind of interesting. However I've never used the > 'attrs' package... > > On Tue, May 16, 2017 at 7:52 AM, Ivan Levkivskyi <levkivskyi(a)gmail.com> > wrote: > > > On 15 May 2017 at 18:22, Guido van Rossum <guido(a)python.org> wrote: > > > >> I expect that we will need someone with a really good sensibility for > >> Pythonic language/API design to lead the PEP writing. > >> > > > > I probably don't have good sensibility for Pythonic API design yet (and I > > am more focused on PEP 544) so I cannot lead this, > > but I would like to actively participate in writing. > > > > -- > > Ivan > > > > > > > > > -- > --Guido van Rossum (python.org/~guido) >

2 1

NamedTuple Interface
by Fabrizio Messina 15 May '17

15 May '17

I think it would be nice to have a generic NamedTuple interface in python: from typing import NamedTupleType def test( arguments: NamedTupleType ) -> NamedTupleType: return SomeType(**NamedTupleType._asdict) The rationale is that named tuple exposes a common API, and it would be nice to have it readily available.

1 0

Re: [Python-ideas] singledispatch for instance methods
by Bar Harel 14 May '17

14 May '17

Bump On Wed, Jan 4, 2017, 8:01 PM Lisa Roach <lisaroach14(a)gmail.com> wrote: > +1 to this as well, I think this would be really useful in the stdlib. > > On Mon, Dec 26, 2016 at 5:40 AM, Bar Harel <bzvi7919(a)gmail.com> wrote: > >> Any updates with a singledispatch for methods? >> >> On Tue, Sep 20, 2016, 5:49 PM Bar Harel <bzvi7919(a)gmail.com> wrote: >> >>> At last! Haven't used single dispatch exactly because of that. Thank you >>> savior! >>> +1 >>> >>> On Tue, Sep 20, 2016, 6:03 AM Tim Mitchell <tim.mitchell(a)leapfrog3d.com> >>> wrote: >>> >>>> Hi All, >>>> >>>> We have a modified version of singledispatch at work which works for >>>> methods as well as functions. We have open-sourced it as methoddispatch >>>> (pypi: https://pypi.python.org/pypi/methoddispatch). >>>> >>>> IMHO I thought it would make a nice addition to python stdlib. >>>> >>>> What does everyone else think? >>>> >>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas(a)python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > >

4 9