[Python-ideas] Re: Keyword arguments self-assignment

[Ivan Levkivskyi]

On Mon, 20 Apr 2020 at 12:19, Eric V. Smith  wrote:

> On 4/20/2020 7:00 AM, Steven D'Aprano wrote:
> > On Mon, Apr 20, 2020 at 10:03:50AM +0200, M.-A. Lemburg wrote:
> >> Guys, is it really worth saving a few hits on the auto-complete key
> >> by adding even more mysterious twists to the existing Python function
> >> call syntax ?
> >>
> >> The current version already strikes me as way too complex.
> >> It's by far the most complex piece of grammar we have in Python:
> > (I think you pasted the typedarglist rules twice.)
> >
> > Now that Python is moving to a PEG parser, could it be simplified?
> >
> > Might we get sequence-unpacking parameters back again?
> >
> >
> >  # Legal in Python 2, illegal in Python 3.
> >  py> def func(a, (b, c), d):
> >  ... print a, b, c, d
> >  ...
> >  py> func(1, "ab", 3)
> >  1 a b 3
> >
> >
> > I know that was a feature that got removed only because it was hard to
> > specify in the grammer, even though it was used by lots of people.
>
> See PEP 3113, which doesn't mention parsing. My understanding is that it
> was the introspection problem that drove this.
>
> And on very rare occasions, I really miss this feature.
>

I migrated a lot of code to Python 3 recently and I really miss this
feature in lambdas:

sorted(users, key=lambda u: (u[1].lower(), u[0]))

is IMO much uglier than

sorted(users, key=lambda (id, name): (name.lower(), id))

--
Ivan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2L4QRUUESBPKYEJF4J4VN7TV3IVBDBER/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions

[Ivan Levkivskyi]

IIRC, black actually uses the first style you mention, so maybe you should
rather discuss it there first. Otherwise this will create a weird situation
where one of the most popular auto-formatter formats code in violation of
PEP 8.

--
Ivan



On Wed, 27 Nov 2019 at 11:42, Stefano Borini 
wrote:

> This may be a pet peeve of mine, but with the introduction of type
> hints, more and more function definitions have become longer than 80
> characters. This used to seldom happen in the past.
> The problem, as I see it, is that there seem to be a general tendency
> to use this way of indenting, e.g. see (among many):
>
>
> https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256f168818e30/pydantic/parse.py#L47
>
> def load_file(
> path: Union[str, Path],
> *,
> content_type: str = None,
> encoding: str = 'utf8',
> proto: Protocol = None,
> allow_pickle: bool = False,
> ) -> Any:
> path = Path(path)
> b = path.read_bytes()
> if content_type is None:
> if path.suffix in ('.js', '.json'):
> proto = Protocol.json
> elif path.suffix == '.pkl':
> proto = Protocol.pickle
>
> This violates pep8
>
> # Add 4 spaces (an extra level of indentation) to distinguish
> arguments from the rest.
> def long_function_name(
> var_one, var_two, var_three,
> var_four):
> print(var_one)
>
> However, no coding styles tools report that. Flake8 does however
> report a similar error for if conditions
>
> if path.suffix in (
> '.js', '.json'
> ):
> proto = Protocol.json
>
> x.py:20:5: E125 continuation line with same indent as next logical line
>
> But says nothing for this monstrosity, which is the equivalent of the
> opening case
>
> if path.suffix in (
> '.js', '.json'
> ):
> proto = Protocol.json
>
> It is not my intention to trigger a massive discussion. My stance is
> that the appropriate visual aspect of the above code should be
>
> def load_file(
> path: Union[str, Path],
> *,
> content_type: str = None,
> encoding: str = 'utf8',
> proto: Protocol = None,
> allow_pickle: bool = False) -> Any:
> path = Path(path)
> b = path.read_bytes()
>
> to keep a visual distinction in indentation between the argument list
> and the function body, as in the spirit of pep8.
> Regardless of the choice, I think that pep8 should be updated with the
> appropriate style for this specific case, and style tools should
> enforce this choice.
>
>
> --
> Kind regards,
>
> Stefano Borini
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/XKEWGJGXMANMYK37FRSJJ7IU67YUNFHC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TPZT2URLT47OL2PO746AXODLBIYTQB6K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add Subscriptable ABC

[Ivan Levkivskyi]

Just FYI there is a closely related issue on b.p.o.
https://bugs.python.org/issue25988. FWIW I am in favor of the idea, but
some people are against it (see e.g. the issue).

--
Ivan



On Fri, 27 Sep 2019 at 17:12, Steven D'Aprano  wrote:

> I keep finding myself needing to test for objects that support
> subscripting. This is one case where EAFP is *not* actually easier:
>
> try:
> obj[0]
> except TypeError:
> subscriptable = False
> except (IndexError, KeyError):
> subscriptable = True
> else:
> subscriptable = True
> if subscriptable:
> ...
>
>
> But I don't like manually testing for it like this:
>
> if getattr(obj, '__getitem__', None) is not None: ...
>
> because it is wrong. (Its wrong because an object with __getitem__
> defined as an instance attribute isn't subscriptable; it has to be in
> the class, or a superclass.)
>
> But doing it correctly is too painful:
>
> if any(getattr(T, '__getitem__', None) is not None for T in
> type(obj).mro())
>
> and besides I've probably still got it wrong in some subtle way. What
> I'd really like to do is use the collections.abc module to do the check:
>
> if isinstance(obj, collections.abc.Subscriptable): ...
>
> in the same way we can check for Sized, Hashable etc.
>
> Alternatively, if we had a getclassattr that skipped the instance
> attributes, I could say:
>
> if getclassattr(obj, '__getitem__', None) is not None: ...
>
>
> (1) Am I doing it wrong? Perhaps I've missed some already existing
> solution to this.
>
> (2) If not, is there any reason why we shouldn't add Subscriptable to
> the collection.abc module? I think I have the implementation:
>
> class Subscriptable(metaclass=ABCMeta):
> __slots__ = ()
> @abstractmethod
> def __getitem__(self, idx):
> return None
> @classmethod
> def __subclasshook__(cls, C):
> if cls is Subscriptable:
> return _check_methods(C, "__getitem__")
> return NotImplemented
>
> Comments, questions, flames?
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/JCQJP5K32SELHRZFQB75CNLTECT3YD3K/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BJ7QNL3OWOBVXLRGHCS25W2Y4IXANWWV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Need a core developer sponsor for a PEP

[Ivan Levkivskyi]

Note that there is a related PEP 585, and the outcome for this one may
depend on that PEP. Anyway,
I agree this should go to typing-sig list.

--
Ivan



On Tue, 17 Sep 2019 at 07:58, Philippe Prados 
wrote:

> Hello,
>
> I would like to publish a new PEP (see here
> ).
> I discussed this idea here
> 
> .
> The PEP1  explains that I must
> have a sponsor.
>
> Who can help me ?
>
> Thanks
>
> Philippe Prados
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WWSOVKGMBCDQBUNJDJYKYKE7FVWHSDU5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5TBFVZWVPR7XIMEQRBZYSSPVME7YWHYJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

[Ivan Levkivskyi]

On Thu, 29 Aug 2019 at 23:48, Guido van Rossum  wrote:

> On Thu, Aug 29, 2019 at 3:33 PM Chris Angelico  wrote:
>
>> On Fri, Aug 30, 2019 at 8:28 AM Guido van Rossum 
>> wrote:
>
> [...]
>
>
> I do tink we should probably review PEP 585 before doing anything about
> unions specifically -- likely there are bigger fish to fry. (And PEP 585
> has not received much discussion.)
>

I also agree with this. Generally I am fine with Union[int, str] and
Optional[int], but I also see how some people might want a shorter
notation. Many things around typing have been previously
rejected because we didn't want to introduce any (or at least minimal)
changes to the syntax and runtime, but now that typing is much more widely
used we can reconsider some of these.
Importantly, I think this should be done in a systematic way (potentially
using PEP 585 draft as a starting point).

--
Ivan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YZHAERD5T4TZL62A6EI4BCKKAQYNJGSU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom string prefixes

[Ivan Levkivskyi]

On Mon, 2 Sep 2019 at 07:04, Pasha Stetsenko  wrote:

> > Don't say that this proposal won't be abused. Every one of the OP's
> > motivating examples is an abuse of the syntax, returning non-strings
> > from something that looks like a string.
>
> If you strongly believe that if something looks like a string it ought to
> quack like a string too, then we can consider 2 potential remedies:
>
> 1. Change the delimiter, for example use curly braces: `re{abc}`. This
> would still be parseable, since currently an id cannot be followed by a set
> or a dict. (The forward-slash, on the other hand, will be ambiguous).
>
> 2. We can also leave the quotation marks as delimiters. Once this feature
> is implemented, the IDEs will update their parsers, and will be emitting a
> token of "user-defined literal" type. Simply setting the color for this
> token to something different than your preferred color for strings will
> make it visually clear that those tokens aren't strings. Hence, no
> possibility for confusion.
>

Just to add my 2 cents: there are always two sides in each language
proposal: more flexibility/usability, and more language complexity.
These need to be compared and the comparison is hard because it is often
subjective. FWIW, I think in this case the added complexity outweighs
the benefits. I think only the very widely used literals (like numbers)
deserve their own syntax. For everything else it is fine to have few extra
keystrokes.

--
Ivan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GD2AAFCB262JSSFZVOMUM6EXPTFJHZ4F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extend ast with types for * instead of using raw lists

[Ivan Levkivskyi]

On one hand I can see how this may cause little inconvenience, but on other
hand this would be a breaking change, so I don't think it is realistic.
Also I think this is often alleviated by using super().

Maybe it is possible to preserve backwards compatibility by making ast_list
a subclass of list? Or is it not possible for some reason?

--
Ivan



On Thu, 15 Aug 2019 at 22:32, Caleb Donovick 
wrote:

> When walking an ast it impossible to know the type of an empty list
> without writing down some giant lookup from node types and field names to
> field types.
>
> More concretely it would nice be to able to programatically visit all
> blocks (stmt*)  without having to something like:
>
> ```
> class BlockVisitor(NodeVisitor):
> def visit_If(self, node: If):
> self.visit(node.test)
> self.visit_block(node.body)
> self.visit_block(node.orelse)
>
> def visit_FunctionDef(self, node: FunctionDef):
> for field, value in iter_fields(node):
> if field == 'body':
> self.visit_block(value)
> else:
> # the implementation of generic_visit
> ```
> Now it turns out that all fields that are lists and are named "body",
> "orelse", or "finalbody" are stmt* and only such fields are stmt*.  A rule
> could also be synthesized to identify expr* and so forth but this seems
> incredibly hacky to me.
>
> It would be much cleaner if * were actual nodes in the ast. E.g.
> something like:
> ```
> class ast_list(AST, MutableSequence[T_co]): ...
> class StmtList(ast_list[stmt]): ...
> class ExprList(ast_list[expr]): ...
> ...
> class FunctionDef(stmt):
> name: identifier
> args: arguments
> body: StmtList
> decorator_list: ExprList
> returns: Optional[expr]
> ```
> This would not change the behavior or structure in any way other than
> tagging * and allowing * to be visited.
>
> It would potentially break old code which relies on stuff like `if
> isinstance(node.field, list)` e.g. the implementation of generic_visit.
>
>
> Caleb Donovick
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZHOXQTDSHOERZSGUJXLNJCYLKKQJOYTA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UXZN3L6YSSUK7YKIZOBSDKKWG4F3YYUM/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A proper way to bring real interfaces to Python

[Ivan Levkivskyi]

On Mon, 6 May 2019 at 03:23, Serge Matveenko  wrote:

> On Sun, May 5, 2019 at 8:23 PM Stephen J. Turnbull
>  wrote:
> >
> > Serge Matveenko writes:
> >
> >  > So, I would like to propose adding a third main object called
> >  > `interface` in addition to `object` and `type` and to use it to define
> >  > interface objects. Such interfaces could then be used in the class
> >  > definition in the following way.
> >
> > How does this compare to existing technology such as zope.interface?
> > Why do you want it to behave differently where it does?
>
> Also, `strict-interfaces` provides typing annotations support and
> could be easily be adopted in conjunction with PEP 544.
>

I am not sure why one would need another special base class to enforce
checking implementations statically.
Currently mypy can already enforce implementations of Protocols/ABCs at
instantiation time. I can imagine one can just add a flag
(like --early-implementations) without other changes.

--
Ivan
___
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] Using rightarrow "->" for typing annotation of functions

[Ivan Levkivskyi]

TBH, I don't think it is so bad that it requires a new syntax. But I am not
strongly against it either. What I would like to add here is that if we
will go with the replacement:

Callable[[X, Y], Z] becomes (X, Y) -> Z

then we should also go with

Union[X, Y] becomes X | Y
Tuple[X, Y] becomes (X, Y)
Optional[X] becomes X?
(Intersection[X, Y] when added becomes X & Y)

The current syntax (although really verbose) is consistent, so if we want
to improve it I would like to keep consistency.
Also if we are going forward with this, should we allow mixing old and new
syntax? Will the old syntax be deprecated after we introduce the new one?

--
Ivan



On Wed, 24 Apr 2019 at 14:43, Guido van Rossum  wrote:

> Thanks for posting. I agree that Callable is ugly (even hideous :-), but
> when we introduced type annotations in PEP 484, we didn't want to introduce
> new syntax. The existing syntax (using -> in function headings) was
> supported since Python 3.0.
>
> Since then we've introduced other new syntax (in particular PEP 526) so we
> could indeed try adding something better for Callable.
>
> I think we should probably at least have parentheses around the arguments,
> so you'd write
>
> f: (int) -> str
> g: (int, str) -> float
>
> That looks elegant.
>
> But we should also try to support optional arguments and keyword arguments.
>
> Also, some groups of people would like to see a more concise notation for
> lambdas, and maybe they'd want to write
>
> x = (a, b) -> a + b
>
> as sugar for
>
> x = lambda a, b: a + b
>
> We probably can't have both, so we should at least decide which is more
> important.
>
> Too bad we can't use Unicode arrows. :-)
>
> On Wed, Apr 24, 2019 at 2:30 PM Vaibhav Karve 
> wrote:
>
>> (Note: This idea is about a particular static typecheking (typing?)
>> annotation syntax).
>> The idea is that currently the use of the "->" (right arrow) is
>> restricted to only function definition annotation. Can we extent it to
>> declaration of type for functions even outside their definitions?
>> Example:
>>
>> Currently we write:
>> f: Callable[[int, Dict[str, int]], str]  # declaring the type of some
>> fake function
>>
>> This would be much cleaner if we could write:
>> f: int -> Dict[str, int] -> str   # One of the possibilities
>>
>> or even:
>> f: int, Dict[str, int] -> str  # Another possibility
>>
>> I have no idea how this will affect the existing syntax (and if this will
>> have any bad repercussions/notational misuse). I just thought it would be
>> nicer to:
>> a) Not have to spell out Callable
>> b) Not have to use all those square brackets
>> c) Have the same notation work for both the function annotation as well
>> as for declaring the type.
>>
>> This is my first time posting an idea to python-ideas. So apologies if i
>> am not following some conventions that i might not be aware of.
>> Vaibhav Karve
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him/his **(why is my pronoun here?)*
> 
> ___
> 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] Dict joining using + and +=

[Ivan Levkivskyi]

On Sat, 2 Mar 2019 at 19:15, Raymond Hettinger 
wrote:

