Re: [Python-ideas] typing.modifiers

[אלעזר]

Thank you all!

אלעזר
(AKA Elazar)

On Sat, Sep 17, 2016 at 4:53 AM Steven D'Aprano  wrote:

> On Sat, Sep 17, 2016 at 03:39:08AM +1000, Chris Angelico wrote:
> > On Fri, Sep 16, 2016 at 11:22 PM, אלעזר  wrote:
> > > P.S. how do I change the name in my quotes? I believe אלעזר is not
> very easy
> > > to address...
> > >
> >
> > TBH I wouldn't worry about it. If people can't cite names using Hebrew
> > script, that's their problem, not yours. :)
>
> [in-joke, that Chris will get]
> But how do we know that אלעזר is his real name? It looks made up to me.
> [/in-joke]
>
> Still, thank you Elazar for also providing a Latin-1 compatible name
> which is readable and pronounceable by English speakers.
>
>
> --
> Steve
> ___
> 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/

Re: [Python-ideas] typing.modifiers

[אלעזר]

On Fri, Sep 16, 2016 at 1:16 PM Steven D'Aprano  wrote:

> On Fri, Sep 16, 2016 at 12:10:22AM +, אלעזר wrote:
>
> [...]
> > Benefits of putting such a collection in stdlib (instead of as an
> external
> > package) include:
>
> Slow down! Before getting all excited about adding these typing hints(?)
> into typing.modifiers, you first have to convince people that they are
> useful and deserve a place in the std library.
>
> What problem are these hints/classes supposed to solve? What
> solutions already exist? Why aren't those solutions good enough?
>


> It is partially described below: mainly, reasoning and readability. I will
try to elaborate, and please forgive me if what I'm writing is obvious to
everyone here. Note that by "readability" I mean "conventional,
non-repetitive syntax, the allow human reasoning", not the subjective issue
(which is also important).

Q. Why standard?

A. Python is not very good at allowing strict reasoning. The confidence in
Python programs, insofar it exists, comes from its reliance on very strong
conventions ("One Way To Do It") and mostly-explicit control flow and name
binding. Data flow, however, is very much implicit since the language
encourages mutation.

Tools that employ conventions are generally linters; these are very
useful in finding trivial bugs, but have zero guarantees about their
absence - unless the inference is trivial. linters and IDEs can also use
basic form of type information, but will not analyze it deeply; hence the
need for convention for modifiers that themselves constrain mutability,
subclassing, etc.As a gradually-typed language, constraints are opt-in at
best, but there should be a way to opt-them-in in a conventional way. Type
hints are very good, and the suggested modifiers complement them.

---
Q. What solutions already exist? Why aren't those solutions good enough?

A:
* Named: There are no conventions and no standard way to prohibit
monkey-patching, since this flexibility is often useful. That's fine. But
what if I want to tell the other programmer that this class should not be
monkey patched, but its fields are mutable? Currently the general solution
is something like

class Person:
name = None
id = None
def __init__(self, name, id):
self.name = name
self.od = id

Say we ignore the repetition. Will tools catch the last typo? Some might
warn, but how should a tool know that it is not intentional? There's no
standard way to express this intent. mypy will say that's an error (if
there are type annotations), but we get the other problem of *allowing*
monkey patching.
StackOverflow suggests
 either
NamedTuple (which is not what I want in this case, since it is immutable
and indexable), another answer without __init__ (which requires useful
default values, and no sign of the "non-mankey-patch" intention). another
answer with arbitrary **kwargs assignment (very flexible, but zero
reasoning). Yet another suggests `dict` which is useful but has nothing to
do with reasoning.
There are many solutions in pypi, most only address the boilerplate issue;
but the "attrs" package seems nice; it might fit in the alternative
decorator-oriented framework I mentioned.
There isn't even a standard name for that feature. "Struct" means something
else.

* Immutable: The importance to reasoning is obvious. There are many
alternative suggestions; again, most upvoted is NamedTuple, which is great
but also indexable. This means one kind of type error that will not be
caught. (actually two, since the __init__ method takes positional arguments
that can be mixed). Additionally, inheriting classes can be monkey-patched,
and there's no standard way to disallow inheritance. The above problems can
be solved in an ad-hoc manner, but it won't give tool support. Other
solutions involve messing up with __setattr__ etc. It Again, "attrs" seems
has a solution in the form of "freeze".

