Re: [Python-Dev] Is there a reference manual for Python bytecode?
Hi Nick, On 29/12/15 02:46, Nick Coghlan wrote: 1. The interpreter's bytecode generation is inconsistent with the implementation of the eval loop Essentially, this was my problem. I'd neglected to add the reference to TARGET_NEW_OP2 to Python/opcode_targets.h (so staring hard at the op generation and ceval implementation did not help me: they were both fine). I'd forgotten adding the first op to that array, and section 24.8 of https://docs.python.org/devguide/compiler.html doesn't mention that file either. I will look at raising a docs bug on that. It's also the case that to rule out the bootstrapping cycle as a potential source of problems, you can try the following manual dance: 1. Revert to a clean checkout and rebuild 2. Apply the eval loop changes, and rebuild 3. Apply the code generation changes, and rebuild Thanks - this is useful to know. It's a bit chicken-and-egg if one has introduced a bug which stops the build-time execution of the python auto-generation scripts from executing correctly :) E. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is there a reference manual for Python bytecode?
numba * http://numba.pydata.org/numba-doc/0.16.0/modules/numba.html#module-numba.bytecode * https://github.com/numba/numba/blob/master/numba/bytecode.py pypy * http://doc.pypy.org/en/latest/interpreter.html * http://aosabook.org/en/pypy.html ... http://compilers.pydata.org/ #Bytecode Utilities On Dec 28, 2015 1:33 PM, "Sturla Molden" wrote: Brett Cannon wrote: > Ned also neglected to mention his byterun project which is a pure Python > implementation of the CPython eval loop: href="https://github.com/nedbat/byterun";>https://github.com/nedbat/byterun I would also encourage you to take a look at Numba. It is an LLVM based JIT compiler for Python bytecode, written for hardcore numerical algorithms in Python. It can often achieve the same performance as -O2 in C after a short burn-in while inferring the types of the arguments and variables. Using it is mostly as easy as adding an @numba.jit decorator to the function we want to accelerate. Numba is rapidly becoming what Google's long dead swallow should have been. :-) Sturla ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 257 and __init__
Hola! (I was doubting in sending this mail to this list or to the normal one, but as it affects a "style recommendation" we propose for the whole community, I finally sent it here) I was reading PEP 257 and it says that all public methods from a class (including __init__) should have a docstring. Why __init__? It's behaviour is well defined (inits the instance), and the initialization parameters should be described in the class' docstring itself, right? Or I am missing something? Should we remove "__init__" (the class method, *not* the package file) as to require docstrings in the PEP? Thanks! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 257 and __init__
On Dec 29, 2015, at 10:27, Facundo Batista wrote: > I was reading PEP 257 and it says that all public methods from a class > (including __init__) should have a docstring. > > Why __init__? > > It's behaviour is well defined (inits the instance), and the > initialization parameters should be described in the class' docstring > itself, right? Isn't the same thing true for every special method? There are lots of classes where __add___ just says "a.__add__(b) = a + b" or (better following the PEP) "Return self + value." But, in the rare case where the semantics of "a + b" are a little tricky (think of "a / b" for pathlib.Path), where else could you put it but __add__? Similarly, for most classes, there's only one of __init__ or __new__, and the construction/initialization semantics are simple enough to describe in one line of the class docstring--but when things are more complicated and need to be documented, where else would you put it? Meanwhile, the useless one-liner docstrings for these methods aren't usually a problem except in trivial classes--and in trivial classes, I usually just don't bother. You can violate PEP 257 when it makes sense, just like PEP 8. They're just guidelines, not iron-clad rules. Unless you're working on a project that insists that we must follow those guidelines, usually for some good reason like having lots of devs who are more experienced in other languages and whose instinctive "taste" isn't sufficiently Pythonic. And for that use case, keeping the rules as simple as possible is probably helpful. Better to have one wasted line in every file than to have an extra rule that all those JS developers have to remember when they're working in Python. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 257 and __init__
On Tue, Dec 29, 2015 at 1:27 PM, Facundo Batista wrote: > I was reading PEP 257 and it says that all public methods from a class > (including __init__) should have a docstring. > > Why __init__? > > It's behaviour is well defined (inits the instance), and the > initialization parameters should be described in the class' docstring > itself, right? __init__ is not always the only constructor for a class; each constructor's arguments should be documented as part of the constructor. The class docstring should provide summary information for the class as a whole. I can also imagine cases where the __init__ isn't considered public, though I suspect that's exceedingly rare in practice. (Can't think of a case I've actually run across like that.) > Should we remove "__init__" (the class method, *not* the package file) > as to require docstrings in the PEP? I don't think so. The advice seems sound to me. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 257 and __init__
On Tue, Dec 29, 2015 at 4:38 PM, Andrew Barnert wrote: > Isn't the same thing true for every special method? There are lots of classes > where __add___ just says "a.__add__(b) = a + b" or (better following the PEP) > "Return self + value." But, in the rare case where the semantics of "a + b" > are a little tricky (think of "a / b" for pathlib.Path), where else could you > put it but __add__? > > Similarly, for most classes, there's only one of __init__ or __new__, and the > construction/initialization semantics are simple enough to describe in one > line of the class docstring--but when things are more complicated and need to > be documented, where else would you put it? Yeap. Note that I'm ok to include a docstring when the actual behaviour would deviate from the expected one as per Reference Docs. My point is to not make it mandatory. > I usually just don't bother. You can violate PEP 257 when it makes sense, > just like PEP 8. They're just guidelines, not iron-clad rules. Yeap, but pep257 (the tool [0]) complains for __init__, and wanted to know how serious was it. [0] https://pypi.python.org/pypi/pep257 -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 257 and __init__
On 12/29/2015 2:40 PM, Fred Drake wrote: On Tue, Dec 29, 2015 at 1:27 PM, Facundo Batista wrote: I was reading PEP 257 and it says that all public methods from a class (including __init__) should have a docstring. Why __init__? It's behaviour is well defined (inits the instance), and the initialization parameters should be described in the class' docstring itself, right? __init__ is not always the only constructor for a class; each constructor's arguments should be documented as part of the constructor. I agree. >>> help(Someclass) first gives the class docstring, which should explain what the class is about, and then each method, with signature and docstring. The explanation of signatures for __new__, __init__, and any other constructor methods should follow the name and signature of the method. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 257 and __init__
Facundo Batista writes: > Note that I'm ok to include a docstring when the actual behaviour > would deviate from the expected one as per Reference Docs. My point is > to not make it mandatory. I disagree with the exception you're making for ‘__init__’. The parameters to that function (and how the function behaves in response) should be documented in the docstring, just as for any other function. > Yeap, but pep257 (the tool [0]) complains for __init__, and wanted to > know how serious was it. Omitting a docstring violates PEP 257, regardless which function we're talking about. So the tool is correct to complain. -- \ “If we don't believe in freedom of expression for people we | `\ despise, we don't believe in it at all.” —Noam Chomsky, | _o__) 1992-11-25 | Ben Finney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 257 and __init__
On Dec 29, 2015, at 13:03, Facundo Batista wrote: > >> On Tue, Dec 29, 2015 at 4:38 PM, Andrew Barnert wrote: >> I usually just don't bother. You can violate PEP 257 when it makes sense, >> just like PEP 8. They're just guidelines, not iron-clad rules. > > Yeap, but pep257 (the tool [0]) complains for __init__, and wanted to > know how serious was it. Of course. It's telling you that you're not following the standard, which is correct. It's also expected in this case, and if you think you have a good reason for breaking from the standard, that's perfectly fine. You probably want to configure the tool to meet your own standards. (I've worked on multiple projects that used custom pep8 configurations. I haven't used pep257 as much, but I believe I've seen configurations for the slightly different conventions of scientific/numerical programming and Django programming, so presumably coming up with your own configuration shouldn't be too hard--don't require docstrings on __init__, or on all special methods, or only when there no __new__, or whatever.) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