>
> > On Mar 1, 2019, at 11:31 AM, Guido van Rossum  wrote:
> >
> > There's a compromise solution for this possible. We already do this for
> Sequence and MutableSequence: Sequence does *not* define __add__, but
> MutableSequence *does* define __iadd__, and the default implementation just
> calls self.update(other). I propose the same for Mapping (do nothing) and
> MutableMapping: make the default __iadd__ implementation call
> self.update(other).
>
> Usually, it's easy to add methods to classes without creating disruption,
> but ABCs are more problematic.  If MutableMapping grows an __iadd__()
> method, what would that mean for existing classes that register as
> MutableMapping but don't already implement __iadd__?  When "isinstance(m,
> MutableMapping)" returns True, is it a promise that the API is fully
> implemented? Is this something that mypy could would or should complain
> about?
>

Just to clarify the situation, currently Mapping and MutableMapping are not
protocols from both runtime and mypy points of view. I.e. they don't have
the structural __subclasshook__() (as e.g. Iterable), and are not declared
as Protocol in typeshed. So to implement these (and be considered a subtype
by mypy) one needs to explicitly subclass them (register() isn't supported
by mypy). This means that adding a new method will not cause any problems
here, since the new method will be non-abstract with a default
implementation that calls update() (the same way as for MutableSequence).

The only potential for confusion I see is if there is a class that de-facto
implements current MutableMapping API and made a subclass (at runtime) of
MutableMapping using register(). Then after we add __iadd__, users of that
class might expect that __iadd__ is implemented, while it might be not.
This is however OK I think, since register() is already non type safe. Also
there is a simple way to find if there are any subclassses of
MutableMapping in typeshed that don't have __iadd__: one can *try*
declaring MutableMapping.__iadd__ as abstract, and mypy will error on all
such subclasses.

--
Ivan
___
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] Dict joining using + and +=

[Ivan Levkivskyi]

On Fri, 1 Mar 2019 at 14:50, Eric V. Smith  wrote:

> On 3/1/2019 9:38 AM, INADA Naoki wrote:
> > Sorry, I'm not good at English enough to explain my mental model.
> >
> > I meant no skip, no ignorance, no throw away.
> >
> > In case of 1+2=3, both of 1 and 2 are not skipped, ignored or thrown
> away.
> >
> > On the other hand, in case of {a:1, b:2}+{a:2}={a:2, b:2}, I feel {a:1}
> > is skipped, ignored, or thrown away.  I used "lost" to explain it.
> >
> > And I used "lossless" for "there is no lost".  Not for reversible.
> >
> > If it isn't understandable to you, please ignore me.
> >
> > I think Rémi’s comment is very similar to my thought.  Merging mapping
> > is more complex than concatenate sequence and it seems hard to call it
> > "sum".
>
> I understand Inada to be saying that each value on the LHS (as shown
> above) affects the result on the RHS. That's the case with addition of
> ints and other types, but not so with the proposed dict addition. As he
> says, the {a:1} doesn't affect the result. The result would be the same
> if this key wasn't present in the first dict, or if the key had a
> different value.
>
> This doesn't bother me, personally. I'm just trying to clarify.
>

OK, thanks for explaining! So more formally speaking, you want to say that
for other examples of '+' in Python
x1 + y == x2 + y if and only if x1 == x2, while for the proposed '+' for
dicts there may be many different x_i such that
x_i + y gives the same result.

This doesn't bother me either, since this is not a critical requirement for
addition. I would say this is rather a coincidence
than a conscious decision.

--
Ivan
___
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] Dict joining using + and +=

[Ivan Levkivskyi]

On Fri, 1 Mar 2019 at 13:48, INADA Naoki  wrote:

> >
> >
> > Is that an invariant you expect to apply to other uses of the +
> > operator?
> >
> > py> x = -1
> > py> x <= (x + x)
> > False
> >
> > py> [999] <= ([1, 2, 3] + [999])
> > False
> >
>
> Please calm down.  I meant each type implements "sum"
> in semantics of the type, in lossless way.
> What "lossless" means is changed by the semantics of the type.
>
> -1 + -1 = -2 is sum in numerical semantics.  There are no loss.
>

TBH I don't understand what is lossless about numeric addition. What is the
definition of lossless?
Clearly some information is lost, since you can't uniquely restore two
numbers you add from the result.

Unless you define what lossless means, there will be just more
misunderstandings.

--
Ivan
___
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] Dict joining using + and +=

[Ivan Levkivskyi]

On Thu, 28 Feb 2019 at 07:18, Serhiy Storchaka  wrote:

> [...]
>
> I do not understand why we discuss a new syntax for dict merging if we
> already have a syntax for dict merging: {**d1, **d2} (which works with
> *all* mappings). Is not this contradicts the Zen?
>

FWIW there are already three ways for lists/sequences:

[*x, *y]
x + y
x.extend(y)  # in-place version

We already have first and third for dicts/mappings, I don't see a big
problem in adding a + for dicts,
also this is not really a new syntax, just implementing couple dunders for
a builtin class.

So I actually like this idea.

--
Ivan
___
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] Type hints for functions with side-effects and for functions raising exceptions

[Ivan Levkivskyi]

On Tue, 19 Feb 2019 at 21:07, Miikka Salminen 
wrote:

> Hi!
>
> To help automatic document generators and static type checkers reason more
> about the code, the possible side-effects and raised exceptions could also
> be annotated in a standardized way.
>

The idea about "checked exceptions" appeared several times in various
places. I used to think that this would be hard to support for any
realistic use cases. But now I think there may be a chance
to turn this into a usable feature if one frames it correctly (e.g. the
focus could be on user defined exceptions, rather than on standard ones,
since there is no way we can annotate every function in typeshed).

But this is probably not the best place to the start the discussion (we may
come back here if we will have a proposal). I would recommend to post
either on typing GitHub tracker, or mypy GitHub tracker,
or on typing SIG mailing list.

IMO the part about side effects is a non-starter.

--
Ivan
___
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] Discussion: Duck typing with “concepts”

[Ivan Levkivskyi]

I think you may be a bit late. Have you heard about PEP 544?

--
Ivan



On Tue, 22 Jan 2019 at 11:50, James Lu  wrote:

> So here’s an interesting idea, not a proposal yet.
>
> In C++20, a Concept is a list of Boolean expressions with a name that can
> be used in place of a type in a templated (ie type-generic) function.
>
> from typing import Concept
> Iterator = Concept(lambda o: hasattr(o, "__iter__", lambda o: iter(o) !=
> NotImplemented)
> # Concept inheritance
> Iterable = Concept(lambda o: hasattr(o, "__next__"), Iterator)
>
> You could use concepts to define many practical “real-world” duck types.
>
> A concept is like an opt-in duck typing type assertion. Since it’s a part
> of type annotation syntax, assertions can be generated automatically by
> looking at assertions.
>
> You would use a Concept like any other type in type annotations.
>
> Marko, how do you think Concepts might integrate with icontract? (I’m
> imagining overriding an import hook to automatically add contracts to
> functions with concepts.) How frequently do you use duck typing at
> Parquery? How might Concepts affect how often you used duck typing?
> ___
> 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] AMEND PEP-8 TO DISCOURAGE ALL CAPS

[Ivan Levkivskyi]

On Sat, 5 Jan 2019 at 02:46, David Mertz  wrote:

> Like everyone other than Abe in this thread, I find judicious use of
> CONSTANTS to be highly readable and useful.
>
> Yes, there is a little wiggle room about just how constant a constant has
> to be since Python doesn't have a straightforward way to create real
> constants. Very rarely I might change a value named in all caps. But the
> distinction between a value intended as fixed and one I merely probably
> won't change is worth marking typographically Especially since there's
> no actual Python semantics enforcing it.
>

There is. Mypy supports final names, final methods and whatnot
https://mypy.readthedocs.io/en/latest/final_attrs.html

Anyway I don't see a problem in using CAPS for constants, finally it is
just a style guide, Python will work even with

class sTYLISH_oNE:
...

--
Ivan
___
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] Introduce typing.SupportsFsPath

[Ivan Levkivskyi]

On Tue, 9 Oct 2018 at 15:17, Eric Fahlgren  wrote:

> On Tue, Oct 9, 2018 at 3:16 AM Ivan Levkivskyi 
> wrote:
>
>> class PathLike(Protocol[AnyStr]):
>>
>
> I had been working on this same problem intermittently for several months,
> so thanks, but...
>
> error: Invariant type variable 'AnyStr' used in protocol where
> covariant one is expected
>
> is called out on the class  by mypy 0.630 (Python 3.6.6).  Do I just need
> to wait for 0.640?  Or should I define a new TypeVar for AnyStr_co and use
> that?
>

Hm, it looks like mypy overreacts here. I think it should be safe to use a
constrained type variable if there are no constraints that are subtypes of
other constraints (which is the case for AnyStr on Python 3, where bytes is
not a subtype of str). Could you please open an issue about this on mypy
tracker? In the meantime, you can just silence the error with a `# type:
ignore`.

--
Ivan
___
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] Introduce typing.SupportsFsPath

[Ivan Levkivskyi]

On Tue, 9 Oct 2018 at 03:13, Guido van Rossum  wrote:

> In typeshed there is os.PathLike which is close. You should be able to use
> Union[str, os.PathLike[str]] for what you want (or define an alias).
>
> We generally don't want to add more things to typing that aren't closely
> related to the type system. (Adding the io and re classes was already less
> than ideal, and we don't want to do more of those.)
>

The problem however is that `PathLike` is not a protocol in typeshed. This
should be updated when protocols will be official. Until that, you can just
easily define your own protocol:

from typing import AnyStr
from typing_extensions import Protocol

class PathLike(Protocol[AnyStr]):
def __fspath__(self) -> AnyStr: ...

--
Ivan
___
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] f-string "debug" conversion

[Ivan Levkivskyi]

On Wed, 3 Oct 2018 at 11:45, Eric V. Smith  wrote:

> On 10/3/2018 3:54 AM, Steven D'Aprano wrote:
> > On Tue, Oct 02, 2018 at 08:27:03PM -0400, Eric V. Smith wrote:
> >
> >> Here’s the idea: for f-strings, we add a !d conversion operator, which
> >> is superficially similar to !s, !r, and !a. The meaning of !d is:
> >> produce the text of the expression (not its value!),
> >
> > I SO WANT THIS AS A GENERAL FEATURE, not just for f-strings, it hurts.
> >
> > Actually what I want is an executable object (a function?) which has the
> > AST and text of the expression attached. If putting this into f-strings
> > is a first step towards getting this thunk-like thing, then I don't
> > need to read any further, I'm +1 :-)
>
> I feel your pain, but we're a long way from that.
>

Maybe we are actually not so far? PEP 563 added functionality for
transforming expressions to strings, maybe it can be reused for this
purpose?
I would love to have this since in my experience I mostly print some
(relatively complex) expressions.

--
Ivan
___
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] Pre-conditions and post-conditions

[Ivan Levkivskyi]

On Mon, 3 Sep 2018 at 23:51, Greg Ewing  wrote:

> Jonathan Fine wrote:
> > I've just read and article which makes a good case for providing
> > pre-conditions and post-conditions.
> >
> > http://pgbovine.net/python-unreadable.htm
>
> There's nothing in there that talks about PBC-style executable
> preconditions and postconditions, it's all about documenting
> the large-scale intent and purpose of code. He doesn't put
> forward any argument why executable code should be a better
> way to do that than writing comments.
>

FWIW this article looks more like a typical motivational intro to static
types in Python :-)
(Even his comment about types can be partially answered with e.g.
Protocols.)

--
Ivan
___
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] Pre-conditions and post-conditions

[Ivan Levkivskyi]

replying to the list now...

On Thu, 30 Aug 2018 at 00:11, Ivan Levkivskyi  wrote:

> On Wed, 29 Aug 2018 at 13:18, Steven D'Aprano  wrote:
>
>> I didn't want to embarass Ivan any further by seemingly picking on his
>> opinion about contracts being always statically checked, but when I
>> asked off-list I got told to reword and post it here. So here it is.
>>
>> Sorry Ivan if this makes you feel I'm picking on you, that isn't my
>> intention.
>>
>
> NP, the discussion just shift more towards terminology etc. which is less
> interesting TBH.
>
> --
> Ivan
>
>
>
___
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] Pre-conditions and post-conditions

[Ivan Levkivskyi]

On Mon, 27 Aug 2018 at 11:39, Steven D'Aprano  wrote:

> On Mon, Aug 27, 2018 at 09:24:20AM +0100, Ivan Levkivskyi wrote:
> > TBH, I think one of the main points of design by contract is that
> contracts
> > are verified statically.
>
> No, that's not correct. Contracts may be verified statically if the
> compiler is able to do so, but they are considered runtime checks.
>

Considered by whom? By people who prefer `assert isinstance(x, int)` over
`x: int`? :-)

Contract in 99% of cases is just another word for type (maybe a very
complex type like `DAG[T] <: Graph[T]`).
Everything else, like `x >= y` is better expressed as an explicit assert
with an assert message.
But again this is rather IMO, than any kind of definition.

There is only one use case I see now where a dedicated syntax would give a
large readability gain:
something like `self.x >= self.y`. But on the other hand I think such
situations are too rare to justify any _new_ syntax.

--
Ivan
___
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] Pre-conditions and post-conditions

[Ivan Levkivskyi]

TBH, I think one of the main points of design by contract is that contracts
are verified statically.
For runtime contract checking I would rather recommend hypothesis library
(or similar).

--
Ivan



On Mon, 27 Aug 2018 at 08:05, Jacco van Dorp  wrote:

> Total noob speaking here, but
>
> Those contracts are mostly important during development right ? Slowdown
> isn't that much of an issue during development. So you could make a debug
> mode that enforces the contracts, and a production mode that code users can
> use during production to stop the slowdown - in this case, your decorators
> can return their functions/classes unaltered. If they do end up with
> problems, you can always ask them to run the same inputs with debug mode on
> to see where it goes wrong.
>
> For the rest, i'm totally new to design by contract. I do get the draw of
> it, but im not sure if I'd ever really use it. I tend to solve my problems
> with a royal sprinkling of logger.debug(f"{val_i_need_to_check}").
> ___
> 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] Consider adding an iterable option to dataclass

[Ivan Levkivskyi]

On 11 August 2018 at 01:29, Eric V. Smith  wrote:

> On 8/10/2018 7:01 PM, Neil Girdhar wrote:
>
>> [...]
>
> [...]
>
>> sequence would simply inherit from collections.abc.Sequence and implement
>> the two methods __len__ and __getitme__.
>>
>
> Unless I'm misunderstanding you, this falls in to the same problem as
> setting __slots__: you need to return a new class, in this case since you
> can't add inheritance after the fact. I don't think __isinstancecheck__
> helps you here, but maybe I'm missing something (I'm not a big user of
> inheritance or ABCs).
>
>
Here are three points to add:

1. collections.abc.Sequence doesn't have a __subclasshook__, i.e. it
doesn't support structural behaviour. There was an idea as a part of PEP
544 to make Sequence and Mapping structural, but it was rejected after all.
2. Mutating __bases__ doesn't require creating a new class. So one can just
add Sequence after creation. That said, I don't like this idea, `typing`
used to do some manipulations with bases, and it caused several confusions
and subtle bugs, until it was "standardised" in PEP 560.
3. In my experience with some real life code the most used tuple API in
named tuples is unpacking, for example:

class Row(NamedTuple):
id: int
name: str

rows: List[Row]

for id, name in rows:
...

I proposed to add it some time ago in
https://github.com/ericvsmith/dataclasses/issues/21, it will be enough to
just generate an __iter__ (btw such classes will be automatically
subclasses of collections.abc.Iterable, which is structural):