* Sealed: Useful for typechecker (prevent erroneus cast) and optimizers
that need to know the actual implementation of method dispatch (I believe
it can be used in CPython too, but that's a different topic).
The only solution I've found is this answer
http://stackoverflow.com/questions/16564198/pythons-equivalent-of-nets-sealed-class
which gives a hand-crafeted metaclass. But if it's not conventional, it
won't be used by public tools.

* Array: If I want a tuple with mutable cells, I currently simply don't
have any option. There's list, which is extendable. There's array.array and
numpy's matrices, which are intended for numeric processing. There might be
some package for that, but I can't find it - and of course none that allow
type annotations. Besides, there's no reason to assume it will work
together with some other "Named" modifier implementation.

* Namespace (as a shorthand for Final+Abstract): "not instantiable" will
help catch both erroneous 

Re: [Python-ideas] typing.modifiers

[אלעזר]

Thanks for the reply

בתאריך יום ו׳, 16 בספט' 2016, 13:16, מאת Steven D'Aprano ‏<
st...@pearwood.info>:

> On Fri, Sep 16, 2016 at 12:10:22AM +, אלעזר wrote:
>
> [...]
> > Benefits of putting such a collection in stdlib (instead of as an
> external
> > package) include:
>
> Slow down! Before getting all excited about adding these typing hints(?)
> into typing.modifiers, you first have to convince people that they are
> useful and deserve a place in the std library.
>
I was thinking this is the place to do this?

What problem are these hints/classes supposed to solve? What solutions
> already exist? Why aren't those solutions good enough?
>
I have addressed that only very briefly; I will try to elaborate later (I'm
writing from the phone. Sorry)

>
> > 1. This information can be used by typecheckers, and also by users, to
> > reason about programs. If isinstance(x, ImmutableArray), then x is an
> > instantiation of ImmutableArray.
>
> That's how type-checkers work. The class doesn't need to be in the std
> lib for a type-checker to reason about it.
>
No, it's not how they work, since it's not true. I meant the actual type,
not a subtype.

>
>
> > 2. A conventional syntax and a single answer for "How do I make my class
> > immutable", "How do I make my class unsubclassable"
>
> Do we need syntax for those?
>
>
> > 3. The syntax, especially for Struct as above, is pretty and clean. The
> > Array syntax is less so.
>
> I don't even understand what the Array syntax is supposed to mean.
>
That's already a bad sign... Each underscore gives type to its index. The
last index is the maximal.

>
> > 4. I think that the array implementation can use internal CPython details
> > to be implemented efficiently.
>
> What happens to Jython, PyPy, IronPython etc?
>
Similarly or even more so.


> > I am not sure that typing.modifiers is the right place, since these are
> not
> > exactly type hints; they generate methods, and are intended to be
> enforced
> > at runtime.
>
> Then I think your answer is: no, typing.modifiers is NOT the right
> place.
>
Speculating it will make its way, where should it land then?

>
> > I think that even if this idea is not accepted, the general theme is
> > something that might be useful to keep in mind, stdlib might accumulate
> > such modifiers, and it will be nice to keep things uniform.
>
> The stdlib might accumulate many things. Why should it accumulate these?
>
In this part I wasn't talking about what should happen, but rather what
might happen gradually, in which case it'll be nice to fit in a uniform
structure.

>
>
> --
> Steve
> ___
> 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/

Re: [Python-ideas] typing.modifiers

[Steven D'Aprano]

On Fri, Sep 16, 2016 at 12:10:22AM +, אלעזר wrote:

[...]
> Benefits of putting such a collection in stdlib (instead of as an external
> package) include:

Slow down! Before getting all excited about adding these typing hints(?) 
into typing.modifiers, you first have to convince people that they are 
useful and deserve a place in the std library.

What problem are these hints/classes supposed to solve? What solutions 
already exist? Why aren't those solutions good enough?


> 1. This information can be used by typecheckers, and also by users, to
> reason about programs. If isinstance(x, ImmutableArray), then x is an
> instantiation of ImmutableArray.

That's how type-checkers work. The class doesn't need to be in the std 
lib for a type-checker to reason about it.


> 2. A conventional syntax and a single answer for "How do I make my class
> immutable", "How do I make my class unsubclassable"

Do we need syntax for those?


> 3. The syntax, especially for Struct as above, is pretty and clean. The
> Array syntax is less so.

I don't even understand what the Array syntax is supposed to mean.


> 4. I think that the array implementation can use internal CPython details
> to be implemented efficiently.

What happens to Jython, PyPy, IronPython etc?


> I am not sure that typing.modifiers is the right place, since these are not
> exactly type hints; they generate methods, and are intended to be enforced
> at runtime.

Then I think your answer is: no, typing.modifiers is NOT the right 
place.


> I think that even if this idea is not accepted, the general theme is
> something that might be useful to keep in mind, stdlib might accumulate
> such modifiers, and it will be nice to keep things uniform.

The stdlib might accumulate many things. Why should it accumulate these?


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