Re: [Python-ideas] Decorator to avoid a mistake

[Nick Coghlan]

On 26 November 2016 at 13:26, Guido van Rossum  wrote:
> I think one reason why such proposals are unwelcome to experienced users may
> be that when done right this is totally legitimate, and the requirement to
> use an @override decorator is just making code more verbose with very little
> benefit.

It's also the case that if we're going to provide decorators to help
with class definitions, there are more valuable things that we can do
beyond merely warning about accidental method and attribute overrides.

For example, I've recently started using Hynek Schlawack's attrs
project, which pairs up an "attr.attributes" class decorator with an
"attr.attrib()" descriptor to make the following a class definition
with totally ordered instances and a nice repr() implementation:

@attributes
class MyClass:
attr1 = attrib()
attr2 = attrib()
...

It's *really* nice to use, and means I'm more inclined to define
explicit helper classes for interim results rather than passing
convenient-but-hard-to-debug raw tuples, lists and dicts around.

The docs summarise the special method implementations that the
decorator will inject for you in
https://attrs.readthedocs.io/en/stable/why.html#hand-written-classes
and go into more details on how it works at
https://attrs.readthedocs.io/en/stable/how-does-it-work.html

While the focus of attrs itself is very much on defining data
structures where composition is the main form of re-use rather than
inheritance, subclassing *is* supported, and such a system could also
be used to complain about accidental attribute and method name
collisions.

Integrating a check for accidental overrides with a method-boilerplate
reduction class decorator like the one in attrs would help address a
few potential objections:

- undecorated class definitions would be unaffected, so there'd be no
start-up performance hit for existing code
- leaving out the decorator when you intended to use it would also
mean you wouldn't have an __init__ method defined, so you'd notice
pretty fast if you forgot to use it
- for the cost of some explicit decorators on the class definition and
any method overrides, you get to skip writing a whole set of special
methods (__new__/__init__, __repr__/etc, __eq__/__ne__, __lt__/etc)

The specific names from the attrs project wouldn't be suitable for the
standard library, but something like the following might work:

@autoinit
class MyClass:
attr1 = instanceattr()
attr2 = instanceattr()

Where "instanceattr" is inspired by "classmethod" and "staticmethod",
while "autoinit" refers directly to the main benefit of the class
decorator (i.e. it writes your __init__ method for you based on the
"instanceattr" definitions).

The standardised variant of that could be kept very simple, while more
advanced features like data validation and conversion were left to
third party libraries like attrs.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Documentation

[Wes Turner]

- I can't open this .odt OpenOffice Document on my phone; or with GitHub.

The CPython docs are here:

- Src: https://hg.python.org/cpython
- Src: https://hg.python.org/cpython/file/tip/Doc
- Src: https://github.com/python/cpython
- Src: https://github.com/python/cpython/tree/master/Doc

The Python Devguide docs are here:

- https://docs.python.org/devguide/#full-table-of-contents
- https://docs.python.org/devguide/docquality.html
- https://docs.python.org/devguide/documenting.html

ODT -> RST

- https://pypi.python.org/pypi/odt2sphinx/
- http://pandoc.org translates between formats like ODT and ReStructuredText



On Friday, November 25, 2016, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> I've redirected to core-mentorship where we'll clarify the proposed
> contribution and explain requirements for contribution to Python.
>
> Steve
>
>
> adil gourinda writes:
>  > This is a small example of my idea,
> ___
> Python-ideas mailing list
> Python-ideas@python.org 
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Python Documentation

[Stephen J. Turnbull]

I've redirected to core-mentorship where we'll clarify the proposed
contribution and explain requirements for contribution to Python.

Steve


adil gourinda writes:
 > This is a small example of my idea,
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Decorator to avoid a mistake

[Guido van Rossum]

This idea is being kicked around from forum to forum and nobody wants to
have it.

Here it's brought up from time to time and the response is usually "let a
linter do it".

In mypy (which is essentially a powerful linter) it was proposed (
https://github.com/python/mypy/issues/1888) and the response was
essentially "better go to python-ideas or bugs.python.org".

It's also been proposed as a PEP 484 feature:
https://github.com/python/typing/issues/269#issuecomment-243765549 .

I think one reason why such proposals are unwelcome to experienced users
may be that when done right this is totally legitimate, and the requirement
to use an @override decorator is just making code more verbose with very
little benefit. (I could see a benefit -- if this is used consistently it
could make spelunking a large codebase easier, because you would know which
methods are overrides. Something like mypy could then enforce its use. But
an IDE could also just highlight method overrides differently, maybe
PyCharm or PyDev already do that?)

-- 
--Guido van Rossum (python.org/~guido )
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Distribution agnostic Python project packaging

[James Pic]

PS: FTR, pyinstaller seems widely use by a part of our community, but
wasn't represented in this thread, perhaps this can give some good thinking
to our devops community too :)

http://www.pyinstaller.org/​
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Distribution agnostic Python project packaging

[James Pic]

Hi all,

Please let me thank you for sharing some of your insight and passion, and
for your tolerance, I'm sorry I thought it would be the best mailing list
to go ahead and bluntly propose to have something like jars in python core.

It's really great to see such a variety of solutions, and I've been trying
to study some of them. The container image based solutions using LXD is
definitely somewhere we're going on the long term, and conda seems like a
good replacement for virtualenv in production.

Best regards,

James, from Angoulême B)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Decorator to avoid a mistake

[Nick Timkovich]

You can do it at run-time, if you so desire, without a measurable
performance hit with a metaclass. Here's a hacky demo:
https://gist.github.com/nicktimko/5f08d6adfa1dbe1319c3bfc715ec0aa4#file-override_guard-ipynb

(Pedants: Any performance hit will be constant-time and probably less than
a stray import that you don't need. If you're worried about optimizing
constant-time things, I think you have larger problems.)

On Thu, Nov 24, 2016 at 5:48 PM, Victor Stinner 
wrote:

> Similar or related issue recently open and quickly closed:
> http://bugs.python.org/issue28776
> "Duplicate method names should be an error"
>
> In short, such job should be done by linters. I'm quite sure that many
> of them already implement such check.
>
> Victor
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Python Documentation

[adil gourinda]

This is a small example of my idea, If you appreciate my little work I will

continue working on it. If no, thank you for your attention and your

comprehension :-)




Python Library Reference's Notes (v0.0).odt
Description: Python Library Reference's Notes (v0.0).odt
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/