@data(iterable=True)class Point:
x: int
y: int
origin = Point(0, 0)
x, y = origin


But this idea was postponed/deferred. Maybe we can reconsider it?

--
Ivan
___
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] PEP 505: None-aware operators

[Ivan Levkivskyi]

I think I am with Michael here. I like the parallel between `??` and `or`,
we don't have `or=`, so `??=` is also not needed.

Although I understand a parallel between `obj.attr` and `obj['attr']`, I
think there is an additional point (in addition to two valid points by
Michael) why I don't like `?[`: in many situations
in my experience optional container attributes were results of suboptimal
APIs, so I would not encourage this pattern.

FWIW, I am rather -0 on adding all proposed operators, but I would be +1 on
adding just the two essential ones: ?? and ?.

--
Ivan



On 20 July 2018 at 01:40, Michael Lee  wrote:

> Hi -- I'm a new voice here, though I've been lurking for a while now.
>
> How do people feel about removing "??=" and "foo?[bar]" from the PEP and
> sticking with just "foo?.bar" and "foo ?? bar"?
>
> Reasons for not implementing "??=":
>
>1. I think the other operators are useful in that they can be chained
>together to shrink many different lines of code. In contrast, ??= can
>shrink at most one line of code: we get to remove a single 'if foo is
>None'. If the rest of the PEP is implemented, we can also just express
>this by doing "foo = foo ?? some_expr" which I think is still
>relatively concise.
>
>2. None of the other short-circuiting operators have an augmented
>assignment form -- e.g. we can do "foo = foo or bar", but there's no
>such thing as "foo or= bar". I don't really see why ?? in particular
>deserves to have an augmented assignment form.
>
>3. We already have two different kinds of assignment operators with
>the inclusion of PEP 572 -- in the interests of keeping Python as simple as
>possible, I think it'd be a good idea not to add a third one.
>
>
> Reasons for not implementing "foo?[bar]":
>
>1. It seems like "foo?[bar]" could be easily confused with "foo??[bar]".
>I don't think it's immediately obvious to a newcomer which spelling
>corresponds to which usage, and getting the two mixed up seems like the
>sort of thing that could cause all sorts of subtle bugs.
>
>2. We can already easily get the same functionality using standard
>Python. E.g., instead of doing foo?["bar"]?[0]?["baz"], we could do 
> lookup(foo,
>"bar", 0, "baz") where lookup is a function that looks roughly like
>this:
>
>def lookup(item, *parts):
>for part in parts:
>if item is None:
>return None
>item = item[parts]
>return item
>
>Of course, we could probably create the same sort of function to
>replace foo?.bar (albeit less ergonomically), but unlike foo?[bar],
>there's no possibility for confusion: doing foo??.bar will never be a
>valid Python expression.
>
>3. One counter-argument against removing foo?[bar] is that it would
>make expression that need both safe index and attribute lookups look weird
>-- you'd sometimes be using the "lookup" function described above (or
>something similar) and sometimes using ".?". However, I'd argue that these
>sorts of scenarios are relatively rare in practice, and that if you really
>need to deal with a bunch of code that requires you to use both forms of
>safe navigation, your code is likely already becoming pretty unreadable and
>should be rewritten -- maybe split up into multiple lines or something, or
>maybe just redesigned from scratch so you don't need to constantly manage a
>mess of Nones.
>
>
> More broadly, I think I agree with the sentiment some other people have
> that Python has acquired a lot of new features in a relatively short period
> of time, and that it would be nice to have some cooldown to let tooling and
> other implementations catch up. In that regard, I'd personally be happy if
> we didn't implement this PEP or just deferred it again. But if we *are*
> moving forward with it, I think it's worth trying to simplify it as much as
> possible/try and make it orthogonal with existing Python features.
>
> (But of course, I'm just some random person on the internet, so IDK if my
> opinion counts for much.)
>
> Regards,
> -- Michael
>
>
> On Thu, Jul 19, 2018 at 5:06 PM, Chris Angelico  wrote:
>
>> On Fri, Jul 20, 2018 at 10:03 AM, Greg Ewing
>>  wrote:
>> > Rhodri James wrote:
>> >>
>> >> If anyone can think of a good word for "if it isn't None, otherwise",
>> I'd
>> >> be all for it :-)
>> >
>> >
>> > I don't think there's any single Engish word that captures
>> > all of that, so we'd have to invent one.
>> >
>> > Some suggestions:
>> >
>> > inno (If Not None, Otherwise)
>> >
>> > oft  (Or, Failing That)
>>
>> Iunno, that'd oft be confusing.
>>
>> Kappa
>>
>> ChrisA
>> ___
>> 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] Where should grouping() live (was: grouping / dict of lists)

[Ivan Levkivskyi]

On 4 July 2018 at 11:25, Steven D'Aprano  wrote:

> On Wed, Jul 04, 2018 at 11:08:05AM +0100, Ivan Levkivskyi wrote:
> > Replying to the question in subject, I think it would be better in
> > collections as a class.
> > Having it just as a function doesn't  buy much, because one can do the
> same
> > with three lines and a defaultdict.
> > However, if this is a class it can support adding new elements, merge the
> > groupeddicts, etc.
>
> defaultdicts support adding new elements, and they have an update method
> same as regular dicts :-)
>

Except that updating will not do what I want. Merging two groupeddicts is
not just `one.update(other)`
Moreover, using just an update with regular dicts will do something
bug-prone, it will add every group
from `other` as an element to the corresponding group in `one`.

--
Ivan
___
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] Where should grouping() live (was: grouping / dict of lists)

[Ivan Levkivskyi]

Replying to the question in subject, I think it would be better in
collections as a class.
Having it just as a function doesn't  buy much, because one can do the same
with three lines and a defaultdict.
However, if this is a class it can support adding new elements, merge the
groupeddicts, etc.

--
Ivan
___
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] Should nested classes in an Enum be Enum members?

[Ivan Levkivskyi]

On 1 July 2018 at 20:47, Ethan Furman  wrote:

> On 07/01/2018 06:03 AM, Ivan Levkivskyi wrote:> On 27 June 2018 at 15:46,
> Ethan Furman wrote:
>
> [...]
>>> So I'm asking the community:  What real-world examples can you offer for
>>> either behavior?  Cases where nested
>>> classes should be enum members, and cases where nested classes should
>>> not be members.
>>>
>>
>> I wanted few times to make an enum of enums. For example:
>>
>> class  Method(Enum):
>>  Powell = 1
>>  Newton_CG = 2
>>  
>>  class Trust(Enum):
>>  Constr = 3
>>  Exact = 4
>>  
>>
>> So that one can write:
>>
>> minimize(..., method=Method.Powell)
>> minimize(..., method=Method.Trust.Exact)  # this currently fails
>>
>
> In such a case, would you want/expect for
>
> --> list(Method)
>
> to return
>
> [, , ..., ]
>
> ?
>

I am fine with what `list(Method)` does currently:

[, , >]

I think it is intuitive that the nested enums are _not_ automatically
flattened. Also it is easy to write a helper that
manually flattens nested enums, but it would be tedious to group them back
if they are already flattened.

The only thing that I find a bit unintuitive is that one needs to write
`Method.Trust.value.Exact` instead of just
`Method.Trust.Exact`.

Maybe his can be allowed by adding a `__getattr__` to `Method` (by the
metaclass) that will check if a value is an enum and
delegate the attribute access.

--
Ivan
___
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] Should nested classes in an Enum be Enum members?

[Ivan Levkivskyi]

Replying to the list this time.

On 27 June 2018 at 15:46, Ethan Furman  wrote:

> [...]
> So I'm asking the community:  What real-world examples can you offer for
> either behavior?  Cases where nested classes should be enum members, and
> cases where nested classes should not be members.
>

I wanted few times to make an enum of enums. For example:

class  Method(Enum):
Powell = 1
Newton_CG = 2

class Trust(Enum):
Constr = 3
Exact = 4


So that one can write:

minimize(..., method=Method.Powell)
minimize(..., method=Method.Trust.Exact)  # this currently fails

--
Ivan
___
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] Add a __cite__ method for scientific packages

[Ivan Levkivskyi]

On 28 June 2018 at 01:19, Nathaniel Smith  wrote:

> On Wed, Jun 27, 2018 at 2:20 PM, Andrei Kucharavy
>  wrote:
> > To remediate to that situation, I suggest a __citation__ method
> associated
> > to each package installation and import. Called from the __main__,
> > __citation__() would scan __citation__ of all imported packages and
> return
> > the list of all relevant top-level citations associated to the packages.
> >
> > As a scientific package developer working in academia, the problem is
> quite
> > serious, and the solution seems relatively straightforward.
> >
> > What does Python core team think about addition and long-term
> maintenance of
> > such a feature to the import and setup mechanisms? What do other users
> and
> > scientific package developers think of such a mechanism for citations
> > retrieval?
>
> This is indeed a serious problem. I suspect python-ideas isn't the
> best venue for addressing it though – there's nothing here that needs
> changes to the Python interpreter itself (I think), and the people who
> understand this problem the best and who are most affected by it,
> mostly aren't here.
>

I actually think the opposite. If this is not fixed in a PEP it will stay
in the current state.
Writing a PEP (and officially accepting it) for this purpose will give a
signal that it is a standard practice
___
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] Copy (and/or pickle) generators

[Ivan Levkivskyi]

>
> [snip]
>
> As Python is being increasingly used for data science, this use case will
> be increasingly common. Being able to copy generators will save a lot of
> work.
>
> Keep in mind, I don't necessarily propose that generators should be fully
> picklable; there are obviously a number of concerns and problems there.
> Just being able to duplicate the generator's state within the interpreter
> would be enough for my use case.
>
> [snip]
>
> Thoughts?
>
>
I also remember I wanted this feature few times in the past, I like the
idea. The problem is who will implement this?
If you have time and energy, then you can just try (but beware, it may be
harder that it looks).

--
Ivan
___
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] Check type hints in stack trace printing

[Ivan Levkivskyi]

On 14 June 2018 at 12:03, Daniel Sánchez Fábregas <
daniel.sanchez.fabre...@xunta.gal> wrote:

> My idea consist in:
> Adding a method to perform type checking in traceback objects
> When printing stack traces search for mistyped arguments and warn about
> them to the user.
>
> Don't know if it is in the roadmap, but seems that have a good
> cost/benefit ratio to me.
>

It seems to me too this will be rather a work for a static type checker
like mypy.
There is a misconception that runtime objects can be attributed (or checked
w.r.t.) static types,
but this is true only in simple cases.

Also such runtime check will be not able to correctly catch many type
errors that can be
detected statically, like a wrong assignment or a Liskov violation.

--
Ivan
___
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] Change magic strings to enums

[Ivan Levkivskyi]

On 25 April 2018 at 12:01, Serhiy Storchaka <storch...@gmail.com> wrote:

> 25.04.18 13:15, Ivan Levkivskyi пише:
>
>> Hm, this is what I wanted to know. I think by rewriting EnumMeta in C we
>> can reduce the creation time of an Enum class
>> (almost) down to the creation time of a normal class, which may be a 4-5x
>> speed-up. What do you think?
>>
>
> It could be great. But I afraid this may add too much complexity in C
> code. Maybe try to implement a simple and fast Enum for using it in the
> stdlib and extend it with a richer interface in the enum module?
>
>
I think we can do something similar to ABCMeta, i.e. the metaclass itself
will stay defined in Python, but the "hottest" parts of its methods will be
replaced with helper functions written in C.
This way we can limit complexity of the C code while still getting almost
all the performance benefits.

--
Ivan
___
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] Change magic strings to enums

[Ivan Levkivskyi]

On 25 April 2018 at 11:03, Serhiy Storchaka <storch...@gmail.com> wrote:

> 25.04.18 10:57, Ivan Levkivskyi пише:
>
>> On 25 April 2018 at 06:03, INADA Naoki <songofaca...@gmail.com > songofaca...@gmail.com>> wrote:
>> enum class creation cost is much heavier than "import enum"
>> cost.
>> Especially, "import socket, ssl" is much slower than before...
>>
>> Is it slow simply because we are creating new  class objects or
>> EnumMeta.__new__ does
>> some extensive calculations? In the latter case rewriting EnumMeta in C
>> might help.
>>
>
> Creating a new function is very cheap -- just around 50 ns on my computer.
>
> Creating a new class is over two orders costly -- around 7 us for an empty
> class on my computer.
>
> Creating a new Enum class is much more costly -- around 40 us for an empty
> class (or 50 us for IntEnum) plus 7 us per member.
>
>
Hm, this is what I wanted to know. I think by rewriting EnumMeta in C we
can reduce the creation time of an Enum class
(almost) down to the creation time of a normal class, which may be a 4-5x
speed-up. What do you think?

--
Ivan
___
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] Change magic strings to enums

[Ivan Levkivskyi]

On 25 April 2018 at 06:03, INADA Naoki  wrote:

> On Wed, Apr 25, 2018 at 12:04 PM, Nick Coghlan  wrote:
> > On 25 April 2018 at 04:56, Ethan Furman  wrote:
> >> On 04/24/2018 10:32 AM, Antoine Pitrou wrote:
> >>
> >>> Also beware the import time cost of having a widely-used module like
> >>> "warnings" depend on the "enum" module and its own dependencies.
> >>
> >>
> >> With all the recent changes to Python, I should go through and see which
> >> dependencies are no longer needed.
> >
> > I was checking this with "./python -X importtime -c 'import enum'",
> > and the overall import time was around 9 ms with a cold disk cache,
> > and 2 ms with a warm one. In both cases, importing "types" and
> > "_collections" accounted for around a 3rd of the time, with the bulk
> > of the execution time being enum's own module level code.
> >
>
> enum class creation cost is much heavier than "import enum" cost.
> Especially, "import socket, ssl" is much slower than before...
>
>
Is it slow simply because we are creating new  class objects or
EnumMeta.__new__ does
some extensive calculations? In the latter case rewriting EnumMeta in C
might help.

--
Ivan
___
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] Fixing class scope brainstorm

[Ivan Levkivskyi]

On 27 March 2018 at 19:47, Paul Moore <p.f.mo...@gmail.com> wrote:

> On 27 March 2018 at 19:43, Ethan Furman <et...@stoneleaf.us> wrote:
> > On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote:
> >>
> >> On 27 March 2018 at 18:19, Guido van Rossum wrote:
> >
> >>> Hm, so maybe we shouldn't touch lambda, but we can at least fix the
> scope
> >>> issues for comprehensions and genexprs.
> >>
> >>
> >> Removing the implicit function scope in comprehensions is something I
> >> wanted for long time.
> >> It would not only "fix" the scoping, but will also fix the yield inside
> >> comprehensions.
> >
> > Can we do it without leaking names?
>
> To me, that would be the ideal. I assume there are significant
> technical challenges, though, as otherwise I'd have thought that would
> have been the approach taken when Python 3 fixed the name leaking
> issue from Python 2.
>
>
Yes, this will be certainly a big PR, but if we agree to do this, I
volunteer to make the PR.

--
Ivan
___
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] Fixing class scope brainstorm

[Ivan Levkivskyi]

On 27 March 2018 at 19:43, Ethan Furman <et...@stoneleaf.us> wrote:

> On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote:
>
>> On 27 March 2018 at 18:19, Guido van Rossum wrote:
>>
>
> Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope
>>> issues for comprehensions and genexprs.
>>>
>>
>> Removing the implicit function scope in comprehensions is something I
>> wanted for long time.
>> It would not only "fix" the scoping, but will also fix the yield inside
>> comprehensions.
>>
>
> Can we do it without leaking names?
>
>
If you mean this

