[Python-Dev] Re: typing: how to use names in result-tuples?

[Christian Tismer]

Hi Guido,

If a C++ function already has a return value, plus some primitive
pointer variables that need to be moved into the result in Python,
then we have the case with a first, single unnamed field.
Only one such field can exist.

I'm not sure if that case exists in the ~25000 Qt5 functions, but in
that case, I think to give that single field the name "unnamed"
or maybe better "result".

Thank you very much for pointing me to that example!

Cheers -- Chris


On 08.08.19 06:41, Guido van Rossum wrote:
> Alas, we didn't think of struct sequences when we designed PEP 484. It
> seems they are a hybrid of Tuple and NamedTuple; both of these are
> currently special-cased in mypy in ways that cannot easily be combined.
> 
> Do you really need anonymous fields?
> 
> I see an example in typeshed/stdlib/3/os/__init__.pyi (in
> github.com/python/typeshed ), for
> stat_result. It defines names for all the fields, plus a __getitem__()
> method that indicates that indexing returns an int. This doesn't help if
> anonymous fields could have different types, not does it teach the type
> checker about the number of anonymous fields.
> 
> --Guido
> 
> On Wed, Aug 7, 2019 at 1:51 AM Christian Tismer  > wrote:
> 
> Hi all,
> 
> Ok, I am about to implement generation of such structures
> automatically using the struct sequence concept.
> 
> 
> One more question:
> --
> 
> Struct sequences are not yet members of the typing types.
> I would like to add that, because a major use case is also to
> show nice .pyi files with all the functions and types.
> 
> * namedtuple has made the transition to NamedTuple
> 
> * What would I need to do that for StructSequence as well?
> 
> Things get also a bit more complicated since struct sequence
> objects can contain unnamed fields.
> 
> Any advice would be appreciated, I am no typing expert (yet :-)
> 
> cheers -- Chris
> 
> 
> On 30.07.19 17:10, Guido van Rossum wrote:
> > I think I have to agree with Petr. Define explicit type names.
> >
> > On Tue, Jul 30, 2019 at 2:45 AM Paul Moore  
> > >> wrote:
> >
> >     On Tue, 30 Jul 2019 at 09:33, Christian Tismer
> mailto:tis...@stackless.com>
> >     >>
> wrote:
> >     > >>> typing.NamedTuple("__f", x=int, y=int)
> >     > 
> >     > >>> typing.NamedTuple("__f", x=int, y=int) is
> typing.NamedTuple("__f",
> >     > x=int, y=int)
> >     > False
> >
> >     This appears to go right back to collections.namedtuple:
> >
> >     >>> from collections import namedtuple
> >     >>> n1 = namedtuple('f', ['a', 'b', 'c'])
> >     >>> n2 = namedtuple('f', ['a', 'b', 'c'])
> >     >>> n1 is n2
> >     False
> >
> >     I found that surprising, as I expected the named tuple type to be
> >     cached based on the declared name 'f'. But it's been that way
> forever
> >     so obviously my intuition here is wrong. But maybe it would be
> useful
> >     for this case if there *was* a way to base named tuple
> identity off
> >     the name/fields? It could be as simple as caching the results:
> >
> >     >>> from functools import lru_cache
> >     >>> cached_namedtuple = lru_cache(None)(namedtuple)
> >     >>> n1 = cached_namedtuple('f', ('a', 'b', 'c')) # A tuple rather
> >     than a list of field names, as lists aren't hashable
> >     >>> n2 = cached_namedtuple('f', ('a', 'b', 'c'))
> >     >>> n1 is n2
> >     True
> >
> >     Paul
> >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido 
> )
> > /Pronouns: he/him/his //(why is my pronoun here?)/
> >
> 
> 
> >
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> 
> > To unsubscribe send an email to python-dev-le...@python.org
> 
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> 
> https://mail.python.org/archives/list/python-dev@python.org/message/GIFRTFWPEGKZ33PTW63YXKGXHHAQJ35I/
> >
> 
> 
> -- 
> Christian Tismer             :^)   tis...@stackless.com
> 
> Software Consulting          :     http://www.stackless.com/
> Karl-Liebknecht-Str. 121     :     https://github.com/PySide
> 14482 Potsdam                :     GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> 
> 
> 
> -- 
> --Guido van Rossum

[Python-Dev] Re: What to do about invalid escape sequences

[Dima Tisnek]

I feel this is one of the cases, where we're expecting early adopters
to proactively post pull requests against affected libraries. Failing
that opening issues against affected libraries.

I was ready to do just that, but alas didn't even have to!
Matt's analysis shows that it's now too hard.

What was hard for me were the rules. In fact, not being up to date, I
couldn't even find the PEP that specified the change.

What the Python devs could do is to guide users on how to update existing code.
Something like python3.8 -c 'print(repr("\b\l\a\h"))' but with sensible output.
And instruction for those who support both py3 and py3 from the same codebase.

I could hope for a feature in psf/black, but maybe that's not for everyone.
Just my 2c :)

