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:
And the current implement is at:
How do you think about this ability to put in pdb/bdb?
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.
- 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.
- 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.
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.
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
> (using a constructor function instead of a class to create objects)
> Content-Type: text/plain; charset="utf-8"
> Hi Guido,
> Yes indeed, *only* invoked by __init__ .
> See my test below.
> import attr
> class Foo:
> x = attr.ib(convert=str)
> foo = Foo(42)
> # prints '42'
> foo.x = 42
> # prints 42
> Not sure if this is a good design but it matches the docs.
> 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>
> > Let me quote the attrs docs:
> > ""
> > convert (callable) ? callable() that is called by attrs-generated
> > methods to convert attribute?s value to the desired format. It is given
> > 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
> > 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/
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
Why choose ClassVar over ClassAttr when the usual terminology used in
the Python community is class and instance *attributes* rather than
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,
- 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
(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?
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?
"""Don't do anything"""
x = 0
if x > 0:
x += 1
"""Comment that is a string or vice versa"""
x = 2
if x == 2:
x += 1 ;"Add 1 to x"
if x == 3:
if __name__ == "__main__":
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
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
Link to the implementation: https://github.com/Traceur759/cpython/tree/
Diff from master: https://github.com/python/cpython/compare/master...Tr
You can quickly test it with:
$ ./python -m _testmultiphase
This is an extension module named __main__
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"
> (using a constructor function instead of a class to create objects)
> 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>
> > 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)
I think it would be nice to have a generic NamedTuple interface in python:
from typing import NamedTupleType
) -> NamedTupleType:
The rationale is that named tuple exposes a common API, and it would be
nice to have it readily available.
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
>>> On Tue, Sep 20, 2016, 6:03 AM Tim Mitchell <tim.mitchell(a)leapfrog3d.com>
>>>> 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
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>> Python-ideas mailing list
>> Code of Conduct: http://python.org/psf/codeofconduct/