[i for i in range(5)]

i  # NameError

then yes, this is possible. Serhiy outlined the implementation few moths
ago. The rough idea is to use automatic re-naming.
The only problem with this is that if someone will step into debugger one
will see a name like .0.i instead of i.
But this can be solved in the debuggers.

--
Ivan
___
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] Fixing class scope brainstorm

[Ivan Levkivskyi]

On 27 March 2018 at 18:19, Guido van Rossum  wrote:

> On Tue, Mar 27, 2018 at 6:56 AM, Nick Coghlan  wrote:
>
>> [...] The implicit functions used in the
>> comprehension & generator expression cases are just potentially
>> simpler to handle, as we don't care about their API signatures, which
>> means we can freely pollute their APIs with eager name bindings if we
>> choose to do so. [...]
>>
>
> Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope
> issues for comprehensions and genexprs.
>

Removing the implicit function scope in comprehensions is something I
wanted for long time.
It would not only "fix" the scoping, but will also fix the yield inside
comprehensions.

--
Ivan
___
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] Dataclasses, keyword args, and inheritance

[Ivan Levkivskyi]

It is possible to pass init=False to the decorator on the subclass (and
supply your own custom __init__, if necessary):

@dataclass
class Foo:
some_default: dict = field(default_factory=dict)

@dataclass(init=False) # This works
class Bar(Foo):
other_field: int

--
Ivan



On 23 January 2018 at 03:33, George Leslie-Waksman 
wrote:

> The proposed implementation of dataclasses prevents defining fields with
> defaults before fields without defaults. This can create limitations on
> logical grouping of fields and on inheritance.
>
> Take, for example, the case:
>
> @dataclass
> class Foo:
> some_default: dict = field(default_factory=dict)
>
> @dataclass
> class Bar(Foo):
> other_field: int
>
> this results in the error:
>
>   5 @dataclass
> > 6 class Bar(Foo):
>   7 other_field: int
>   8
>
> ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py
> in dataclass(_cls, init, repr, eq, order, hash, frozen)
> 751
> 752 # We're called as @dataclass, with a class.
> --> 753 return wrap(_cls)
> 754
> 755
>
> ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py
> in wrap(cls)
> 743
> 744 def wrap(cls):
> --> 745 return _process_class(cls, repr, eq, order, hash, init,
> frozen)
> 746
> 747 # See if we're being called as @dataclass or @dataclass().
>
> ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py
> in _process_class(cls, repr, eq, order, hash, init, frozen)
> 675 #  in __init__.  Use "self" if
> possible.
> 676 '__dataclass_self__' if 'self' in
> fields
> --> 677 else 'self',
> 678 ))
> 679 if repr:
>
> ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py
> in _init_fn(fields, frozen, has_post_init, self_name)
> 422 seen_default = True
> 423 elif seen_default:
> --> 424 raise TypeError(f'non-default argument {f.name!r}
> '
> 425 'follows default argument')
> 426
>
> TypeError: non-default argument 'other_field' follows default argument
>
> I understand that this is a limitation of positional arguments because the
> effective __init__ signature is:
>
> def __init__(self, some_default: dict = , other_field: int):
>
> However, keyword only arguments allow an entirely reasonable solution to
> this problem:
>
> def __init__(self, *, some_default: dict = , other_field: int):
>
> And have the added benefit of making the fields in the __init__ call
> entirely explicit.
>
> So, I propose the addition of a keyword_only flag to the @dataclass
> decorator that renders the __init__ method using keyword only arguments:
>
> @dataclass(keyword_only=True)
> class Bar(Foo):
> other_field: int
>
> --George Leslie-Waksman
>
> ___
> 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] Improve ABCs _dump_registry() readability

[Ivan Levkivskyi]

On 31 December 2017 at 20:05, Antoine Pitrou <solip...@pitrou.net> wrote:

> On Sun, 31 Dec 2017 19:31:06 +0100
> Ivan Levkivskyi <levkivs...@gmail.com>
> wrote:
>
> > On 31 December 2017 at 19:24, Yahya Abou 'Imran via Python-ideas <
> > python-ideas@python.org> wrote:
> >
> > >
> > > >I guess a PR to fix the registry output would make sense (first file a
> > > bug on bugs.python.org for it).
> > >
> > > Ok, I will!
> > >
> > >
> > Please don't hurry with this. I am going to rewrite ABCMeta in C soon.
> > In fact most of the work is done but I am waiting for implementation of
> PEP
> > 560 to settle (need few more days for this).
> >
> > In the C version the caches/registry will be simpler and will not use
> > WeakSet (instead they will be thin C wrappers around normal sets).
>
> Hmm... Just because you are rewriting the thing in C doesn't mean that
> Yahya shouldn't submit a patch for the Python version (which I assume
> will be staying around anyway).
>

Yes, good point!

--
Ivan
___
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] Improve ABCs _dump_registry() readability

[Ivan Levkivskyi]

On 31 December 2017 at 19:24, Yahya Abou 'Imran via Python-ideas <
python-ideas@python.org> wrote:

>
> >I guess a PR to fix the registry output would make sense (first file a
> bug on bugs.python.org for it).
>
> Ok, I will!
>
>
Please don't hurry with this. I am going to rewrite ABCMeta in C soon.
In fact most of the work is done but I am waiting for implementation of PEP
560 to settle (need few more days for this).

In the C version the caches/registry will be simpler and will not use
WeakSet (instead they will be thin C wrappers around normal sets).

--
Ivan
___
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] Repr of lambda

[Ivan Levkivskyi]

Serhiy,

I like the idea, but in typeshed we have an agreement to always show a
default value by an ellipsis.
For example, definition like this:

def fun(x, y, z=0):
return x + y + z

can be represented like this

fun(x, y, z=...)

or if one has annotations in the definition, then

fun(x: int, y: int, z: int = ...) -> int

So if you would make this change, I would prefer the existing "style".

--
Ivan
___
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] Stub class for Generic to further improve PEP 560

[Ivan Levkivskyi]

On 1 December 2017 at 00:34, Ilya Kulakov  wrote:

> Anyway, my expectation is that going along this way (i.e. removing all
> runtime API apart from a necessary minimum)
> will give a minor speed-up as compared to PEP 560 at the cost of a
> breaking change (even for small number of developers).
>
>
> I don't think the change will be breaking: usage of this class will be
> entirely voluntarily and does not replace typing.Generic
>
>
If you propose an additional class, then yes, it is non-breaking, but I
still don't see much value given a minor performance improvement.


> PEP 560 already gives overhead of 80% as compared to normal classes in
> worst case scenario
> (empty body with a single generic base). This is actually less than for
> ABCs (they can give up to 120% in worst case scenario).
>
>
> GenericMeta inherits from ABCMeta. Do you mean that it will be removed
> after 560 lands?
>
>
Yes, GenericMeta will be removed.


> Moreover, performance is not a single motivation for PEP 560, there are
> other arguments such as metaclass conflicts which will
> not be solved without the machinery proposed by the PEP.
>
>
> Perhaps you can consider designing Generic / GenericMeta in a way that
> will allow end user to create GenericStub-alike class without much trouble?
>

This can be done, but the hardest part here is not to make the runtime
changes, but to get the support of all
static type checkers (they need to understand what GenericStub means and
add all the necessary special casing).

--
Ivan
___
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] Stub class for Generic to further improve PEP 560

[Ivan Levkivskyi]

On 30 November 2017 at 22:38, Ilya Kulakov  wrote:

> A very rough implementation:
>
> typing.py:
>
> class _GenericMetaNoop(type):
> def __getitem__(self, params):
> return self
>
> class _GenericNoop(metaclass=_GenericMetaNoop)
> pass
>
> GenericStub = Generic if TYPE_CHECKING else _GenericNoop
>
> elsewhere.py:
>
> import typing
>
> T = typing.TypeVar('T')
>
> class MyClass(typing.GenericStub[T]):
> pass
>
>
OK, I see.

Note that all type checkers known to me never actually read content of
typing.py (it is always heavily special cased).
Therefore, one can safely write `GenericStub = _GenericNoop`.

Anyway, my expectation is that going along this way (i.e. removing all
runtime API apart from a necessary minimum)
will give a minor speed-up as compared to PEP 560 at the cost of a breaking
change (even for small number of developers).
PEP 560 already gives overhead of 80% as compared to normal classes in
worst case scenario
(empty body with a single generic base). This is actually less than for
ABCs (they can give up to 120% in worst case scenario).

Moreover, performance is not a single motivation for PEP 560, there are
other arguments such as metaclass conflicts which will
not be solved without the machinery proposed by the PEP.

--
Ivan
___
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] Stub class for Generic to further improve PEP 560

[Ivan Levkivskyi]

On 30 November 2017 at 22:25, Ilya Kulakov  wrote:

> My point is to have a class with public interface identical to
> typing.Generic, but without all runtime overhead.
> It's based on the assumption that few developers benefit with
> typing.Generic addition during production application execution.
>
> Those who do, can subclass typing.Generic directly


Could you please give some examples for these statements? They still look
to abstract for me.

--
Ivan
___
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] Add a dict with the attribute access capability

[Ivan Levkivskyi]

On 29 November 2017 at 20:11, Barry Warsaw  wrote:

> Serhiy Storchaka wrote:
> > In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
> > already was deprecated when the plistlib module was added to the regular
> > stdlib in Python 2.6.
> >
> > Raymond noticed that that capability seemed nice to have.
>
> So nice in fact that I'm sure I've reimplemented something similar
> several times. :)
>
> > What do you think about reviving this type as general purpose type in
> > collections or types? Perhaps it can be convenient for working with
> > JSON, plists, configuration files, databases and in other cases that
> > need a dict with string keys.
> >
> > If reintroduce it, there are open questions.
> >
> > 1. The name of the type.
> >
> > 2. The location of the type. collections or types? Or other variants?
> >
> > 3. How it will collaborate with OrderedDict, defaultdict, etc?
> >
> > 4. Should it be a dict subclass, or a mixin, or a proxy? Or add several
> > types?
>
> I also wonder whether PEP 557 dataclasses could provide this except in
> the opposite direction, e.g. by optionally adding __getitem__ support.
>

This was discussed in https://github.com/ericvsmith/dataclasses/issues/21
and it was decided to postpone this.

--
Ivan
___
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] Should Python have user-defined constants?

[Ivan Levkivskyi]

On 21 November 2017 at 14:22, Kirill Balunov 
wrote:

> It is not set in stone, but it looks like most people like Final (although
>> the initial proposal was Const, see https://github.com/python/mypy
>> /issues/1214)
>>
>
>
> Ivan, you mean this thread "Can't index named tuple by defined constant"
> ?
>

Discussions about Final/Const happened in several threads on both typing
and mypy trackers, I just don't remember them all.

--
Ivan
___
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] Should Python have user-defined constants?

[Ivan Levkivskyi]

On 21 November 2017 at 12:12, Stéfane Fermigier  wrote:

> That's one way to do it with no changes to the language, though
> syntaxically I find it lacking a bit of elegance (maybe a matter of getting
> accustomed with it?).
>
> Also, I'm not sure "Final" really conveys what it means (at first glance,
> I thought it was about immutability, not constantness).
>
> Maybe "Const" would be better in this context ? (Or maybe you've discussed
> this question already and come to the conclusion that "Final" is better for
> some reason?)
>

It is not set in stone, but it looks like most people like Final (although
the initial proposal was Const, see
https://github.com/python/mypy/issues/1214)

--
Ivan
___
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] Should Python have user-defined constants?

[Ivan Levkivskyi]

On 21 November 2017 at 10:47, Paul Moore  wrote:

> -1. I don't see how this would improve any programs I've written or
> seen. Tools like mypy or linters might benefit from a feature to track
> constants and ensure they don't get changed
>

It is actually likely that something like this will appear in ``typing``:

from typing import Final, List

x: Final = 42
x = 1  # Fails type check

lst: Final[List[int]] = []
lst.append(5)  # OK
lst = [1, 2, 3]  # Fails type check

--
Ivan
___
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] Terminology of types / typing [was: PEP 560 (second post)]

[Ivan Levkivskyi]

At some point it was proposed to distinguish two things: types (static) and
classes (runtime).
I don't think we need more fine grained terminology here.

--
Ivan



On 15 November 2017 at 17:54, Koos Zevenhoven  wrote:

> On Wed, Nov 15, 2017 at 1:41 PM, Koos Zevenhoven 
> wrote:
> [..]
>
>> What do we call such a "type"? Maybe we have both "concrete" and
>> "strictly concrete" types. Perhaps we also have both "abstract" and
>> "strictly abstract" types. An ABC with some concrete default
>> implementations might then be both a concrete type and an abstract type.
>>
>> Note that in the above bullet point "definition" of concrete type, I
>> intentionally left out the requirement that the type can be instantiated.
>>
>> The other two bullet points are:
>>
>> * strictly concrete type: a concrete type that is not abstract––it
>> concretely implements everything that it represents / describes. This is
>> almost always a normal class, so it might be also known as "class".
>>
>> * strictly abstract type: an abstract type that is not concrete––it does
>> not implement any functionality or storage.
>>
>> ​There might be a way to improve terminology from this, but I feel that
>> what I sketched here is usable but still not very ambiguous.
>>
>>
> ​Let me rephrase that last sentence: I think this terminology is more
> clear.
>
> And here's some additional clarification:
>
> I expect that the possibility of a type being both concrete and abstract
> may sound strange. In some ways it is indeed strange, but this overlap of
> concepts definitely exists already, we just need to categorize and define
> the concepts clearly, but without introducing too many concepts whose
> relations to each other are messy.
>
> This might also seem strange if you are not used to how "strict" is often
> used in mathematics and related sciences. Essentially, it's synonymous to
> "proper"​. For example,  "strict subset" and "proper subset" of a set both
> refer to a subset that is not the set itself. Any set is both a superset
> and subset of itself (in non-strict terms).  Also "pure" might sometimes
> refer to something similar.
>
> So in some sense it means excluding the "gray area". Often that "gray
> area" is kept part of the non-strict/improper concept for convenience.
> ​
> ––Koos
> ​
>
> --
> + Koos Zevenhoven + http://twitter.com/k7hoven +
>
> ___
> 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] Complete typing.Union with the rest of set-like functions

[Ivan Levkivskyi]

Intersection has already been proposed, see
https://github.com/python/typing/issues/213
But it is not yet implemented. You can show your use cases on the typing
issue tracker,
maybe they can be covered by Intersection (which will be most probably
added at some point).

--
Ivan



On 13 November 2017 at 20:32, Ilya Kulakov  wrote:

> I needed to declare a type that would mean "Any but None" and didn't find
> how.
>
> Current implementation allows to expand set of allowed types, not narrow
> it.
> Perhaps typing needs the rest of set operators in addition to Union?
>
>
> Best Regards,
> Ilya Kulakov
>
>
> ___
> 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] PEP 562

[Ivan Levkivskyi]

On 10 November 2017 at 22:27, Guido van Rossum  wrote:

> Picking up this thread as part of the PEP 562 and PEP 549 review. I like
> PEP 562 most, but I propose to add special-casing for `__dir__`. Not quite
> as proposed above (making the C level module_dir() look for `__all__`) but
> a bit more general -- making module_dir() look for `__dir__` and call that
> if present and callable. Ivan what do you think of that idea? It should be
> simple to add to your existing implementation. (https://github.com/
> ilevkivskyi/cpython/pull/3#issuecomment-343591293)
>
>
I like this idea. I was thinking about yet another option: *extending* the
result of current dir() search by contents __all__ if present (not just
returning contents of __all__).
But it looks like your idea covers more use cases, so I would stick with
your idea.

--
Ivan
___
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] PEP 560 (second post)