On Mon, 5 Aug 2019 at 13:30,  wrote:
>
> We should revisit what we want to do (if anything) about invalid escape 
> sequences.
>
> For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which 
> is visible by default.  The intention is to make it a SyntaxError in Python 
> 3.9.
>
> This once seemed like a reasonable and innocuous idea to me; however, I've 
> been using the 3.8 beta heavily for a month and no longer think it is a good 
> idea.  The warning crops up frequently, often due to third-party packages 
> (such as docutils and bottle) that users can't easily do anything about.  And 
> during live demos and student workshops, it is especially distracting.
>
> I now think our cure is worse than the disease.  If code currently has a 
> non-raw string with '\latex', do we really need Python to yelp about it (for 
> 3.8) or reject it entirely (for 3.9)?   If someone can't remember exactly 
> which special characters need to be escaped, do we really need to stop them 
> in their tracks during a data analysis session?  Do we really need to reject 
> ASCII art in docstrings: ` \---> special case'?
>
> IIRC, the original problem to be solved was false positives rather than false 
> negatives:  filename = '..\training\new_memo.doc'.  The warnings and errors 
> don't do (and likely can't do) anything about this.
>
> If Python 3.8 goes out as-is, we may be punching our users in the nose and 
> getting almost no gain from it.  ISTM this is a job best left for linters.  
> For a very long time, Python has been accepting the likes of 'more \latex 
> markup' and has been silently converting it to 'more \\latex markup'.  I now 
> think it should remain that way.  This issue in the 3.8 beta releases has 
> been an almost daily annoyance for me and my customers. Depending on how you 
> use Python, this may not affect you or it may arise multiple times per day.
>
>
> Raymond
>
> P.S.  Before responding, it would be a useful exercise to think for a moment 
> about whether you remember exactly which characters must be escaped or 
> whether you habitually put in an extra backslash when you aren't sure.  Then 
> see:  https://bugs.python.org/issue32912
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/ZX2JLOZDOXWVBQLKE4UCVTU5JABPQSLB/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/F2ZIHAT2EIWM5IOJFP2THGUOSFZJ3Z2W/

[Python-Dev] Re: What to do about invalid escape sequences

[Dima Tisnek]

These two ought to be converted to raw strings, shouldn't they?

On Thu, 8 Aug 2019 at 08:04,  wrote:
>
> For me, these warnings are continuing to arise almost daily.  See two recent 
> examples below.  In both cases, the code previously had always worked without 
> complaint.
>
> - Example from yesterday's class 
>
> ''' How old-style formatting works with positional placeholders
>
> print('The answer is %d today, but was %d yesterday' % (new, old))
>  \o
>   \o
> '''
>
> SyntaxWarning: invalid escape sequence \-
>
> - Example from today's class 
>
> # Cut and pasted from:
> # https://en.wikipedia.org/wiki/VCard#vCard_2.1
> vcard = '''
> BEGIN:VCARD
> VERSION:2.1
> N:Gump;Forrest;;Mr.
> FN:Forrest Gump
> ORG:Bubba Gump Shrimp Co.
> TITLE:Shrimp Man
> PHOTO;GIF:http://www.example.com/dir_photos/my_photo.gif
> TEL;WORK;VOICE:(111) 555-1212
> TEL;HOME;VOICE:(404) 555-1212
> ADR;WORK;PREF:;;100 Waters Edge;Baytown;LA;30314;United States of America
> LABEL;WORK;PREF;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:100 Waters Edge=0D=
>  =0ABaytown\, LA 30314=0D=0AUnited States of America
> ADR;HOME:;;42 Plantation St.;Baytown;LA;30314;United States of America
> LABEL;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:42 Plantation St.=0D=0A=
>  Baytown, LA 30314=0D=0AUnited States of America
> EMAIL:forrestg...@example.com
> REV:20080424T195243Z
> END:VCARD
> '''
>
> SyntaxWarning: invalid escape sequence \,
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/OYGRL5AWSJZ34MDLGIFTWJXQPLNSK23S/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P5YTWGKVSR5EFTHHUKOXW32CBEUYIRW2/

[Python-Dev] Re: What to do about invalid escape sequences

[Christian Tismer]

Hey friends,

This is IMHO a great idea.
If a package claims to be Python 3.8 compatible, then it has to
be correct concerning invalid escapes.

A new pip version could perhaps even refuse packages with such
literals when it claims to be supporting Python 3.8 .

But how can it actually happen that a pre-3.8 package gets installed
when you install Python 3.8? Does pip allow installation without
a section that defines the allowed versions?

Ok, maybe packages are claimed for Python 3.8 and not further checked.

But let's assume the third-party things that Raymond sees do _not_
come from pip, but elsewhere. Pre-existing stuff that is somehow copied
into the newer Python version? Sure, quite possible!

But then it is quite likely that those third-party things still
have their creation date from pre-3.8 time.
What about the simple heuristic that a Python module with a creation
date earlier than xxx does simply not issue the annoying warning?

Maybe that already cures the disease in enough cases?

just a wild idea - \leave \old \code \untouched -- ciao - \Chris


On 06.08.19 18:59, Neil Schemenauer wrote:
> 
> Making it an error so soon would be mistake, IMHO.  That will break
> currently working code for small benefit.  When Python was a young
> language with a few thousand users, it was easier to make these
> kinds of changes.  Now, we should be much more conservative and give
> people a long time and a lot of warning.  Ideally, we should provide
> tools to fix code if possible.
> 
> Could PyPI and pip gain the ability to warn and even fix these
> issues?  Having a warning from pip at install time could be better
> than a warning at import time.  If linting was built into PyPI, we
> could even do a census to see how many packages would be affected by
> turning it into an error.
> 
> On 2019-08-05, raymond.hettin...@gmail.com wrote:
>> P.S. In the world of C compilers, I suspect that if the relatively
>> new compiler warnings were treated as errors, the breakage would
>> be widespread. Presumably that's why they haven't gone down this
>> road.
> 
> The comparision with C compilers is relevant.  C and C++ represent a
> fairly extreme position on not breaking working code.   E.g. K & R
> style functional declarations were supported for decades.  I don't
> think we need to go quite that far but also one or two releases is
> not enough time.
> 
> Regards,
> 
>   Neil
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/V2EDFDJGXRIDMKJU3FKIWC2NDLMUZA2Y/
> 


-- 
Christian Tismer :^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XVJCYXDZ7VPMMCTP2BPNAJ3OO7S4II4V/

[Python-Dev] Re: typing: how to use names in result-tuples?

[Ronald Oussoren via Python-Dev]

Chrisian,

How would these namedtuple/structseq values be used? I have a similar design 
with PyObjC: pass-by-reference “return” values are returned in a tuple, e.g.:

void getpoint(pointclass* v, int* x, int *y)=>def get point(v: 
pointless) -> (int, int)
BOOL getvalue(someclass* v, int* val)  =>def getvalue(v: someclass) 
-> (bool, int)

I rarely, if ever, see code that actually stores the return tuple as-is. The 
return tuple is just deconstructed immediately, like “x, y = 
getpoint(mypoint)”. 

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

> On 8 Aug 2019, at 10:42, Christian Tismer  wrote:
> 
> Hi Guido,
> 
> If a C++ function already has a return value, plus some primitive
> pointer variables that need to be moved into the result in Python,
> then we have the case with a first, single unnamed field.
> Only one such field can exist.
> 
> I'm not sure if that case exists in the ~25000 Qt5 functions, but in
> that case, I think to give that single field the name "unnamed"
> or maybe better "result".
> 
> Thank you very much for pointing me to that example!
> 
> Cheers -- Chris
> 
> 
> On 08.08.19 06:41, Guido van Rossum wrote:
>> Alas, we didn't think of struct sequences when we designed PEP 484. It
>> seems they are a hybrid of Tuple and NamedTuple; both of these are
>> currently special-cased in mypy in ways that cannot easily be combined.
>> 
>> Do you really need anonymous fields?
>> 
>> I see an example in typeshed/stdlib/3/os/__init__.pyi (in
>> github.com/python/typeshed ), for
>> stat_result. It defines names for all the fields, plus a __getitem__()
>> method that indicates that indexing returns an int. This doesn't help if
>> anonymous fields could have different types, not does it teach the type
>> checker about the number of anonymous fields.
>> 
>> --Guido
>> 
>> On Wed, Aug 7, 2019 at 1:51 AM Christian Tismer > > wrote:
>> 
>>Hi all,
>> 
>>Ok, I am about to implement generation of such structures
>>automatically using the struct sequence concept.
>> 
>> 
>>One more question:
>>--
>> 
>>Struct sequences are not yet members of the typing types.
>>I would like to add that, because a major use case is also to
>>show nice .pyi files with all the functions and types.
>> 
>>* namedtuple has made the transition to NamedTuple
>> 
>>* What would I need to do that for StructSequence as well?
>> 
>>Things get also a bit more complicated since struct sequence
>>objects can contain unnamed fields.
>> 
>>Any advice would be appreciated, I am no typing expert (yet :-)
>> 
>>cheers -- Chris
>> 
>> 
>>On 30.07.19 17:10, Guido van Rossum wrote:
>>> I think I have to agree with Petr. Define explicit type names.
>>> 
>>> On Tue, Jul 30, 2019 at 2:45 AM Paul Moore >
>>> >> wrote:
>>> 
>>>  On Tue, 30 Jul 2019 at 09:33, Christian Tismer
>>mailto:tis...@stackless.com>
>>>  >>
>>wrote:
>>>  > >>> typing.NamedTuple("__f", x=int, y=int)
>>>  > 
>>>  > >>> typing.NamedTuple("__f", x=int, y=int) is
>>typing.NamedTuple("__f",
>>>  > x=int, y=int)
>>>  > False
>>> 
>>>  This appears to go right back to collections.namedtuple:
>>> 
>>>  >>> from collections import namedtuple
>>>  >>> n1 = namedtuple('f', ['a', 'b', 'c'])
>>>  >>> n2 = namedtuple('f', ['a', 'b', 'c'])
>>>  >>> n1 is n2
>>>  False
>>> 
>>>  I found that surprising, as I expected the named tuple type to be
>>>  cached based on the declared name 'f'. But it's been that way
>>forever
>>>  so obviously my intuition here is wrong. But maybe it would be
>>useful
>>>  for this case if there *was* a way to base named tuple
>>identity off
>>>  the name/fields? It could be as simple as caching the results:
>>> 
>>>  >>> from functools import lru_cache
>>>  >>> cached_namedtuple = lru_cache(None)(namedtuple)
>>>  >>> n1 = cached_namedtuple('f', ('a', 'b', 'c')) # A tuple rather
>>>  than a list of field names, as lists aren't hashable
>>>  >>> n2 = cached_namedtuple('f', ('a', 'b', 'c'))
>>>  >>> n1 is n2
>>>  True
>>> 
>>>  Paul
>>> 
>>> 
>>> 
>>> --
>>> --Guido van Rossum (python.org/~guido 
>>)
>>> /Pronouns: he/him/his //(why is my pronoun here?)/
>>> 
>>
>> 
>>> 
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>
>>> To unsubscribe send an email to python-dev-le...@python.org
>>
>>> https://mail.python.org/mailman3/lists/pyth

[Python-Dev] Re: What to do about invalid escape sequences

[Jeroen Demeyer]

> When you take a text string and create a string literal to represent
> it, sometimes you have to modify it to become syntactically valid.

Even simpler: use r""" instead of """

The only case where that won't work is when you need actual escape
sequences. But I find this very rare in practice for triple-quoted
strings.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LV5STHINBEREK2Y43OQLFUOBQPN2AXZC/

[Python-Dev] Re: What to do about invalid escape sequences

[Eric V. Smith]

On 8/5/2019 4:30 PM, raymond.hettin...@gmail.com wrote:


Thanks for weighing in.  I think this is an important usability discussion.  
IMO it is the number one issue affecting the end user experience with this 
release.   If we could get more people to actively use the beta release, the 
issue would stand-out front and center.  But if people don't use the beta in 
earnest, we won't have confirmation until it is too late.

We really don't have to go this path.  Arguably, the implicit conversion of 
'\latex' to '\\latex' is a feature that has existed for three decades, and now 
we're deciding to turn it off to define existing practices as errors.  I don't 
think any commercial product manager would allow this to occur without a lot of 
end user testing.


As much as I'd love to force this change through [0], it really does 
seem like we're forcing it. Especially given Nathaniel's point about the 
discoverability problems with compile-time warnings, I think we should 
delay a visible warning about this. Possibly in 3.9 we can do something 
about making these warnings visible at run time, not just compile time. 
I had a similar problems with f-strings (can't recall the details now, 
since resolved), and the compile-time-only nature made it difficult to 
notice. I realize a run-time warning for this would require a fair bit 
of work that might not be worth it.


I think Raymond's point goes beyond this. I think he's proposing that we 
never make this change. I'm sympathetic to that, too. But the first step 
is to change 3.8's behavior to not make this visible. That is, we should 
restore the 3.7 warning behavior.


Eric

[0] And the real reason I'd like this is so we can add \e
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UADZYIYTPGNRELG477F3SSRB3K7R2J75/

[Python-Dev] Re: typing: how to use names in result-tuples?

[Christian Tismer]

Hi Ronald,

sure, the tuple is usually not very interesting; people look it up
once and use that info in the code.

But I think things can be made quite efficient and pretty at the
same time. Such a return tuple could be hidden like the stat_result
example that Guido mentioned:

https://github.com/python/typeshed/blob/master/stdlib/3/os/__init__.pyi

def stat(self, *, follow_symlinks: bool = ...) -> stat_result: ...

The stat_result is a huge structure where you don't want to see much
unless you are working with a stat_result.

Other with common, repeating patterns like (x, y, width, height)
or your examples:

def getpoint(v: pointless) -> (int, int)
def getvalue(v: someclass) -> (bool, int)

would be at first sight

def getpoint(v: pointless) -> getpoint_result
def getvalue(v: someclass) -> getvalue_result

But actually, a much nicer, speaking outcome would be written as
the single function StructSequence(...) with arguments, producing:

def getpoint(v: pointless) -> StructSequence(x=int, y=int)
def getvalue(v: someclass) -> StructSequence(result=bool, val=int)

That would have the nice effect of a very visible structure in
the .pyi file. When you actually get such an object and look at it,
then you have

>>> getpoint(pointless())
getpoint_result(x=17, y=4)
>>> getvalue(someclass())
getvalue_result(result=True, val=42))

And the "magic" function StructSequence would simply index a dict
with the given argument tuple that gives the right struct sequence.
This is always possible, since only names and types are involved
in the lookup.

Cheers -- Chris


On 08.08.19 14:22, Ronald Oussoren wrote:
> Chrisian,
> 
> How would these namedtuple/structseq values be used? I have a similar
> design with PyObjC: pass-by-reference “return” values are returned in a
> tuple, e.g.:
> 
>     void getpoint(pointclass* v, int* x, int *y)    =>    def get
> point(v: pointless) -> (int, int)
>     BOOL getvalue(someclass* v, int* val)      =>    def getvalue(v:
> someclass) -> (bool, int)
> 
> I rarely, if ever, see code that actually stores the return tuple as-is.
> The return tuple is just deconstructed immediately, like “x, y =
> getpoint(mypoint)”. 
> 
> Ronald
> —
> 
> Twitter: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
> 
>> On 8 Aug 2019, at 10:42, Christian Tismer > > wrote:
>>
>> Hi Guido,
>>
>> If a C++ function already has a return value, plus some primitive
>> pointer variables that need to be moved into the result in Python,
>> then we have the case with a first, single unnamed field.
>> Only one such field can exist.
>>
>> I'm not sure if that case exists in the ~25000 Qt5 functions, but in
>> that case, I think to give that single field the name "unnamed"
>> or maybe better "result".
>>
>> Thank you very much for pointing me to that example!
>>
>> Cheers -- Chris
>>
>>
>> On 08.08.19 06:41, Guido van Rossum wrote:
>>> Alas, we didn't think of struct sequences when we designed PEP 484. It
>>> seems they are a hybrid of Tuple and NamedTuple; both of these are
>>> currently special-cased in mypy in ways that cannot easily be combined.
>>>
>>> Do you really need anonymous fields?
>>>
>>> I see an example in typeshed/stdlib/3/os/__init__.pyi (in
>>> github.com/python/typeshed 
>>> ), for
>>> stat_result. It defines names for all the fields, plus a __getitem__()
>>> method that indicates that indexing returns an int. This doesn't help if
>>> anonymous fields could have different types, not does it teach the type
>>> checker about the number of anonymous fields.
>>>
>>> --Guido
>>>
>>> On Wed, Aug 7, 2019 at 1:51 AM Christian Tismer >> 
>>> > wrote:
>>>
>>>    Hi all,
>>>
>>>    Ok, I am about to implement generation of such structures
>>>    automatically using the struct sequence concept.
>>>
>>>
>>>    One more question:
>>>    --
>>>
>>>    Struct sequences are not yet members of the typing types.
>>>    I would like to add that, because a major use case is also to
>>>    show nice .pyi files with all the functions and types.
>>>
>>>    * namedtuple has made the transition to NamedTuple
>>>
>>>    * What would I need to do that for StructSequence as well?
>>>
>>>    Things get also a bit more complicated since struct sequence
>>>    objects can contain unnamed fields.
>>>
>>>    Any advice would be appreciated, I am no typing expert (yet :-)
>>>
>>>    cheers -- Chris
>>>
>>>
>>>    On 30.07.19 17:10, Guido van Rossum wrote:
 I think I have to agree with Petr. Define explicit type names.

 On Tue, Jul 30, 2019 at 2:45 AM Paul Moore >>> 
>>>    
 >> wrote:

      On Tue, 30 Jul 2019 at 09:33, Christian Tismer
>>>    mailto:tis...@stackless.com>
>>> 

[Python-Dev] Re: typing: how to use names in result-tuples?

[Ronald Oussoren via Python-Dev]

> On 8 Aug 2019, at 17:12, Christian Tismer  wrote:
> 
> Hi Ronald,
> 
> sure, the tuple is usually not very interesting; people look it up
> once and use that info in the code.
> 
> But I think things can be made quite efficient and pretty at the
> same time. Such a return tuple could be hidden like the stat_result
> example that Guido mentioned:
> 
> https://github.com/python/typeshed/blob/master/stdlib/3/os/__init__.pyi 
> 
> 
>def stat(self, *, follow_symlinks: bool = ...) -> stat_result: ...
> 
> The stat_result is a huge structure where you don't want to see much
> unless you are working with a stat_result.
> 
> Other with common, repeating patterns like (x, y, width, height)
> or your examples:
> 
>def getpoint(v: pointless) -> (int, int)
>def getvalue(v: someclass) -> (bool, int)
> 
> would be at first sight
> 
>def getpoint(v: pointless) -> getpoint_result
>def getvalue(v: someclass) -> getvalue_result
> 
> But actually, a much nicer, speaking outcome would be written as
> the single function StructSequence(...) with arguments, producing:
> 
>def getpoint(v: pointless) -> StructSequence(x=int, y=int)
>def getvalue(v: someclass) -> StructSequence(result=bool, val=int)
> 
> That would have the nice effect of a very visible structure in
> the .pyi file. When you actually get such an object and look at it,
> then you have

But will you ever look at these objects, other then when exploring APIs in the 
REPL? As I wrote earlier the normal usage for a similar pattern in PyObjC is to 
always immediately deconstruct the tuple into its separate values. 

BTW. I’m primarily trying to understand your use case because it is so similar 
to what I’m doing in PyObjC, and such understanding can lead to an improvement 
in PyObjC ;-).

Ronald


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/W74WEFH4X7QU5WBOR4JSBW5BLPQW3UW3/

[Python-Dev] Re: typing: how to use names in result-tuples?

[Guido van Rossum]

OK, yes, having a convention for naming the anonymous field sounds like the
way to go. But presuming people will want to use it, and probably know it
from the C++ API, why not name it 'return_value' or 'result' or 'retval' or
something like that?

On Thu, Aug 8, 2019 at 1:43 AM Christian Tismer 
wrote:

> Hi Guido,
>
> If a C++ function already has a return value, plus some primitive
> pointer variables that need to be moved into the result in Python,
> then we have the case with a first, single unnamed field.
> Only one such field can exist.
>
> I'm not sure if that case exists in the ~25000 Qt5 functions, but in
> that case, I think to give that single field the name "unnamed"
> or maybe better "result".
>
> Thank you very much for pointing me to that example!
>
> Cheers -- Chris
>
>
> On 08.08.19 06:41, Guido van Rossum wrote:
> > Alas, we didn't think of struct sequences when we designed PEP 484. It
> > seems they are a hybrid of Tuple and NamedTuple; both of these are
> > currently special-cased in mypy in ways that cannot easily be combined.
> >
> > Do you really need anonymous fields?
> >
> > I see an example in typeshed/stdlib/3/os/__init__.pyi (in
> > github.com/python/typeshed ), for
> > stat_result. It defines names for all the fields, plus a __getitem__()
> > method that indicates that indexing returns an int. This doesn't help if
> > anonymous fields could have different types, not does it teach the type
> > checker about the number of anonymous fields.
> >
> > --Guido
> >
> > On Wed, Aug 7, 2019 at 1:51 AM Christian Tismer  > > wrote:
> >
> > Hi all,
> >
> > Ok, I am about to implement generation of such structures
> > automatically using the struct sequence concept.
> >
> >
> > One more question:
> > --
> >
> > Struct sequences are not yet members of the typing types.
> > I would like to add that, because a major use case is also to
> > show nice .pyi files with all the functions and types.
> >
> > * namedtuple has made the transition to NamedTuple
> >
> > * What would I need to do that for StructSequence as well?
> >
> > Things get also a bit more complicated since struct sequence
> > objects can contain unnamed fields.
> >
> > Any advice would be appreciated, I am no typing expert (yet :-)
> >
> > cheers -- Chris
> >
> >
> > On 30.07.19 17:10, Guido van Rossum wrote:
> > > I think I have to agree with Petr. Define explicit type names.
> > >
> > > On Tue, Jul 30, 2019 at 2:45 AM Paul Moore  > 
> > > >> wrote:
> > >
> > > On Tue, 30 Jul 2019 at 09:33, Christian Tismer
> > mailto:tis...@stackless.com>
> > > >>
> > wrote:
> > > > >>> typing.NamedTuple("__f", x=int, y=int)
> > > > 
> > > > >>> typing.NamedTuple("__f", x=int, y=int) is
> > typing.NamedTuple("__f",
> > > > x=int, y=int)
> > > > False
> > >
> > > This appears to go right back to collections.namedtuple:
> > >
> > > >>> from collections import namedtuple
> > > >>> n1 = namedtuple('f', ['a', 'b', 'c'])
> > > >>> n2 = namedtuple('f', ['a', 'b', 'c'])
> > > >>> n1 is n2
> > > False
> > >
> > > I found that surprising, as I expected the named tuple type to
> be
> > > cached based on the declared name 'f'. But it's been that way
> > forever
> > > so obviously my intuition here is wrong. But maybe it would be
> > useful
> > > for this case if there *was* a way to base named tuple
> > identity off
> > > the name/fields? It could be as simple as caching the results:
> > >
> > > >>> from functools import lru_cache
> > > >>> cached_namedtuple = lru_cache(None)(namedtuple)
> > > >>> n1 = cached_namedtuple('f', ('a', 'b', 'c')) # A tuple
> rather
> > > than a list of field names, as lists aren't hashable
> > > >>> n2 = cached_namedtuple('f', ('a', 'b', 'c'))
> > > >>> n1 is n2
> > > True
> > >
> > > Paul
> > >
> > >
> > >
> > > --
> > > --Guido van Rossum (python.org/~guido 
> > )
> > > /Pronouns: he/him/his //(why is my pronoun here?)/
> > >
> > <
> http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/
> >
> > >
> > > ___
> > > Python-Dev mailing list -- python-dev@python.org
> > 
> > > To unsubscribe send an email to python-dev-le...@python.org
> > 
> > > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > > Message a

[Python-Dev] Re: typing: how to use names in result-tuples?

[Christian Tismer]

On 08.08.19 17:20, Ronald Oussoren via Python-Dev wrote:
> 
> 
>> On 8 Aug 2019, at 17:12, Christian Tismer > > wrote:
>>
>> Hi Ronald,
>>
>> sure, the tuple is usually not very interesting; people look it up
>> once and use that info in the code.
>>
>> But I think things can be made quite efficient and pretty at the
>> same time. Such a return tuple could be hidden like the stat_result
>> example that Guido mentioned:
>>
>> https://github.com/python/typeshed/blob/master/stdlib/3/os/__init__.pyi
>>
>>    def stat(self, *, follow_symlinks: bool = ...) -> stat_result: ...
>>
>> The stat_result is a huge structure where you don't want to see much
>> unless you are working with a stat_result.
>>
>> Other with common, repeating patterns like (x, y, width, height)
>> or your examples:
>>
>>    def getpoint(v: pointless) -> (int, int)
>>    def getvalue(v: someclass) -> (bool, int)
>>
>> would be at first sight
>>
>>    def getpoint(v: pointless) -> getpoint_result
>>    def getvalue(v: someclass) -> getvalue_result
>>
>> But actually, a much nicer, speaking outcome would be written as
>> the single function StructSequence(...) with arguments, producing:
>>
>>    def getpoint(v: pointless) -> StructSequence(x=int, y=int)
>>    def getvalue(v: someclass) -> StructSequence(result=bool, val=int)
>>
>> That would have the nice effect of a very visible structure in
>> the .pyi file. When you actually get such an object and look at it,
>> then you have
> 
> But will you ever look at these objects, other then when exploring APIs
> in the REPL? As I wrote earlier the normal usage for a similar pattern
> in PyObjC is to always immediately deconstruct the tuple into its
> separate values. 


Yes, it is for exploring the interface. In Qt5, you have *very* many
functions, and they are pretty unpythonic as well.
That was the reason at all for me to write that __signature__ module for
PySide, that does everything with introspection.

When I'm programming with it, then half as a user who wants to see
"yes, it really returns such a value" and as a developer "shit, we claim
that interface, but lied".

In a sense, it was also a way to test this huge library automatically,
and I enjoy it when things can explain themselves.
That is absolutely not necessary.

As the whole typing idea and typeshed is not necessary, but for me
it was a huge win to have a typed interface, and IDE users seem to
love it when PyCharm suddenly talks to them ;-)


> BTW. I’m primarily trying to understand your use case because it is so
> similar to what I’m doing in PyObjC, and such understanding can lead to
> an improvement in PyObjC ;-).


I am happy to learn from your projects as well! All the best

-- Chris

-- 
Christian Tismer :^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TUQVQIRTBSI6HCWBRKAZTCCTNVKCLXJJ/

[Python-Dev] Re: typing: how to use names in result-tuples?

[Christian Tismer]

Yes, that's what I mean.
Probably retval or whatever people prefer would be adequate,
with a special rule if that name is taken.

I think btw. that using StructSequence(somename=sometype, ..., ) that
does a dict lookup is quite appealing. It returns a class like
stat_result, but the function call shows its arguments (see answer to
Ronald).

Ciao -- Chris


On 08.08.19 17:22, Guido van Rossum wrote:
> OK, yes, having a convention for naming the anonymous field sounds like
> the way to go. But presuming people will want to use it, and probably
> know it from the C++ API, why not name it 'return_value' or 'result' or
> 'retval' or something like that?
> 
> On Thu, Aug 8, 2019 at 1:43 AM Christian Tismer  > wrote:
> 
> Hi Guido,
> 
> If a C++ function already has a return value, plus some primitive
> pointer variables that need to be moved into the result in Python,
> then we have the case with a first, single unnamed field.
> Only one such field can exist.
> 
> I'm not sure if that case exists in the ~25000 Qt5 functions, but in
> that case, I think to give that single field the name "unnamed"
> or maybe better "result".
> 
> Thank you very much for pointing me to that example!
> 
> Cheers -- Chris
> 
> 
> On 08.08.19 06:41, Guido van Rossum wrote:
> > Alas, we didn't think of struct sequences when we designed PEP 484. It
> > seems they are a hybrid of Tuple and NamedTuple; both of these are
> > currently special-cased in mypy in ways that cannot easily be
> combined.
> >
> > Do you really need anonymous fields?
> >
> > I see an example in typeshed/stdlib/3/os/__init__.pyi (in
> > github.com/python/typeshed 
> ), for
> > stat_result. It defines names for all the fields, plus a __getitem__()
> > method that indicates that indexing returns an int. This doesn't
> help if
> > anonymous fields could have different types, not does it teach the
> type
> > checker about the number of anonymous fields.
> >
> > --Guido
> >
> > On Wed, Aug 7, 2019 at 1:51 AM Christian Tismer
> mailto:tis...@stackless.com>
> > >> wrote:
> >
> >     Hi all,
> >
> >     Ok, I am about to implement generation of such structures
> >     automatically using the struct sequence concept.
> >
> >
> >     One more question:
> >     --
> >
> >     Struct sequences are not yet members of the typing types.
> >     I would like to add that, because a major use case is also to
> >     show nice .pyi files with all the functions and types.
> >
> >     * namedtuple has made the transition to NamedTuple
> >
> >     * What would I need to do that for StructSequence as well?
> >
> >     Things get also a bit more complicated since struct sequence
> >     objects can contain unnamed fields.
> >
> >     Any advice would be appreciated, I am no typing expert (yet :-)
> >
> >     cheers -- Chris
> >
> >
> >     On 30.07.19 17:10, Guido van Rossum wrote:
> >     > I think I have to agree with Petr. Define explicit type names.
> >     >
> >     > On Tue, Jul 30, 2019 at 2:45 AM Paul Moore
> mailto:p.f.mo...@gmail.com>
> >     >
> >     > 
>  >     >
> >     >     On Tue, 30 Jul 2019 at 09:33, Christian Tismer
> >     mailto:tis...@stackless.com>
> >
> >     >         >     wrote:
> >     >     > >>> typing.NamedTuple("__f", x=int, y=int)
> >     >     > 
> >     >     > >>> typing.NamedTuple("__f", x=int, y=int) is
> >     typing.NamedTuple("__f",
> >     >     > x=int, y=int)
> >     >     > False
> >     >
> >     >     This appears to go right back to collections.namedtuple:
> >     >
> >     >     >>> from collections import namedtuple
> >     >     >>> n1 = namedtuple('f', ['a', 'b', 'c'])
> >     >     >>> n2 = namedtuple('f', ['a', 'b', 'c'])
> >     >     >>> n1 is n2
> >     >     False
> >     >
> >     >     I found that surprising, as I expected the named tuple
> type to be
> >     >     cached based on the declared name 'f'. But it's been
> that way
> >     forever
> >     >     so obviously my intuition here is wrong. But maybe it
> would be
> >     useful
> >     >     for this case if there *was* a way to base named tuple
> >     

[Python-Dev] PEP 572 TargetScopeError

[Barry Warsaw]

bpo-37757: https://bugs.python.org/issue37757

This issue describes some corner cases in PEP 572 (assignment expressions) 
syntax that haven’t been implemented yet.  The PEP currently says:

"The two invalid cases listed above raise TargetScopeError, a new subclass of 
SyntaxError (with the same signature).”

The PEP doesn’t really go into the rationale for why a new exception is being 
defined, and in the issue I’ve argued that we should just raise SyntaxError in 
those cases.  To me, “TargetScopeError” is pretty obscure and doesn’t give 
users an obvious clue as to what’s going wrong, without searching the interwebs.

Nick argues (apologies if I’m misrepresenting you!):

"I believe our main motivation for separating it out was the fact that even 
though TargetScopeError is a compile-time error, the affected code is 
syntactically fine - there are just issues with unambiguously inferring the 
intended read/write location for the affected target names. (Subclassing 
SyntaxError is then a pragmatic concession to the fact that "SyntaxError" also 
de facto means "CompilationError”)”

Serhiy points out that we have IndentationError and TabError subclasses of 
SyntaxError, but those feel different to me because the exception names 
themselves are clear and descriptive, and lead to obvious actionable remedies.

Guido then suggests we take the discussion here, thus this email.

It would be a very minor update to the PEP, but I think it’s useful to resolve 
before the last push for PEP 572 implementation gets completed.

Rather than just a vote, if you have a rationale for one over the other, I’d 
love to hear it.  Feel free to weigh in here or on the issue.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FXVSYCTQOTT7JCFACKPGPXKULBCGEPQY/

[Python-Dev] Re: PEP 572 TargetScopeError

[Tim Peters]

[Barry Warsaw ]
> bpo-37757: https://bugs.python.org/issue37757

Really couldn't care less whether it's TargetScopeError or
SyntaxError, but don't understand the only rationale given here for
preferring the latter:

> To me, “TargetScopeError” is pretty obscure and doesn’t give users an
> obvious clue as to what’s going wrong, without searching the interwebs.

Whereas SyntaxError would give no clue whatsoever, and nothing useful
to search for.  In contrast, a search for TargetScopeError would
presumably find a precisely relevant explanation as the top hit
(indeed, it already does today).

I don't care because it's unlikely an error most people will make at
all - or, for those too clever for their own good, make more than once
;-)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WBWCV7PBDYY6PVSXIX2QX7GKXY54PREU/

[Python-Dev] Re: PEP 572 TargetScopeError

[Barry Warsaw]

On Aug 8, 2019, at 10:41, Tim Peters  wrote:

> Whereas SyntaxError would give no clue whatsoever, and nothing useful
> to search for.  In contrast, a search for TargetScopeError would
> presumably find a precisely relevant explanation as the top hit
> (indeed, it already does today).
> 
> I don't care because it's unlikely an error most people will make at
> all - or, for those too clever for their own good, make more than once
> ;-)

I agree it’s probably going to be a rare occurrence.  I suppose it just bothers 
me that when it does happen, we’ll present an obscurely named exception that 
will essentially force users to search for it.  But maybe they’ll have to 
anyway.  OTOH, maybe we can find an even better name, like EggManError or 
KooKooKaChooError.

I-am-the-Walrus-lyrics-won’t-help-you-at-all-ly y’rs,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SSPDFUPPCLLNOWGHWPB5JK2ZIFRL6J44/

[Python-Dev] Re: PEP 572 TargetScopeError

[Chris Angelico]

On Fri, Aug 9, 2019 at 4:00 AM Barry Warsaw  wrote:
>
> On Aug 8, 2019, at 10:41, Tim Peters  wrote:
>
> > Whereas SyntaxError would give no clue whatsoever, and nothing useful
> > to search for.  In contrast, a search for TargetScopeError would
> > presumably find a precisely relevant explanation as the top hit
> > (indeed, it already does today).
> >
> > I don't care because it's unlikely an error most people will make at
> > all - or, for those too clever for their own good, make more than once
> > ;-)
>
> I agree it’s probably going to be a rare occurrence.  I suppose it just 
> bothers me that when it does happen, we’ll present an obscurely named 
> exception that will essentially force users to search for it.  But maybe 
> they’ll have to anyway.  OTOH, maybe we can find an even better name, like 
> EggManError or KooKooKaChooError.
>

ConfusedWalrusError? :)

I think it's good to have a subclass of SyntaxError for this. It's way
easier to recognize what's going on when the exception name makes it
clear that this isn't a typo. Trying to be too descriptive in the name
will just make it too long, but maybe AmbiguousScopeError would be
better?

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OVLTKZBKO5AACKYPXNMCLYLZUR5XOWPY/

[Python-Dev] Re: Can someone please finish merging GH-13482?

[Brett Cannon]

Tim Peters wrote:
> [Brett Cannon br...@python.org]
> > We probably need to update https://devguide.python.org/committing/
> > to
> > have a step-by-step list of how to make a merge works and how to
> > handle backports instead of the wall of text that we have. (It's already
> > outdated anyway, e.g. Misc/ACKS really isn't important as git itself
> > records the author of the commit and so that can be used with
> > Misc/ACKS for old commits to gather the list of folks who have"
> > contributed.)
> > Don't put too much weight on my screwups ;-)  I was appalled to hear
> that the OP's contribution was still sitting unmerged, and was in a
> hurry to resolve that at a time I _had_ no significant time to give to
> it.

Sure, but I and I hope everyone else here wants to make the dev process as easy 
as possible so that more people help out regardless of their comfort with git 
so that PRs are dealt with fast enough none of us become appalled. ;) So the 
fact you had any struggles suggests there is room for improvement, even if the 
docs say "click the green button and if miss-islington says something happened 
then come to python-committers for help".

> Mariatta and Terry Reedy finished up what I left undone, so in the end
> it's all good :-)
> And there's a problem with the GitHub workflow docs that may be unique
> to me:  we have helpful layers of automation, but they're shortening a
> git workflow I don't understand even without the automation.  With the
> automation, I'm just doubly clueless.
> That's because I'm old.  My capacity to give a rip about source
> control system quirks was apparently entirely used up when I spent
> several weeks mastering the intricacies of Mercurial.  Try as I might,
> I just haven't been able to force myself to become competent with git.
> It's not that I disapprove of git!  It's apparently more that we're
> each born with a finite capacity for being _able_ to learn Yet Another
> New Source Control System, and mine was used up on YANSCS #8 ;-)
> aging-isn't-for-the-optimistic-ly y;rs  - tim

Yeah, but I still want your filled brain to be able to use our workflow to help 
put you to work. ;)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DP2QF6YUZS42WVIWHHNMRJVH7RQKEIC7/

[Python-Dev] Re: PEP 572 TargetScopeError

[Ivan Pozdeev via Python-Dev]

On 08.08.2019 20:54, Barry Warsaw wrote:

On Aug 8, 2019, at 10:41, Tim Peters  wrote:


Whereas SyntaxError would give no clue whatsoever, and nothing useful
to search for.  In contrast, a search for TargetScopeError would
presumably find a precisely relevant explanation as the top hit
(indeed, it already does today).

I don't care because it's unlikely an error most people will make at
all - or, for those too clever for their own good, make more than once
;-)

I agree it’s probably going to be a rare occurrence.  I suppose it just bothers 
me that when it does happen, we’ll present an obscurely named exception that 
will essentially force users to search for it.  But maybe they’ll have to 
anyway.  OTOH, maybe we can find an even better name, like EggManError or 
KooKooKaChooError.


It looks like you are forgetting that an exception presented to the user is 
accompanied with an explanation text.

Something like "Cannot assign `i` because this name is already used as a comprehension's loop variable" would clarify what exactly they did 
wrong.



I-am-the-Walrus-lyrics-won’t-help-you-at-all-ly y’rs,
-Barry


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SSPDFUPPCLLNOWGHWPB5JK2ZIFRL6J44/


--
Regards,
Ivan

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GCS24S5ADTQCOZUHOBR3TGSBPLWYJ7CT/

[Python-Dev] Re: PEP 572 TargetScopeError

[Brett Cannon]

I agree that it should be a SyntaxError as it's a semantic issue regarded to 
syntax. For instance, we already use SyntaxError for when a `return` statement 
is outside of a function and I view this as the same sort of error. And I think 
 with an appropriately descriptive message like Ivan pointed out will handle 
any confusion, especially since this exception will very rarely be caught and 
if it is it very likely won't be caught _just_ for the walrus operator and no 
other syntax-related error.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WJ6YQSFWO6JPJEMWA6FJSWOA4VK4R4RF/

[Python-Dev] Re: PEP 572 TargetScopeError

[Kyle Stanley]

Barry Warsaw wrote:
> The PEP doesn’t really go into the rationale for why a new exception is being 
> defined,
> and in the issue I’ve argued that we should just raise SyntaxError in those 
> cases.  To me,
> “TargetScopeError” is pretty obscure and doesn’t give users an obvious clue 
> as to what’s
> going wrong, without searching the interwebs.

Barry Warsaw wrote:
> Serhiy points out that we have IndentationError and TabError subclasses of 
> SyntaxError,
> but those feel different to me because the exception names themselves are 
> clear and
> descriptive, and lead to obvious actionable remedies.

I find myself in agreement that SyntaxError should be raised for the above 
reasons, as
long as the error message can adequately explain to the user that it's an issue 
with the
scope they're referring to:

``SyntaxError: Invalid scope defined by walrus operator: 'i := 10 for i in 
range(5)'``

To make it a bit more more succinct, "by walrus operator" could be potentially 
removed. 

I don't think there's anything inherently wrong with the users looking up the 
name of the
exception for more information, but it should not be required to gain a basic
understanding of what the error is referring to.

Also, I'm not entirely convinced that this would be a frequent enough 
occurrence to justify
creating a subclass of SyntaxError instead of simply using a custom message to
describe the issue.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZE3JNHAW46QCOAYQRNKYUABFK5YEJCZH/

[Python-Dev] Re: What to do about invalid escape sequences

[Jim J. Jewett]

FWIW, the web archive 
https://mail.python.org/archives/list/python-dev@python.org/thread/ZX2JLOZDOXWVBQLKE4UCVTU5JABPQSLB/
 does not seem to display the problems ... apparently the individual messages 
are not included in view source, and are cleaned up for chrome's inspect.  I'm 
not sure whether that counts as a bug in the archiving or not.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UYSBJFII467TKNA2SDYCJZUQFLCGEAKY/

[Python-Dev] Re: PEP 572 TargetScopeError

[Steven D'Aprano]

On Thu, Aug 08, 2019 at 10:00:01AM -0700, Barry Warsaw wrote:

> "The two invalid cases listed above raise TargetScopeError, a new 
> subclass of SyntaxError (with the same signature).”
> 
> The PEP doesn’t really go into the rationale for why a new exception 
> is being defined, and in the issue I’ve argued that we should just 
> raise SyntaxError in those cases.  To me, “TargetScopeError” is pretty 
> obscure and doesn’t give users an obvious clue as to what’s going 
> wrong, without searching the interwebs.

It's not a syntax error. There's nothing wrong with the syntax per-say: 
we still have ``target := expression``. There's a problem with the 
*semantics* not the syntax.

The name is perfectly self-descriptive: TargetScopeError means that 
there's an error with the scope of the target. What else could it mean?

What's wrong with having to look up an unfamiliar exception by searching 
the interwebs? The first few times I hit KeyError, I had no idea what a 
"key" was (I was a beginner) and if I had internet access, I would have 
looked it up on the web. I didn't, so I looked it up in the book I was 
reading.

The first times I hit UnboundLocalError, I did have internet access, so 
I googled it. Once I understood that it meant that the local I was 
trying to use was unbound, and that "unbound" mean "undefined", all was 
clear.

(Well, not all, I still had to work out why it was undefined. But at 
least the exception name was more clear.)

One of the frustrations I have is that it's near to impossible to 
programmatically distinguish wrong number of arguments from bad keyword 
arguments from providing the wrong type of argument without relying on 
the error message. (And yes, I have needed to do this.) All of these 
raise the same TypeError, even though only one of them is an actual 
error with the type:

len(1)  # An actual TypeError

len([], None)  # The type of the argument is fine.

len(spam=[])   # The type of the argument is fine.

Please let's not use SyntaxError for something that's not an error 
with the syntax.



-- 
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GC3AYNSX2W4JR4RLR3NOJZQFRHOLTG5L/

[Python-Dev] Re: PEP 572 TargetScopeError

[Greg Ewing]

Barry Warsaw wrote:

Subclassing
SyntaxError is then a pragmatic concession to the fact that "SyntaxError"
also de facto means "CompilationError”


Perhaps there should be a CompilationError tghat SyntaxError and
TargetScopeError are subclasses of?

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CHUWNXB737ZYTJTD5EMFXJ3RFOEEOBGM/

[Python-Dev] Re: PEP 572 TargetScopeError

[Barry Warsaw]

On Aug 8, 2019, at 14:58, Steven D'Aprano  wrote:

> It's not a syntax error. There's nothing wrong with the syntax per-say:
> we still have ``target := expression``. There's a problem with the
> *semantics* not the syntax.

I’m not sure that distinction is meaningful though.  What you wrote is 
disallowed, so you have to change your code (i.e. syntax) to avoid the error.

> The name is perfectly self-descriptive: TargetScopeError means that
> there's an error with the scope of the target. What else could it mean?

What’s the scope?  What’s *a* scope (in this context)?  What’s the target?  
Nothing about the exception name tells you that it’s a problem with the 
assignment expression you wrote.

> What's wrong with having to look up an unfamiliar exception by searching
> the interwebs? The first few times I hit KeyError, I had no idea what a
> "key" was (I was a beginner) and if I had internet access, I would have
> looked it up on the web. I didn't, so I looked it up in the book I was
> reading.

But remember that assignment expressions are a relatively advanced topic.  Once 
you learned what a key was — and you have to do that pretty early on in your 
Python experience — KeyError is perfectly descriptive.

So let’s imagine what the user experience would be like with a better named 
exception to see whether a subclass is worth it.  For now let’s call it 
AssignmentExpressionDisallowedError.  If you saw that it would definitely be 
more descriptive.  Is that valuable in the error output?  Is it still valuable 
when you have useful descriptive text?

> Please let's not use SyntaxError for something that's not an error
> with the syntax.

PEP 572 does propose TargetScopeError as a subclass of SyntaxError, so you’re 
getting a SyntaxError anyway.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2AMSRRGEXFQOLIRVCUXRR7U6CM6EMTPJ/

[Python-Dev] Re: PEP 572 TargetScopeError

[Rob Cliffe via Python-Dev]

On 08/08/2019 22:58:15, Steven D'Aprano wrote:

On Thu, Aug 08, 2019 at 10:00:01AM -0700, Barry Warsaw wrote:


"The two invalid cases listed above raise TargetScopeError, a new
subclass of SyntaxError (with the same signature).”

The PEP doesn’t really go into the rationale for why a new exception
is being defined, and in the issue I’ve argued that we should just
raise SyntaxError in those cases.  To me, “TargetScopeError” is pretty
obscure and doesn’t give users an obvious clue as to what’s going
wrong, without searching the interwebs.

It's not a syntax error. There's nothing wrong with the syntax per-say:
we still have ``target := expression``. There's a problem with the
*semantics* not the syntax.

The name is perfectly self-descriptive: TargetScopeError means that
there's an error with the scope of the target. What else could it mean?
That's easy for an experienced programmer to say.  IMHO it's about as 
helpful to a
newbie as saying GrobKunkError means that there's an error with the kunk 
of the grob.


I think AmbiguousScopeError is somewhat better than TargetScopeError,
but perhaps someone will think of something even better.
(ScopeConflictError?  InvalidVariableReuse?  I dunno.)

What's wrong with having to look up an unfamiliar exception by searching
the interwebs? The first few times I hit KeyError, I had no idea what a
"key" was (I was a beginner) and if I had internet access, I would have
looked it up on the web. I didn't, so I looked it up in the book I was
reading.

The first times I hit UnboundLocalError, I did have internet access, so
I googled it. Once I understood that it meant that the local I was
trying to use was unbound, and that "unbound" mean "undefined", all was
clear.

(Well, not all, I still had to work out why it was undefined. But at
least the exception name was more clear.)
Sure, people should be encouraged to look things up on the web (if they 
haven't

already acquired the habit).  But that doesn't mean we shouldn't make things
as clear as reasonably possible in the first place.


One of the frustrations I have is that it's near to impossible to
programmatically distinguish wrong number of arguments from bad keyword
arguments from providing the wrong type of argument without relying on
the error message. (And yes, I have needed to do this.) All of these
raise the same TypeError, even though only one of them is an actual
error with the type:

 len(1)  # An actual TypeError

 len([], None)  # The type of the argument is fine.

 len(spam=[])   # The type of the argument is fine.

Please let's not use SyntaxError for something that's not an error
with the syntax.
(For reference the error messages are, depending a bit on the Python 
version, respectively

    object of type 'int' has no len()
    len() takes exactly one argument (2 given)
    len() takes no keyword arguments .
.)
I'm mildly curious as to why you couldn't rely on the error message, but 
I'm sure you had a good reason.
FWIW IMHO the last two ought to produce an exception called 
ArgumentError or ParameterError or some such
or even more specific names such as TooManyArguments and 
KeywordArgumentsDisallowed.
I guess I'm agreeing with you to the extent that I'm proposing more 
(specific) exceptions.

Rob Cliffe





___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GEOWJTBNMTE6KWCVR5AJTQNSWIRALXOD/

[Python-Dev] Re: PEP 572 TargetScopeError

[Eric V. Smith]

On 8/8/2019 7:28 PM, Barry Warsaw wrote:

On Aug 8, 2019, at 14:58, Steven D'Aprano  wrote:


It's not a syntax error. There's nothing wrong with the syntax per-say:
we still have ``target := expression``. There's a problem with the
*semantics* not the syntax.


I’m not sure that distinction is meaningful though.  What you wrote is 
disallowed, so you have to change your code (i.e. syntax) to avoid the error.


I agree with Barry here. For all practical purposes, it's a syntax 
error. And if we had a more powerful parser, maybe it really would be a 
syntax error. See Guido's recent PEG parser articles 
(https://medium.com/@gvanrossum_83706/peg-parsers-7ed72462f97c) where he 
discusses raising SyntaxError after the parser is finished, in a 
subsequent pass. Is it really a syntax error if pgen doesn't object to 
it? In current CPython, the answer is yes.


But to the original point: I think the real reason to make this just a 
SyntaxError, and not a subclass (TargetScopeError) is this: would you 
ever catch TargetScopeError? If not, why would it need to be its own 
class? It should just be SyntaxError with a descriptive enough text that 
the user can figure out what's wrong.


I don't see anyone ever writing:

try:
.. something ..
except TargetScopeError:
.. handle this ..
except SyntaxError:
.. handle this differently ..

Eric
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5AALXTK5JKZSFBDPVD2Y2ONE2JFEKDN7/

[Python-Dev] Re: What to do about invalid escape sequences

[Stephen J. Turnbull]

Steve Holden writes:

 > This whole thread would be an excellent justification for following 3.9
 > with 4.0. It's as near as we ever want to get to a breaking change, and a
 > major version number would indicate the need to review. If increasing
 > strictness of escape code interpretation in string literals is the only
 > incompatibility there would surely be general delight.

This should be the first chapter in the Beautiful Version Numbering
book!  I love it!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LY2RX4ROGH54IU57RO7Y2O6IDDV5LUBG/

[Python-Dev] Re: PEP 572 TargetScopeError

[Serhiy Storchaka]

08.08.19 20:00, Barry Warsaw пише:

Rather than just a vote, if you have a rationale for one over the other, I’d 
love to hear it.  Feel free to weigh in here or on the issue.


I do not have arguments for SyntaxError but the rationale for 
TargetScopeError does not look strong to me. IndentationError and 
TabError are special enough. Don't count me as advocating for 
TargetScopeError.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/K63RQZTWB6W2KJAIBH3SQXZDC75S5MJH/