On 25 September 2016 at 11:55, אלעזר wrote:
> I promised not to bother you, but I really can't. So here's what I felt I
> have to say. This email is quite long. Please do not feel obliged to read
> it. You might find some things you'll want to bash at the end though :)
>
> Short-ish version:
>
> 1
Thanks for the references. I will read them.
In general, I am against magic in code. I am for magic in specification,
with appropriate hints (e.g. the explicit name in the decorator, as pointed
to me by Chris) and with taste. The most important part about specification
is being naturally understoo
I promised not to bother you, but I really can't. So here's what I felt I
have to say. This email is quite long. Please do not feel obliged to read
it. You might find some things you'll want to bash at the end though :)
Short-ish version:
1. Please consider disallowing the use of side effects of
Nick Coghlan writes:
> This code works as a doctest today:
>
> >>> def func(a: "Expected output"):
> ... pass
> ...
> >>> print(func.__annotations__["a"])
> Expected output
>
> Any change that breaks that currently valid doctest is necessarily a
> compatibility
Thank you Stephen. You have phrased my proposal better than I did.
As per the using quoted strings, the problems are:
1. The well-formedness of the expression is not checked by the compiler.
2. It is not naturally supported by syntax highlighters and IDEs. They can
be made to support it, but most
> 1. Please consider disallowing the use of side effects of any kind in
annotations, in that it is not promised when it will happen, if at all. So
that a change 3 years from now will be somewhat less likely to break
things. Please consider doing this for version 3.6; it is feature-frozen,
but this
On Sep 25, 2016 10:59 AM, "אלעזר" wrote:
> 2. It is not naturally supported by syntax highlighters and IDEs. They
can be made to support it, but most will not.
This is a complete red herring. Having a highlight rule of "apply
highlights in string annotations" is straightforward in modern editors.
On Sun, Sep 25, 2016 at 9:28 PM David Mertz wrote:
> On Sep 25, 2016 10:59 AM, "אלעזר" wrote:
> > 2. It is not naturally supported by syntax highlighters and IDEs. They
> can be made to support it, but most will not.
>
> This is a complete red herring. Having a highlight rule of "apply
> highlig
On Mon, Sep 26, 2016 at 4:54 AM, אלעזר wrote:
> IDEs are more important. Renaming facilities do over-renaming or
> under-renaming because of this need to rename inside some strings, but not
> inside others. Similarly code search facilities, and warnings from IDEs
> about inlining variables. I have
אלעזר writes:
> But nobody (yet) claimed it to be a reasonable example of code we
> don't want to break.
"Reasonable example" is not the standard. The ideal is that
*nobody*'s code breaks unless it's necessary to to fix a bug. The
current implementation conforms to the specification[1], and t
On Sep 25, 2016 11:54 AM, "אלעזר" wrote:
> Not that I think it's a killer argument, but why a red herring? Quick
search does not find such an explicit option in Gedit, PyDev and yes,
Notepad++.exe. It is not a common or default option.
This would equally be an argument against any syntax change,
On Sun, Sep 25, 2016 at 10:14 PM David Mertz wrote:
> All of those might promote changes in tools. But the tools exist to aid
> working with a language, not the other way around.
>
> I can't think of a way to know that this string is code and that string is
an actual string. And figuring out mean
On Sun, Sep 25, 2016 at 01:55:09AM +, אלעזר wrote:
> 1. Please consider disallowing the use of side effects of any kind in
> annotations,
That is *simply not possible* in Python.
Actually, no, that's not quite correct. One way to prohibit side-effects
would be to make all annotations strin
On 26 September 2016 at 03:42, Stephen J. Turnbull
wrote:
> Nick Coghlan writes:
>
> > This code works as a doctest today:
> >
> > >>> def func(a: "Expected output"):
> > ... pass
> > ...
> > >>> print(func.__annotations__["a"])
> > Expected output
> >
> > Any chan
14 matches
Mail list logo