[Ivan Levkivskyi]

On 10 November 2017 at 21:19, Koos Zevenhoven <k7ho...@gmail.com> wrote:

> On Fri, Nov 10, 2017 at 8:33 PM, Ivan Levkivskyi <levkivs...@gmail.com>
> wrote:
>
>> On 10 November 2017 at 18:39, Koos Zevenhoven <k7ho...@gmail.com> wrote:
>>
>>> On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi <levkivs...@gmail.com>
>>> wrote:
>>>
>>>> ​
>>>>
>>> ​
>>>> After creating the class,
>>>> the original bases are saved in ``__orig_bases__`` (currently this is
>>>> also
>>>> done by the metaclass).
>>>>
>>>>
>>> ​Those are *still* bases, right, even if they are not in the mro?​ I'm
>>> not sure if this is a naming thing or something even more.
>>>
>>
>> The objects that have __subclass_base__ method (proposed to rename to
>> __mro_entry__)
>> are removed from __bases__ attributed of the newly created class.
>> Otherwise they may cause a metaclass conflict.
>> One can however still call them syntactic (or static?) bases. For example
>> this is how it is going to be used by typing:
>>
>> from typing import List
>>
>> class Tokens(List[int]):
>> ...
>>
>> assert Tokens.__bases__ == (list,)
>>
>
> ​Why is List[int] not allowed to be the base? Neither method-lookup
> performance nor the metaclass conflict issue seem to depend on whether
> List[int] is in __bases__.
>
>
The situation is actually quite opposite. Interestingly, the whole
discussion started from Mark Shannon pointing to these problems with
List[int] at the Language Summit.
The original discussion on typing tracker is referenced in the PEP draft.

--
Ivan
___
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] PEP 560 (second post)

[Ivan Levkivskyi]

On 10 November 2017 at 18:39, Koos Zevenhoven <k7ho...@gmail.com> wrote:

> On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi <levkivs...@gmail.com>
> wrote:
>
>> ​
>>
> ​
>> After creating the class,
>> the original bases are saved in ``__orig_bases__`` (currently this is also
>> done by the metaclass).
>>
>>
> ​Those are *still* bases, right, even if they are not in the mro?​ I'm not
> sure if this is a naming thing or something even more.
>

The objects that have __subclass_base__ method (proposed to rename to
__mro_entry__)
are removed from __bases__ attributed of the newly created class. Otherwise
they may cause a metaclass conflict.
One can however still call them syntactic (or static?) bases. For example
this is how it is going to be used by typing:

from typing import List

class Tokens(List[int]):
...

assert Tokens.__bases__ == (list,)


> NOTE: These two method names are reserved for exclusive use by
>> the ``typing`` module and the generic types machinery, and any other use
>> is
>> strongly discouraged.
>>
>
> ​Given the situation, that may be a good thing. But will it really work? I
> think it is also strongly discouraged to invent your own dunder method
> names, but people still do it.​
>

Terry had a similar comment. I will "soften" this formulation in the next
revision of the PEP.

--
Ivan
___
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] PEP 560 (second post)

[Ivan Levkivskyi]

On 10 November 2017 at 17:43, Guido van Rossum  wrote:

> Hey Ivan,
>
> There seem to be some action items from this thread that I haven't seen
> reflected in the PEP source code yet.
> [...snip...]
> Then the next step I propose is a PR with a full implementation. After
> that I'll likely approve the PEP (or we'll have minor feedback based on
> trying the implementation).
>
>
Yes, sorry, I wanted to make updates to the PEP and reference
implementation,
but last two weeks were very busy.
Hopefully, I will work on it this weekend.

--
Ivan
___
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] install pip packages from Python prompt

[Ivan Levkivskyi]

Just another random idea: What about simply having two menu items in IDLE:

* Install/update package manager
* Open package manager

The first one will install the pipgui from PyPI (and pip if not already
installed).
The second one will run the GUI.

This way it looks like pipgui can be simply published on PyPI without
special-casing at all, or am I missing something?

--
Ivan



On 2 November 2017 at 11:53, Nick Coghlan  wrote:

> On 2 November 2017 at 18:46, Nathaniel Smith  wrote:
>
>> But unfortuately this hasn't been standardized, and there's currently
>> no way to do the lookup from the stdlib, so maybe this is not so
>> helpful for IDLE...
>>
>
> The entry point file format was recently promoted to a PyPA
> interoperability spec (without a PEP, as we documented it as-is, rather
> than changing anything): https://packaging.python.org/
> specifications/entry-points/
>
> While the point about the standard library lacking the ability to read the
> metadata for installed packages still stands, it's also not too hard to
> implement a rudimentary version that just iterates over sys.path looking
> for `entry_points.txt` files in `*.dist-info` subdirectories.
>
> 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/
>
>
___
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] install pip packages from Python prompt

[Ivan Levkivskyi]

I think it was proposed several times before, but I just wanted to revive
the idea that we could add
a GUI interface to install/update packages from IDLE (maybe even with some
package browser).

--
Ivan
___
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] PEP 561: Distributing Type Information V3

[Ivan Levkivskyi]

Thanks Ethan!

The PEP draft now looks good to me. I think it makes sense to make
a PoC implementation of the PEP at this point to see if everything
works smoothly in practice.

(You could also link few examples with your PoC implementation in the PEP)

--
Ivan



On 6 October 2017 at 22:00, Ethan Smith  wrote:

> Hello,
>
> I have made some changes to my PEP on distributing type information. A
> summary of the changes:
>
>- Move to adding a new metadata specifier so that more packaging tools
>can participate
>- Clarify version matching between third party stubs and runtime
>packages.
>- various other fixes for clarity, readability, and removal of
>repetition
>
> As usual I have replicated a copy below.
>
> Cheers,
> Ethan
>
>
> PEP: 561
> Title: Distributing and Packaging Type Information
> Author: Ethan Smith 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 09-Sep-2017
> Python-Version: 3.7
> Post-History:
>
>
> Abstract
> 
>
> PEP 484 introduced type hinting to Python, with goals of making typing
> gradual and easy to adopt. Currently, typing information must be distributed
> manually. This PEP provides a standardized means to package and distribute
> type information and an ordering for type checkers to resolve modules and
> collect this information for type checking using existing packaging
> architecture.
>
>
> Rationale
> =
>
> Currently, package authors wish to distribute code that has
> inline type information. However, there is no standard method to distribute
> packages with inline type annotations or syntax that can simultaneously
> be used at runtime and in type checking. Additionally, if one wished to
> ship typing information privately the only method would be via setting
> ``MYPYPATH`` or the equivalent to manually point to stubs. If the package
> can be released publicly, it can be added to typeshed [1]_. However, this
> does not scale and becomes a burden on the maintainers of typeshed.
> Additionally, it ties bugfixes to releases of the tool using typeshed.
>
> PEP 484 has a brief section on distributing typing information. In this
> section [2]_ the PEP recommends using ``shared/typehints/pythonX.Y/`` for
> shipping stub files. However, manually adding a path to stub files for each
> third party library does not scale. The simplest approach people have taken
> is to add ``site-packages`` to their ``MYPYPATH``, but this causes type
> checkers to fail on packages that are highly dynamic (e.g. sqlalchemy
> and Django).
>
>
> Specification
> =
>
> There are several motivations and methods of supporting typing in a package.
> This PEP recognizes three (3) types of packages that may be created:
>
> 1. The package maintainer would like to add type information inline.
>
> 2. The package maintainer would like to add type information via stubs.
>
> 3. A third party would like to share stub files for a package, but the
>maintainer does not want to include them in the source of the package.
>
> This PEP aims to support these scenarios and make them simple to add to
> packaging and deployment.
>
> The two major parts of this specification are the packaging specifications
> and the resolution order for resolving module type information. The packaging
> spec is based on and extends PEP 345 metadata. The type checking spec is
> meant to replace the ``shared/typehints/pythonX.Y/`` spec of PEP 484 [2]_.
>
> New third party stub libraries are encouraged to distribute stubs via the
> third party packaging proposed in this PEP in place of being added to
> typeshed. Typeshed will remain in use, but if maintainers are found, third
> party stubs in typeshed are encouraged to be split into their own package.
>
> Packaging Type Information
> --
> In order to make packaging and distributing type information as simple and
> easy as possible, the distribution of type information, and typed Python code
> is done through existing packaging frameworks. This PEP adds a new item to the
> ``*.distinfo/METADATA`` file to contain metadata about a package's support for
> typing. The new item is optional, but must have a name of ``Typed`` and have a
> value of either ``inline`` or ``stubs``, if present.
>
> Metadata Examples::
>
> Typed: inline
> Typed: stubs
>
>
> Stub Only Packages
> ''
>
> For package maintainers wishing to ship stub files containing all of their
> type information, it is prefered that the ``*.pyi`` stubs are alongside the
> corresponding ``*.py`` files. However, the stubs may be put in a sub-folder
> of the Python sources, with the same name the ``*.py`` files are in. For
> example, the ``flyingcircus`` package would have its stubs in the folder
> ``flyingcircus/flyingcircus/``. This path is chosen so that if stubs are
> not found in ``flyingcircus/`` the type checker may treat the subdirectory as
> a normal package. The normal 

Re: [Python-ideas] PEP 560 (second post)

[Ivan Levkivskyi]

On 29 September 2017 at 08:57, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 29 September 2017 at 08:04, Ivan Levkivskyi <levkivs...@gmail.com>
> wrote:
> >> How would you feel about calling it "__mro_entry__", as a mnemonic for
> >> "the substitute entry to use instead of this object when calculating a
> >> subclass MRO"?
> >
> > I don't have any preferences for the name, __mro_entry__ sounds equally
> OK
> > to me.
>
> I'd propose changing it then, as searching for "Python mro entry" is
> likely to get people to the right place faster than searching for
> "Python subclass base".
>
>
OK, will do.


> > I propose to update
> > ``type.__new__`` to just give
> > a better error message explaining this.
>
> +1 from me, since that avoids ever resolving the list of bases twice.
>
>
OK, I will update the reference implementation.


> > 3) Do we need to update types.new_class and types.prepare_class?
> > Here I am not sure. These functions are rather utility functions and are
> > designed to
> > mimic in Python what __build_class__ does in C. I think we might add
> > types._update_bases
> > that does the same as its C counterpart. Then we can update
> types.new_class
> > and types.prepare_class
> > like you proposed, this will preserve their current API while
> > types.new_class will match behaviour of __build_class__
>
> Your suggestion for `types.__new__` gave me a different idea: what if
> `types.prepare_class` *also* just raised an error when given a
> non-class as a nominal base class?
>
> Then if we added `types.resolve_bases` as a public API, a full
> reimplementation of `types.new_class` would now look like:
>
> resolved_bases = types.resolve_bases(bases)
> mcl, ns, updated_kwds = types.prepare_class(name, resolved_bases, kwds)
> exec_body(ns)
> ns["__orig_bases__"] = bases
> mcl(name, resolved_bases, ns, **updated_kwds)
>
> That way, `types.new_class` would transparently switch to the new
> behaviour, while clients of any other dynamic type creation API could
> do their own base class resolution, even if the type creation API they
> were using didn't implicitly support MRO entry resolution.
>
>
Yes, makes sense. I no one is against adding new public
``types.resolve_bases``
then I will add this to the PEP.

--
Ivan
___
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] PEP 560 (second post)

[Ivan Levkivskyi]

On 29 September 2017 at 10:14, Victor Stinner 
wrote:

> > Title: Core support for generic types
>
> Would it be possible to mention "typing" somewhere in the title? If
> you don't know the context, it's hard to understand that the PEP is
> related to type annotation and type checks. At least just from the
> title.
>

What do you think about "Core support for typing module and generic types"?
Another option is "Runtime mechanism to improve generics and typing module".

--
Ivan
___
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] PEP 560 (second post)

[Ivan Levkivskyi]

On 28 September 2017 at 08:27, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 27 September 2017 at 19:28, Ivan Levkivskyi <levkivs...@gmail.com>
> wrote:
> > If an object that is not a class object appears in the bases of a class
> > definition, the ``__subclass_base__`` is searched on it. If found,
> > it is called with the original tuple of bases as an argument. If the
> result
> > of the call is not ``None``, then it is substituted instead of this
> object.
> > Otherwise (if the result is ``None``), the base is just removed. This is
> > necessary to avoid inconsistent MRO errors, that are currently prevented
> by
> > manipulations in ``GenericMeta.__new__``. After creating the class,
> > the original bases are saved in ``__orig_bases__`` (currently this is
> also
> > done by the metaclass).
>
> How would you feel about calling it "__mro_entry__", as a mnemonic for
> "the substitute entry to use instead of this object when calculating a
> subclass MRO"?
>
>
I don't have any preferences for the name, __mro_entry__ sounds equally OK
to me.

I think the other thing that needs to be clarified is whether or not
> the actual metaclass can expect to receive an already-resolved
> sequence of MRO entries as its list of bases, or if it will need to
> repeat the base resolution process executed while figuring out the
> metaclass.
>
>
There are three points for discussion here:

1) It is necessary to make the bases resolution soon, before the metaclass
is calculated. This is why I do this at the beginning of __build_class__ in
the
reference implementation.

2) Do we need to update type.__new__ to be able to accept non-classes as
bases?
I think no. One might be a bit surprised that

class C(Iterable[int]):
pass

works, but

type('C', (Iterable[int],), {})

fails with a metaclass conflict, but I think it is natural that static
typing and dynamic
class creation should not be used together. I propose to update
``type.__new__`` to just give
a better error message explaining this.

3) Do we need to update types.new_class and types.prepare_class?
Here I am not sure. These functions are rather utility functions and are
designed to
mimic in Python what __build_class__ does in C. I think we might add
types._update_bases
that does the same as its C counterpart. Then we can update types.new_class
and types.prepare_class
like you proposed, this will preserve their current API while
types.new_class will match behaviour of __build_class__

If you and others agree with this, then I will update the PEP text and the
reference implementation.

Thanks for comments!

--
Ivan
___
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] PEP 560 (second post)

[Ivan Levkivskyi]

On 27 September 2017 at 18:08, Terry Reedy <tjre...@udel.edu> wrote:

> On 9/27/2017 5:28 AM, Ivan Levkivskyi wrote:
>
> It is proposed to add two special methods ``__class_getitem__`` and
>> ``__subclass_base__`` to the core CPython for better support of
>> generic types.
>>
>
> I would not be concerned about anyone (mis)using reserved words.
>
>
These methods are quite specific (especially __subclass_base__) so there
are two points:

* I would like to say that there are less backwards compatibility
guarantees. Only the documented use
  is guaranteed to be backwards compatible, which is in this case
Iterable[int] etc.

* I don't want to "advertise" these methods. I could imagine someone will
be unpleasantly surprised when
  finding these while reading someone other's code.


> If the new methods were for general use, I would question making them
> automatically class methods.  Having __new__ automatically being a static
> method is convenient, but occasionally throws people off.  But if they were
> only used for typing, perhaps it is ok.  On the other hand, I expect that
> others will use __class_getitem__ for the same purpose -- to avoid defining
> a metaclass just to make class[something] work.  So I question defining
> that as 'typing only'.
>
>
I think we would rather want to limit the number of use cases for
SomeClass[int], so that one doesn't need to guess if it is a generic class
or something else.


> Without rereading the PEP, the use case for __subclass_base__ is not clear
> to me.  So I don't know if there are other uses for it.
>

The __subclass_base__ method is needed to avoid making the result of
Iterable[int] a class object. Creating new class objects on
every subscription is too expensive. However, these objects must be
subclassable, so that the only way is to introduce this new method.
For example:

class Iterable:
def __class_getitem__(cls, item):
return GenericAlias(cls, item)

class GenericAlias:
def __init__(self, origin, item):
self.origin = origin
self.item = item
def __subclass_base__(self, bases):
return self.origin

class MyIterable(Iterable[int]):
...

Real code will be more complex, but this illustrates the idea. I don't know
other use cases where one
would want to allow non-classes in base classes list.

Thanks for comments!

--
Ivan
___
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] PEP 560 (second post)

[Ivan Levkivskyi]

Previously I posted PEP 560 two weeks ago, while several other PEPs were
also posted, so it didn't get much of attention. Here I post the PEP 560
again, now including the full text for convenience of commenting.

--
Ivan



PEP: 560
Title: Core support for generic types
Author: Ivan Levkivskyi <levkivs...@gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 03-Sep-2017
Python-Version: 3.7
Post-History: 09-Sep-2017


Abstract


Initially PEP 484 was designed in such way that it would not introduce
*any* changes to the core CPython interpreter. Now type hints and
the ``typing`` module are extensively used by the community, e.g. PEP 526
and PEP 557 extend the usage of type hints, and the backport of ``typing``
on PyPI has 1M downloads/month. Therefore, this restriction can be removed.
It is proposed to add two special methods ``__class_getitem__`` and
``__subclass_base__`` to the core CPython for better support of
generic types.


Rationale
=

The restriction to not modify the core CPython interpreter lead to some
design decisions that became questionable when the ``typing`` module started
to be widely used. There are three main points of concerns:
performance of the ``typing`` module, metaclass conflicts, and the large
number of hacks currently used in ``typing``.


Performance:


The ``typing`` module is one of the heaviest and slowest modules in
the standard library even with all the optimizations made. Mainly this is
because subscripted generic types (see PEP 484 for definition of terms
used in this PEP) are class objects (see also [1]_). The three main ways how
the performance can be improved with the help of the proposed special
methods:

- Creation of generic classes is slow since the ``GenericMeta.__new__`` is
  very slow; we will not need it anymore.

- Very long MROs for generic classes will be twice shorter; they are present
  because we duplicate the ``collections.abc`` inheritance chain
  in ``typing``.

- Time of instantiation of generic classes will be improved
  (this is minor however).


Metaclass conflicts:


All generic types are instances of ``GenericMeta``, so if a user uses
a custom metaclass, then it is hard to make a corresponding class generic.
This is particularly hard for library classes that a user doesn't control.
A workaround is to always mix-in ``GenericMeta``::

  class AdHocMeta(GenericMeta, LibraryMeta):
  pass

  class UserClass(LibraryBase, Generic[T], metaclass=AdHocMeta):
  ...

but this is not always practical or even possible. With the help of the
proposed special attributes the ``GenericMeta`` metaclass will not be
needed.


Hacks and bugs that will be removed by this proposal:
-

- ``_generic_new`` hack that exists since ``__init__`` is not called on
  instances with a type differing form the type whose ``__new__`` was
called,
  ``C[int]().__class__ is C``.

- ``_next_in_mro`` speed hack will be not necessary since subscription will
  not create new classes.

- Ugly ``sys._getframe`` hack, this one is particularly nasty, since it
looks
  like we can't remove it without changes outside ``typing``.

- Currently generics do dangerous things with private ABC caches
  to fix large memory consumption that grows at least as O(N\ :sup:`2`),
  see [2]_. This point is also important because it was recently proposed to
  re-implement ``ABCMeta`` in C.

- Problems with sharing attributes between subscripted generics,
  see [3]_. Current solution already uses ``__getattr__`` and
``__setattr__``,
  but it is still incomplete, and solving this without the current proposal
  will be hard and will need ``__getattribute__``.

- ``_no_slots_copy`` hack, where we clean-up the class dictionary on every
  subscription thus allowing generics with ``__slots__``.

- General complexity of the ``typing`` module, the new proposal will not
  only allow to remove the above mentioned hacks/bugs, but also simplify
  the implementation, so that it will be easier to maintain.


Specification
=

The idea of ``__class_getitem__`` is simple: it is an exact analog of
``__getitem__`` with an exception that it is called on a class that
defines it, not on its instances, this allows us to avoid
``GenericMeta.__getitem__`` for things like ``Iterable[int]``.
The ``__class_getitem__`` is automatically a class method and
does not require ``@classmethod`` decorator (similar to
``__init_subclass__``) and is inherited like normal attributes.
For example::

  class MyList:
  def __getitem__(self, index):
  return index + 1
  def __class_getitem__(cls, item):
  return f"{cls.__name__}[{item.__name__}]"

  class MyOtherList(MyList):
  pass

  assert MyList()[0] == 1
  assert MyList[int] == "MyList[int]"

  assert MyOtherList()[0] == 1
  assert MyOthe

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

[Ivan Levkivskyi]

> The difference in allocated memory is over 22 MB.
> The import time with annotations is over 2s longer.
> The problem with those numbers that we still have 80% functions to cover.

This will not be a problem with PEP 560 (I could imagine that string objects
may take actually more memory than relatively small cached objects).

Also I think it makes sense to mention in the PEP that stringifying
annotations
does not solve _all_ problems with forward references. For example, two
typical
situations are:

  T  = TypeVar('T', bound='Factory')

  class Factory:
  def make_copy(self: T) -> T:
  ...

and

  class Vertex(List['Edge']):
  ...
  class Edge:
  ends: Tuple[Vertex, Vertex]

Actually both situations can be resolved with PEP 563 if one puts
`T` after `Factory`, and `Vertex` after `Edge`, the latter is OK, but
the former would be strange. After all, it is OK to pay a _little_ price
for Python being an interpreted language.

There are other situations discussed in
https://github.com/python/typing/issues/400, I don't want to copy all
of them to the PEP, but I think this prior discussion should be referenced
in the PEP.

> This is not a viable strategy since __future__ is not designed to be
> a feature toggle but rather to be a gradual introduction of an upcoming
> breaking change.

But how it was with `from __future__ import division`? What I was proposing
is something similar, just have `from __future__ import annotations` that
will
be default in Python 4. (Although this time it would be a good idea to emit
DeprecationWarning one-two releases before Python 4).

--
Ivan
___
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] PEP 563: Postponed Evaluation of Annotations, first draft

[Ivan Levkivskyi]

In principle, I like this idea, this will save some keystrokes
and will make annotated code more "beautiful". But I am quite worried about
the backwards
compatibility. One possible idea would be to use __future__ import without
a definite
deprecation plan. If people will be fine with using typing.get_type_hints
(btw this is already the preferred way instead of directly accessing
__annotations__,
according to PEP 526 at least) then we could go ahead with deprecation.

Also I really like Yury's idea of dynamic mapping, but it has one downside,
semantics of this will change:

def fun(x: print("Function defined"), y: int) -> None:
...

However I agree functions with side effects in annotations are very rare,
and it would be reasonable to sacrifice this tiny backwards compatibility
to avoid the __future__ import.

--
Ivan
___
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] PEP 562

[Ivan Levkivskyi]

@Anthony
> module.__getattr__ works pretty well for normal access, after being
> imported by another module, but it doesn't properly trigger loading by
> functions defined in the module's own namespace.

The idea of my PEP is to be very simple (both semantically and in terms
of implementation). This is why I don't want to add any complex logic.
People who will want to use __getattr__ for lazy loading still can do this
by importing submodules.

@Nathaniel @INADA
> The main two use cases I know of for this and PEP 549 are lazy imports
> of submodules, and deprecating attributes.

Yes, lazy loading seems to be a popular idea :-)
I will add the simple recipe by Inada to the PEP since it will already work.

@Cody
> I still think the better way
> to solve the custom dir()  would be to change the module __dir__
> method to check if __all__ is defined and use it to generate the
> result if it exists. This seems like a logical enhancement to me,
> and I'm planning on writing a patch to implement this. Whether it
> would be accepted is still an open issue though.

This seems a reasonable rule to me, I can also make this patch if
you will not have time.

@Guido
What do you think about the above idea?

--
Ivan
___
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] PEP 560

[Ivan Levkivskyi]

I have written another short PEP that proposes some minor changes to core
CPython interpreter
for better support of generic types. I will be grateful for comments and
suggestions:

https://www.python.org/dev/peps/pep-0560/

--
Ivan
___
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] PEP 562

[Ivan Levkivskyi]

I have written a short PEP as a complement/alternative to PEP 549.
I will be grateful for comments and suggestions. The PEP should
appear online soon.

--
Ivan

***

PEP: 562
Title: Module __getattr__
Author: Ivan Levkivskyi <levkivs...@gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Sep-2017
Python-Version: 3.7
Post-History: 09-Sep-2017


Abstract


It is proposed to support ``__getattr__`` function defined on modules to
provide basic customization of module attribute access.


Rationale
=

It is sometimes convenient to customize or otherwise have control over
access to module attributes. A typical example is managing deprecation
warnings. Typical workarounds are assigning ``__class__`` of a module object
to a custom subclass of ``types.ModuleType`` or substituting ``sys.modules``
item with a custom wrapper instance. It would be convenient to simplify this
procedure by recognizing ``__getattr__`` defined directly in a module that
would act like a normal ``__getattr__`` method, except that it will be
defined
on module *instances*. For example::

  # lib.py

  from warnings import warn

  deprecated_names = ["old_function", ...]

  def _deprecated_old_function(arg, other):
  ...

  def __getattr__(name):
  if name in deprecated_names:
  warn(f"{name} is deprecated", DeprecationWarning)
  return globals()[f"_deprecated_{name}"]
  raise AttributeError(f"module {__name__} has no attribute {name}")

  # main.py

  from lib import old_function  # Works, but emits the warning

There is a related proposal PEP 549 that proposes to support instance
properties for a similar functionality. The difference is this PEP proposes
a faster and simpler mechanism, but provides more basic customization.
An additional motivation for this proposal is that PEP 484 already defines
the use of module ``__getattr__`` for this purpose in Python stub files,
see [1]_.


Specification
=

The ``__getattr__`` function at the module level should accept one argument
which is a name of an attribute and return the computed value or raise
an ``AttributeError``::

  def __getattr__(name: str) -> Any: ...

This function will be called only if ``name`` is not found in the module
through the normal attribute lookup.

The reference implementation for this PEP can be found in [2]_.


Backwards compatibility and impact on performance
=

This PEP may break code that uses module level (global) name
``__getattr__``.
The performance implications of this PEP are minimal, since ``__getattr__``
is called only for missing attributes.


References
==

.. [1] PEP 484 section about ``__getattr__`` in stub files
   (https://www.python.org/dev/peps/pep-0484/#stub-files)

.. [2] The reference implementation
   (https://github.com/ilevkivskyi/cpython/pull/3/files)


Copyright
=

This document has been placed in the public domain.
___
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] More Metadata for Variable Annotations

[Ivan Levkivskyi]

Hi Bagrat,

Thanks for a detailed proposal! Indeed, some projects might want to have
some additional metadata attached to a variable/argument besides its type.
However, I think it would be more productive to first discuss this on a
more specialized forum like https://github.com/python/typing/issues

Note that similar proposals have been discussed and rejected before, see
for example
https://www.python.org/dev/peps/pep-0484/#what-about-existing-uses-of-annotations
so that you would need to have a strong argument, for example some popular
projects that will benefit from your proposal.

--
Ivan



On 18 August 2017 at 17:09, Bagrat Aznauryan  wrote:

> # Abstract
>
> Before the holly PEP-526 the only option for type hints were comments. And
> before PEP-484 the docstrings were the main place where variable metadata
> would go. That variable metadata would include:
>
> * the type
> * the human-readable description
> * some value constraints (e.g. a range for integer variable)
>
> PEP-526 introduced the awesome syntax sugar, which made the first part of
> the metadata - the type, easily introspectable during the runtime. However,
> if you still need to add the description and the value constraints to the
> variable metadata, you still need to fallback to the docstring option.
>
> The idea is to make it possible to be able to include all of the mentioned
> metadata in the variable annotations.
>
> # Rationale
>
> Having the type specified using the supported annotation syntax and the
> rest of the metadata in the docstrings, adds duplication and complexity for
> further maintenance. Moreover, if you need the docstring-contained metadata
> to be used in the runtime, you need to implement a parser or pick one from
> existing ones which adds another dependency to your application.
>
> The need for the rest of the metadata other than the type, might be proven
> to be common. A typical example is generating the JSON Schema for a class,
> e.g. to be used for OpenAPI definition of your API.
>
> # Possible Solutions
>
> ## A wrapper
>
> The proposal is to introduce a new wrapper (probably a function), that
> will accept the type as the first positional argument and additional
> keyword arguments for metadata. The wrapper will map the keyword arguments
> to the type object as attributes and return it. The code would look like
> this:
>
> ```
> foo: wrapper(
> int,
> description="bar",
> minimum=0,
> maximum=100
> )
> ```
>
> Later, the metadata can be accessed as the annotation attributes, like
> e.g.:
>
> ```
> __annotations__['foo'].description
> ```
>
> ## Annotation as a tuple
>
> This solution does not require any code change in Python, but will force
> other tools change the parsing (e.g. mypy). The proposal is that when the
> annotation is optionally a tuple instance, use the first element as the
> type of the variable, and ignore the rest or treat as additional metadata.
> This will make it possible to add the metadata into a separate dictionary
> as the second element of the annotation tuple. For example:
>
> ```
> foo: (
> int,
> {
> description="bar",
> minimum=0,
> maximum=100
> }
> )
> ```
>
> The annotation will be stored as is, so to access the metadata in the
> runtime, one would need to explicitly access the second item of the
> annotation tuple.
>
> # Summary
>
> This option would help to have a well annotated code which will be
> self-descriptive and provide abilities to generate schemas and other
> definitions (e.g. OpenAPI) automatically and without duplication.
>
> The proposed solutions are definitely not perfect and not the main point
> of this email. The target is to describe the idea and motivation and start
> a discussion.
>
> ___
> 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] namedtuple nit...

[Ivan Levkivskyi]

This error message is the same for types with __slots__, and probably it is
indeed a bit too terse.

--
Ivan



On 27 July 2017 at 18:26, Chris Barker  wrote:

> Since we are talking about namedtuple and implementation, I just noticed:
>
> In [22]: Point = namedtuple('Point', ['x', 'y'])
> In [23]: p = Point(2,3)
>
> In [24]: p.x = 5
> 
> ---
> AttributeErrorTraceback (most recent call last)
>  in ()
> > 1 p.x = 5
> AttributeError: can't set attribute
>
> OK -- that makes sense. but then, if you try:
>
> In [25]: p.z = 5
> 
> ---
> AttributeErrorTraceback (most recent call last)
>  in ()
> > 1 p.z = 5
> AttributeError: 'Point' object has no attribute 'z'
>
> I think this should be a different message -- key here is that you can't
> set a new attribute, not that one doesn't exist. Maybe:
>
> "AttributeError: can't set new attribute"
>
> -CHB
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> 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] Fwd: Consider allowing the use of abstractmethod without metaclasses

[Ivan Levkivskyi]

On 20 July 2017 at 19:51, INADA Naoki <songofaca...@gmail.com> wrote:

> On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi <levkivs...@gmail.com>
> wrote:
> > To be honest, I am not very happy with addition of a new special class.
> > Imagine that the PEP 544 will be accepted (and I hope so).
> > Then we would have, abstract classes, abstract base classes, and
> protocols.
> > I think users will be overwhelmed by having
> > three similar concepts instead of one.
>
> Hmm, couldn't split protocol and ABC?
>
>
Unfortunately no, it was considered and rejected for various reasons (in
particular to provide smooth transition to protocols).


> > I think we still could squeeze a lot of performance from good old ABCs by
> > optimizing various parts and reimplementing some parts in C.
> > In fact, my desire to optimize and rewrite ABCMeta in C is partially due
> to
> > reluctance to add yet another concept of "abstractness".
> >
>
> Even if it's implemented in C, issubclass implementation is much
> complicated
> than normal type.
> I don't want to introduce unnecessary complexity because I'm minimalist.
>
>
This complexity is already there, and attempt to reduce might lead to
actually an increase of complexity.
This is probably the case where I would be with Raymond in terms of
performance vs ease of maintenance.

--
Ivan
___
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] Fwd: Consider allowing the use of abstractmethod without metaclasses

[Ivan Levkivskyi]

To be honest, I am not very happy with addition of a new special class.
Imagine that the PEP 544 will be accepted (and I hope so).
Then we would have, abstract classes, abstract base classes, and protocols.
I think users will be overwhelmed by having
three similar concepts instead of one.

I think we still could squeeze a lot of performance from good old ABCs by
optimizing various parts and reimplementing some parts in C.
In fact, my desire to optimize and rewrite ABCMeta in C is partially due to
reluctance to add yet another concept of "abstractness".

--
Ivan
___
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] namedtuple literals [Was: RE a new namedtuple]

[Ivan Levkivskyi]

Something probably not directly related, but since we started to talk about
syntactic changes...
I think what would be great to eventually have is some form of pattern
matching.
Essentially pattern matching  could be just a "tagged" unpacking protocol.
For example, something like this will simplify a common pattern
with a sequence of if isinstance() branches:

class Single(NamedTuple):
x: int

class Pair(NamedTuple):
x: int
y: int

def func(arg: Union[Single, Pair]) -> int:
whether arg:
Single as a:
return a + 2
Pair as a, b:
return a * b
else:
return 0

The idea is that the expression before ``as`` is evaluated, then if ``arg``
is an instance of the result,
then ``__unpack__`` is called on it. Then the resulting tuple is unpacked
into the names a, b, etc.

I think named tuples could provide the __unpack__, and especially it would
be great for dataclasses
to provide the __unpack__ method. (Maybe we can then call it __data__?)

--
Ivan



On 20 July 2017 at 11:39, Clément Pit-Claudel  wrote:

> On 2017-07-20 11:30, Paul Moore wrote:
> > On 20 July 2017 at 10:15, Clément Pit-Claudel 
> wrote:
> >> On 2017-07-20 11:02, Paul Moore wrote:
>  Also, what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)? I.e.,
>  why does this need to be syntax instead of a library?
> >>>
> >>> Agreed. Now that keyword argument dictionaries retain their order,
> >>> there's no need for new syntax here. In fact, that's one of the key
> >>> motivating reasons for the feature.
> >>
> >> Isn't there a speed aspect?  That is, doesn't the library approach
> require creating (and likely discarding) a dictionary every time a new
> ntuple is created?  The syntax approach wouldn't need to do that.
> >
> > I don't think anyone has suggested that the instance creation time
> > penalty for namedtuple is the issue (it's the initial creation of the
> > class that affects interpreter startup time), so it's not clear that
> > we need to optimise that (at this stage)
>
> Indeed, it's not clear we do.  I was just offering a response to the
> original question, "what's the advantage of (x=1, y=2) over ntuple(x=1,
> y=2)?".
> ___
> 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] a new namedtuple

[Ivan Levkivskyi]

Just FYI, typing.NamedTuple is there for almost a year and already supports
default values, methods, docstrings etc.
Also there is ongoing work towards dataclasses PEP, see
https://github.com/ericvsmith/dataclasses

So that would keep namedtuple API as it is, and focus only on performance
improvements.

--
Ivan



On 18 July 2017 at 02:01, Ethan Furman  wrote:

> Guido has decreed that namedtuple shall be reimplemented with speed in
> mind.
>
> I haven't timed it (I'm hoping somebody will volunteer to be the bench
> mark guru), I'll offer my NamedTuple implementation from my aenum [1]
> library.  It uses the same metaclass techniques as Enum, and offers doc
> string and default value support in the class-based form.
>
> --
> ~Ethan~
>
>
> [1] https://pypi.python.org/pypi/aenum/1.4.5
> ___
> 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] Runtime types vs static types

[Ivan Levkivskyi]

@ Koos Zevenhoven

> and there should at least *exist* a well-defined answer to whether an
object is in 'instance' of a given type. (Not sure if 'instance' should be
world used here)

Let me illustrate why being an "instance" (or any other word) does not
apply well to runtime objects. Consider a list [1, 2, 3], then is it an
"instance" of List[int]? Probably yes. Is it an "instance" of
List[Union[str, int]]? Probably also yes. However, List[int] and
List[Union[str, int]] are mutually incompatible i.e. the latter is not a
subtype of the former and the former is not a subtype of the latter. (This
is due to lists being mutable and therefore invariant in its type variable.)

The next important point is that static type checkers never decide (or at
least I have never seen this) whether a given literal (since there are no
objects before runtime) is an "instance" of a type. Static type checkers
(roughly speaking) verify that the semantics represented by an AST is
consistent with declared/inferred types.

Concerning the above example with [1, 2, 3], static type checkers can infer
List[int] for such literal, or refuse to do so and require an explicit
annotation, or a user can overrule the inference by an explicit annotation.
This decision (whether to use List[int] or any other acceptable type for
this literal) will influence type checking outcome (i.e. are there errors
or not) even _earlier_ in the program, this is something that is not
possible at runtime.

> Ignoring that *types* are also a runtime concept seems dangerous to me.

It is not ignored. Annotations are structured type metadata accessible both
at static and runtime, there is even typing_inspect module on PyPI designed
to provide some runtime introspection of types (it is at an early stage of
development) and some elements of it might end up in typing. Also checking
subtyping between two types (without mixing them with classes) at runtime
is entirely possible, but this is very complicated task with lots of corner
cases, therefore I don't think it will be in stdlib. stdlib was always kept
simple and easy to maintain.

--
Ivan
___
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] Runtime types vs static types

[Ivan Levkivskyi]

Sorry, I was not able to completely digest the OP, but I think there are
some points I need to clarify.

1. Distinction between runtime classes and static types is quite sane and a
simple idea.
A runtime class is something associated with an actual object,
while static type is something associated with an AST node.
Mixing them would be misleading, since they "live in parallel planes".
Although it is true that there is a type that corresponds to every runtime
class.

2. Currently isinstance(obj, List[int]) fails with TypeError, ditto for
issubclass and
for user defined generic classes:

class C(Generic[T]):
...

isinstance(obj, C)  # works, returns only True or False
isinstance(obj, C[int])  # TypeError
issubclass(cls, C)  # works
issubclass(cls, C[int])  # raisesTypeError

3. User defined protocols will by default raise TypeError with isinstance(),
but the user can opt-in (using @runtime decorator) for the same behavior as
normal generics,
this is how typing.Iterable currently works:

class MyIter:
def __iter__(self):
return [42]

isinstance(MyIter(), Iterable)  # True
isinstance(MyIter(), Iterable[int])  # TypeError

class A(Protocol[T]):
x: T
isinstance(obj, A)  # TypeError

@runtime
class B(Protocol[T]):
y: T
isinstance(obj, B)  # True or False depending on whether 'obj' has
attribute 'y'
isinstance(obj, B[int])  # Still TypeError

--
Ivan
___
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] ImportError raised for a circular import

[Ivan Levkivskyi]

On 14 June 2017 at 09:59, Paul Moore  wrote:

> On 13 June 2017 at 23:36, Chris Angelico  wrote:
> > On Wed, Jun 14, 2017 at 8:10 AM, Mahmoud Hashemi 
> wrote:
> >> I didn't interpret the initial email as wanting an error on *all*
> circular
> >> imports. Merely those which are unresolvable. I've definitely helped
> people
> >> diagnose circular imports and wished there was an error that called
> that out
> >> programmatically, even if it's just a string admonition to check for
> >> circular imports, appended to the ImportError message.
> >
> > Oh! That could be interesting. How about a traceback in the import chain?
>
> I have a feeling that mypy might flag circular imports. I've not used
> mypy myself, but I just saw the output from a project where we enabled
> very basic use of mypy (no type hints at all, yet) and saw an error
> reported about a circular import. So with suitable configuration, mypy
> could help here (and may lead to other benefits if you want to use
> more of its capabilities).
>

Mypy doesn't always flag invalid circular imports, there is an old issue
about this,
see https://github.com/python/mypy/issues/61
But yes, one gets many other benefits like static type checking
(including checking the types of things imported in a circular manner).

--
Ivan
___
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] π = math.pi

[Ivan Levkivskyi]

On 3 June 2017 at 21:55, MRAB  wrote:

> [...]
>>
>
> Interestingly, '_' doesn't have that property, although Python does allow
> identifiers to start with it.


Yes, it is special cased:

if (!_PyUnicode_IsXidStart(first) && first != 0x5F /* LOW LINE */)
return 0;

--
Ivan
___
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] π = math.pi

[Ivan Levkivskyi]

On 3 June 2017 at 01:29, Guido van Rossum  wrote:

> Are those characters not considered Unicode letters? Maybe we could add
> their category to the allowed set?
>
>
Yes, they are not considered letters, they are in category Sm.
Unfortunately, +, -, |, and other symbol that clearly should not be in
identifiers are also in this category,
so we cannot add the whole category. It is possible to include particular
ranges, but there should be a discussion
about what exactly can/should be included.

--
Ivan
___
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] π = math.pi

[Ivan Levkivskyi]

On 3 June 2017 at 00:55, Guido van Rossum  wrote:

> [...]
> So, I am still in favor of the rule "only ASCII in the stdlib".
>

But what about the other question? Currently, integral, sum, infinity,
square root etc. Unicode symbols are all prohibited in identifiers.
Is it possible to allow them?

(Btw IPython just supports normal TeX notations like \pi, \lambda etc, so
it is very easy to remember)

--
Ivan
___
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] π = math.pi

[Ivan Levkivskyi]

On 2 June 2017 at 12:17, Giampaolo Rodola'  wrote:

> On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka 
> wrote:
>
>> What you are think about adding Unicode aliases for some mathematic names
>> in the math module? ;-)
>>
>> math.π = math.pi
>> math.τ = math.tau
>> math.Γ = math.gamma
>> math.ℯ = math.e
>>
>> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
>>
>> [...]
> * duplicated aliases might make sense if they add readability; in this
> case they don't unless (maybe) you have a mathematical background. I can
> infer what "math.gamma" stands for but not being a mathematician math.Γ
> makes absolutely zero sense to me.
>
>
There is a significant number of scientific Python programmers (21%
according to PyCharm 2016), so it is not that rare to meet someone who
knows what is Gamma function.
And for many of them π is much more readable than np.pi. Also there is
another problem, confusion between Gamma function and Euler–Mascheroni
constant, the first one is Γ,
the second one is γ (perfectly opposite to PEP 8 capitalization rules :-),
while both of them are frequently denoted as just gamma (in particular
math.gamma follows the PEP8 rules,
but is counter-intuitive for most scientist).

All that said, I agree that these problems are easily solved by a custom
import from. Still there is something in (or related to?) this proposal
I think is worth considering: Can we also allow identifiers like ∫ or √.
This will make many expressions more similar to usual TeX,
plus it will be useful for projects like SymPy.

--
Ivan
___
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] π = math.pi

[Ivan Levkivskyi]

Although it is trivial, I like the idea (except for math.e maybe).
(And it would be cool to be able to also write ∑ = sum, etc.)

--
Ivan


On 1 June 2017 at 08:47, Serhiy Storchaka  wrote:

> What you are think about adding Unicode aliases for some mathematic names
> in the math module? ;-)
>
> math.π = math.pi
> math.τ = math.tau
> math.Γ = math.gamma
> math.ℯ = math.e
>
> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
>
> ___
> 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] PEP 526: why ClassVar instead of ClassAttr?

[Ivan Levkivskyi]

On 18 May 2017 at 17:25, Brett Cannon <br...@python.org> wrote:

> On Wed, May 17, 2017, 09:33 Ivan Levkivskyi, <levkivs...@gmail.com> wrote:
>
>> On 17 May 2017 at 11:03, Steven D'Aprano <st...@pearwood.info> wrote:
>>
>>> On Tue, May 16, 2017 at 10:11:31PM -0700, Guido van Rossum wrote:
>>> > There was another reason too. Many things are "class attributes" e.g.
>>> > methods, descriptors. But only specific things are class *variables*.
>>>
>>> Ah, that's a good reason. I can live with that.
>>>
>>> Thanks for the explanation.
>>>
>>>
>> This was discussed during development of PEP 526:
>> https://github.com/python/typing/issues/258#issuecomment-242263868
>> Maybe we should add a corresponding subsection to "Rejected ideas"?
>>
>
> If it isn't too much trouble to write them I say it's a reasonable idea.
>

Here is a small proposed PR https://github.com/python/peps/pull/261

--
Ivan
___
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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Ivan Levkivskyi]

On 17 May 2017 at 20:09, Sven R. Kunze  wrote:

> Hi Stephan,
>
> On 17.05.2017 08:49, Stephan Houben wrote:
>
>> 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.
>>
>
> Would it make sense to have a 'simpleobject'? Which basically implements a
> NamedTuple constructor but nothing more?
>
> class Foo(simpleobject):
> attribute1: User
> attribute2: Blog
> attribute3: list
>
>
> And if you need more __dunder__ magic, have it provided by some mixins?
>
>
> class Foo(dictlike, tuplelike, simpleobject):
> attribute1: User
> attribute2: Blog
> attribute3: list
>
>  def __my_dunder__(self):
> ...
>

As I understand this is more or less what is proposed, the idea is to write
it into a PEP and consider API/corner cases/implementation/etc.

--
Ivan
___
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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Ivan Levkivskyi]

On 17 May 2017 at 19:40, Juancarlo Añez <apal...@gmail.com> wrote:

>
> On Wed, May 17, 2017 at 12:48 PM, Ivan Levkivskyi <levkivs...@gmail.com>
> wrote:
>
>> class Foo(NamedTuple):
>> """Foo is a very important class and
>> you should totally use it.
>> """
>> bar: int
>> baz: int = 0
>>
>> def grand_total(self):
>> return self.bar + self.baz
>>
>
> Really?!
>
> I didn't know that idiom existed.
>
> It is enough for many use cases, and I was just about to require typing
> and pathlib on my 2.7-compatible projects.
>
>
Unfortunately, this works _only_ in Python 3.6+.

--
Ivan
___
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] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Ivan Levkivskyi]

On 17 May 2017 at 18:38, Stephan Houben  wrote:

> Hi Sven,
>
> > But even given that (and I am only speaking for my team), I haven't even
> > seen a use-case for namedtuples in a year. Every time we considered it,
> > people said: "please make it its own class for documentary purposes; this
> > thing will tend to grow faster than we can imagine".
>
> Using namedtuple doesn't stop the class from being its "own class".
> Typical use case:
>
>  class Foo(namedtuple("Foo", "bar "baz"), FooBase):
>   "Foo is a very important class and you should totally use it."""
>
>def grand_total(self):
> return self.bar + self.baz
>


And the right (modern) way to do this is

from typing import NamedTuple

class Foo(NamedTuple):
"""Foo is a very important class and
you should totally use it.
"""
bar: int
baz: int = 0

def grand_total(self):
return self.bar + self.baz

typing.NamedTuple supports docstrings, user-defined methods, and default
values.

--
Ivan
___
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] Optional parameters without default value

[Ivan Levkivskyi]

On 2 March 2017 at 13:20, Paul Moore  wrote:

> On 2 March 2017 at 11:31, Stephan Houben  wrote:
> > NoDefault would be special syntax so that this would be disallowed:
> >
> > f(NoDefault)
>
> [...]
>
> So I guess I'm +0.5 on the proposed "positional only parameters"
> syntax, and -1 on any form of new language-defined sentinel value.
>
>
This is also my opinion.

--
Ivan
___
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] Optional parameters without default value

[Ivan Levkivskyi]

On 2 March 2017 at 09:36, M.-A. Lemburg  wrote:

> On 02.03.2017 09:03, Serhiy Storchaka wrote:
> > Function implemented in Python can have optional parameters with default
> [...]
>
Why a new syntax ? Can't we just have a pre-defined sentinel
> singleton NoDefault and use that throughout the code (and also
> special case it in argument parsing/handling)?
>

I think for the sane reason that we didn't add Undefined to PEP 484 and PEP
526:
Having "another kind of None" will cause code everywhere to expect it.
(Plus Guido didn't like it)

--
Ivan
___
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] Expose a child factory using MappingProxyType in builtins

[Ivan Levkivskyi]

On 28 February 2017 at 23:19, Victor Stinner 
wrote:

> 2017-02-28 13:17 GMT+01:00 Michel Desmoulin :
> > We have the immutable frozenset for sets and and tuples for lists.
> >
> > But we also have something to manipulate dict as immutable
> datastructures:
>
> ... Sorry, I don't understand your proposition.
>

My interpretation of the idea is to reconsider
https://www.python.org/dev/peps/pep-0416/
but put frozendict in collections, not in builtins.

MappingProxyType could be a possible implementation
(plus copying in constructor and hashing, as proposed above by Matt),
but not necessarily.

--
Ivan
___
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] List indexing multiple elements

[Ivan Levkivskyi]

On 20 February 2017 at 22:05, Jonathan Goble  wrote:

> On Mon, Feb 20, 2017 at 3:55 PM Ryan Gonzalez  wrote:
>
>> - Right now, a[b,c] is already valid syntax, since it's just indexing a
>> with the tuple (b, c). The proposal is to make this a specialization in the
>> grammar, and also allow stuff like a[b:c, d:e] (like
>> `a.__getitem__(slice(b, c), slice(d, e))`).
>>
>
> The syntax/grammar already permits slices to be used in this fashion:
>

Moreover, this syntax is already extensively used by numpy and means
something different - multidimensional slicing.
Having a different semantics for lists would be therefore confusing.

--
Ivan
___
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] Built-in function to run coroutines

[Ivan Levkivskyi]

Hi,

async/await syntax is a very nice recent feature, but there is something
that I miss for coroutines defined with async def, as compared to
generators. Coroutines represent an interesting mental model that goes
beyond only asynchronous IO, so that I play with them in REPL often. But
there is no built-in function to actually run a coroutine, so that
typically I use something like:

>>> def run(coro):
... try:
... coro.send(None)
... except StopIteration as e:
... return e.value

>>> async def f():
... return 42

>>> run(f())
42

There is a simple yet useful function for interactive play with generators
- ``next``, but not for coroutines. There is an option to do:

>>> import asyncio
>>> loop = asyncio.get_event_loop()
>>> loop.run_until_complete(f())
42

But this feels a bit redundant for an interactive play. I would propose to
add something like an above described ``run`` function to built-ins.

Yes, I know, there is a very high bar for adding a built-in function, but I
believe such a function will help to promote async/await to a wider
community (especially to novices).

--
Ivan
___
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] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

[Ivan Levkivskyi]

On 16 October 2016 at 06:47, Chris Angelico  wrote:

> On Sun, Oct 16, 2016 at 3:44 PM, Greg Ewing 
> wrote:
> > Steven D'Aprano wrote:
> >
> >> This thread is a huge, multi-day proof that people do not agree that
> this
> >> is a "reasonable" interpretation.
> >
> >
> > So far I've seen one very vocal person who disgrees, and
> > maybe one other who isn't sure.
> >
>
> And what you're NOT seeing is a whole lot of people (myself included)
> who have mostly glazed over, unsure what is and isn't reasonable, and
> not clear enough on either side of the debate to weigh in. (Or not
> even clear what the two sides are.)
>
>
+1

There are lots of arguments of whether the new syntax is readable or not
etc.,
but not so many arguments why we need this and what kind of problems it
would solve.

What I have learned from this megathread is that the syntax [*foo for foo
in bar]
is proposed as a replacement for a one-liner itertools.chain(*[foo for foo
in bar]).
I do not have any strong opinion on this, because I simply do not use
such constructs frequently (if ever).

--
Ivan
___
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] Improve error message when missing 'self' in method definition

[Ivan Levkivskyi]

On 5 October 2016 at 20:55, Yury Selivanov  wrote:

>
> Speaking of, I'm not much of a C hacker, and messing with CPython internals
>> is a little daunting. If anyone wants to take this on, you have my
>> blessing. I also may take a shot at implementing this idea in the next
>> couple weeks when I have some time.
>>
>
> It would help if you could create an issue and write exhaustive unittests
> (or at least specifying how exactly the patch should work for all corner
> cases).  Someone with the knowledge of CPython internals will later add the
> missing C code to the patch.
>
> Yury
>
>
I agree with Yury here. There are corner cases (like what to do with
classmethods etc). If behaviour for all of them are specified, it would be
quite straightforward to implement this.

--
Ivan
___
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] Delay evaluation of annotations

[Ivan Levkivskyi]

On 22 September 2016 at 22:02, אלעזר  wrote:

> On Thu, Sep 22, 2016 at 10:58 PM David Mertz  wrote:
>
>> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר  wrote:
>>
>>> I think we're talking about different things here. I just referred to
>>> the common need to use the name of the current class in type annotation
>>>
>>> class A:
>>> def add(self, other: A) -> A: ...
>>>
>>
>> Yeah, I find the need for using the string "A" here a wart. Rather than
>> change the entire semantics of annotations, it feels like a placeholder for
>> this meaning would be better.  E.g.:
>>
>> class A:
>> def __add__(self, other: CLS) -> CLS: ...
>>
>> A static checker could do the magic of recognizing that special name
>> easily enough (no harder than recognizing the quoted string).  At runtime
>> 'CLS' could either just be a singleton with no other behavior... or perhaps
>> it could be some sort of magic introspection object.  It's more verbose,
>> but you can also spell it now as:
>>
>> class A:
>> def __add__(self, other: type(self)) -> type(self): ...
>>
>> That's a little ugly, but it expresses the semantics we want.
>>
>
Concerning the __add__ method, I think a more typical type for it is

T = TypeVar('T', bound='A')

class A:
def __add__(self: T, other: T) -> T: ...

There is a plan to support this in one of next releases of mypy.

In general I think it is a bit early to judge what would be the best
solution for forward references.
(there are related issues like performance drop etc). More evidence is
needed to decide a way forward.

--
Ivan
___
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] Generics Syntax

[Ivan Levkivskyi]

On 15 September 2016 at 11:21, אלעזר  wrote:

> This suggestion is so obvious that it's likely has been discussed, but I
> can't find any reference (It's not what PEP-3124 talks about).
>
>
You might want to read this tread
https://github.com/python/typing/issues/211 and another tread mentioned
there at the start.
In short, this idea has been discussed, but nobody had seen it as good
enough to sacrifice his time for implementing the changes.

--
Ivan
___
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] Fwd: Null coalescing operator

[Ivan Levkivskyi]

On 12 September 2016 at 09:05, Michel Desmoulin 
wrote:

> In the form of:
>
> val = do_thing() except ThingError: "default"
>
> [...]

>
> But it also can deal with many common operations in Python without the
> need to add more operators or variants:
>
> val = my_list[0] except IndexError: "default"
>
> val = iterable[0] except TypeError: next(iter(iterable))
>
> val = int(param) except ValueError: man.nan
>

 I like this idea, I would propose a (maybe crazy) addition to it. What
about a special exception NoneError, that will catch TypeError,
AttributeError etc. but only when it was caused by None(),
None.attr, None[1], etc. With this one can write:

x = a.b()[0] except NoneError: 'default'

without a risk of catching other (unrelated) exceptions.

--
Ivan
___
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] Typecheckers: there can be only one

[Ivan Levkivskyi]

On 8 September 2016 at 00:00, Paul Moore  wrote:


> > Type annotations are code, not tests.
>
> Not in Python they aren't.
>

Well, to a certain extent. One can try something like this in REPL:

from typing import get_type_hints
import __main__

s: str

class C:
x: int

get_type_hints(C)
get_type_hints(__main__)

Although please remember that the PEP is still provisional and
implementation details may change.

--
Ivan
___
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] SI scale factors in Python

[Ivan Levkivskyi]

On 26 August 2016 at 18:35, Steven D'Aprano  wrote:
> I think that units are orthogonal to types: I can have a float of unit
> "gram" and a Fraction of unit "gram", and they shouldn't necessarily be
> treated as the same type.

I think you are mixing here what I sometimes call classes (i.e. runtime
implementation)
and types (i.e., static "interface" declaration). In this terms I think
units are types.
But probably it is a more philosophical question and could be a matter of
taste.

On 27 August 2016 at 15:04, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> def power(potential, current):
> return WattType(float(Volt)*float(Ampere))

One don't need to call float on NewTypes derived from it, they will be cast
"automatically", so that:

def power(I, V):
return WattType(I*V)

should be sufficient. Concerning the speed vs. flexibility issue, one could
use stub files:

# content of units.py

def WattType(x): return x
#etc.

# contents of units.pyi

class WattType:
def __init__(self, x: float) -> None:
...
def __mul__(self, other: float) -> WattType:
# over 9000 of complicated overloads and stuff

In such way units will be very fast at runtime but will be thoroughly
checked by static type checkers.

As I understand there are two separate parts of the proposal:

1) suffixes like micro, kilo, etc. -- but Guido does not like this idea yet
2) physical units -- this part I think could be 99% percent solved by PEP
484 and PEP 526
(it is not 100% because this will require dependent types).

--
Ivan

On 27 August 2016 at 22:22, Chris Angelico  wrote:

> On Sun, Aug 28, 2016 at 4:25 AM, Steven D'Aprano 
> wrote:
> >
> > Sympy (apparently) doesn't warn you if your units are incompatible, it
> > just treats them as separate terms in an expression:
> >
> > py> 2*m + 3*K
> > 3*K + 2*m
> >
> > which probably makes sense from the point of view of a computer algebra
> > system (adding two metres and three degrees Kelvin is no weirder than
> > adding x and y). But from a unit conversion point of view, I think
> > sympy is the wrong solution.
>
> As a generic tool, I would say this is correct. It keeps things simple
> and straight-forward. Worst case, you see a strange result at the end,
> rather than getting an instant exception; in fact, it's very similar
> to NaN, in that some operations might cancel out the "error" status.
>
> ChrisA
> ___
> 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] SI scale factors in Python

[Ivan Levkivskyi]

On 26 August 2016 at 14:49, Ivan Levkivskyi <levkivs...@gmail.com> wrote:

> On 26 August 2016 at 13:01, Steven D'Aprano <st...@pearwood.info> wrote:
>
>> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
>> > On 8/25/16, Ken Kundert <python-id...@shalmirane.com> wrote:
>> >
>> > [...]
>> >
>> > > Just allowing the units to be present, even it not
>> > >
>> > > retained, is a big advantage because it can bring a great deal of
>> clarity to
>> > > the
>> > > meaning of the number. For example, even if the language does not
>> flag an
>> > > error
>> > > when a user writes:
>> > >
>> > > vdiff = 1mV - 30uA
>> >
>> > It reminds me: "Metric mishap caused loss of NASA's Mars Climate
>> > orbiter. It could be nice to have language support helping to avoid
>> > something similar.
>>
>
> [snip]
>
>
>> Take v = s/t (velocity equals distance over time). If I write v = s
>> because it is implicitly understood that the time t is "one":
>>
>> s = 100 miles
>> v = s
>>
>> Should v be understood as 100 miles per hour or 100 miles per second or
>> 100 miles per year? That sort of ambiguity doesn't come up in circuit
>> design, but it is common elsewhere.
>>
>
> If one writes this as
>
> from units import m, s, miles
>
> s = miles(100)
> v: m/s = s
>

Sorry for a name collision in this example. It should read:

dist = miles(100)
vel: m/s = dist

--
Ivan
___
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] SI scale factors in Python

[Ivan Levkivskyi]

On 26 August 2016 at 13:01, Steven D'Aprano  wrote:

> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> > On 8/25/16, Ken Kundert  wrote:
> >
> > [...]
> >
> > > Just allowing the units to be present, even it not
> > >
> > > retained, is a big advantage because it can bring a great deal of
> clarity to
> > > the
> > > meaning of the number. For example, even if the language does not flag
> an
> > > error
> > > when a user writes:
> > >
> > > vdiff = 1mV - 30uA
> >
> > It reminds me: "Metric mishap caused loss of NASA's Mars Climate
> > orbiter. It could be nice to have language support helping to avoid
> > something similar.
>

[snip]


> Take v = s/t (velocity equals distance over time). If I write v = s
> because it is implicitly understood that the time t is "one":
>
> s = 100 miles
> v = s
>
> Should v be understood as 100 miles per hour or 100 miles per second or
> 100 miles per year? That sort of ambiguity doesn't come up in circuit
> design, but it is common elsewhere.
>

If one writes this as

from units import m, s, miles

s = miles(100)
v: m/s = s

This could be flagged as an error by a static type checker.

Let me add some clarifications here:
1. By defining __mul__ and __truediv__ on m, s, and other units one can
achieve
the desirable semantics

2. Arbitrary (reasonable) unit can be described by a tuple of 7 rational
numbers
(powers of basic SI units, m/s will be e.g. (1, -1, 0, 0, 0, 0, 0)), if one
wants also
non SI units, then there will be one more float number in the tuple.

3. It is impossible to write down all the possible overloads for operations
on units,
e.g. 1 m / 1 s should be 1 m/s, 1 m/s / 1 s should be 1 m/s**2,
and so on to infinity. Only finite number of overloads can be described
with PEP 484 type hints.

4. It is very easy to specify all overloads with very basic dependent types,
unit will depend on the above mentioned tuple, and multiplication should be
overloaded
like this (I write three numbers instead of seven for simplicity):

class Unit(Dependent[k,l,m]):
def __mul__(self, other: Unit[ko, lo, mo]) -> Unit[k+ko, l+lo, m+mo]:
...

5. Currently neither "mainstream" python type checkers nor PEP 484 support
dependent types.

6. For those who are not familiar with dependent types, this concept is
very similar to generics.
Generic type (e.g. List) is like a "function" that takes a concrete type
(e.g. int) and "returns" another
concrete type (e.g. List[int], lists of integers). Dependent types do the
same, but they allowed to
also receive values, not only types as "arguments". The most popular example
is matrices of fixed size n by m: Mat[n, m]. The matrix multiplication then
could be overloaded as

class Mat(Dependent[n, m]):
def __matmul__(self, other: Mat[m, k]) -> Mat[n, k]:
...

7. I like the formulation by Nick, if e.g. the library circuit_units
defines sufficiently many overloads,
then it will safely cover 99.9% of use cases *without* dependent types. (An
operation
for which type checker does not find an overload will be flagged as error,
although the operation might be correct).

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