[Python-Dev] Re: Function Prototypes

[Serhiy Storchaka]

24.12.21 00:09, Guido van Rossum пише:
> Without decorator too (that was Lukasz’ idea). Why bother with the
> decorator (*if* we were to go there)?

It is errorprone.

Some library provide function foo() which returns an instance of private
type _Foo and people start using it as a type hint. A new version
converts foo() into a class. It is usually a safe backward compatible
change, except that now all type hints became wrong. "a: foo" now means
an instance of foo, not a callable which returns an instance of _Foo.

There are also issues with subclassing.

>>> foo = Callable[[int], str]
>>> class A(foo): ...
...
>>> def bar(x: int, /) -> str: pass
...
>>> class B(bar): ...
...
Traceback (most recent call last):
  File "", line 1, in 
TypeError: function() argument 'code' must be code, not str

There are also issues with subscripting:

>>> T = TypeVar('T')
>>> foo = Callable[[T], list[T]]
>>> list[foo][int]
list[typing.Callable[[int], list[int]]]
>>> def bar(x: T, /) -> list[T]: pass
...
>>> list[bar][int]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: There are no type variables left in list[__main__.bar]

___
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/ALW5PMZ3MRIG3BGTX5DVIKFO4JS45MBK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Function Prototypes

[Andrew Svetlov]

I like the Callable decorator idea very much.
It supports all Python function flavors out of the box, isn't it?

Also, what is about allowing to make callable types from existing functions
(and even methods maybe) with type hints?
def f(a: int, /, b: float) -> str:
return str(a*b)

F = Callable(f)

Could it work?

I'm ok with making an explicit Callable type alias first for every usage.
But if I can create it from an existing function augmented with type hints
without copy-pasting the signature -- it can make my life significantly
easier.

What do you think?

On Fri, Dec 24, 2021 at 11:57 AM Serhiy Storchaka 
wrote:

> 24.12.21 00:09, Guido van Rossum пише:
> > Without decorator too (that was Lukasz’ idea). Why bother with the
> > decorator (*if* we were to go there)?
>
> It is errorprone.
>
> Some library provide function foo() which returns an instance of private
> type _Foo and people start using it as a type hint. A new version
> converts foo() into a class. It is usually a safe backward compatible
> change, except that now all type hints became wrong. "a: foo" now means
> an instance of foo, not a callable which returns an instance of _Foo.
>
> There are also issues with subclassing.
>
> >>> foo = Callable[[int], str]
> >>> class A(foo): ...
> ...
> >>> def bar(x: int, /) -> str: pass
> ...
> >>> class B(bar): ...
> ...
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: function() argument 'code' must be code, not str
>
> There are also issues with subscripting:
>
> >>> T = TypeVar('T')
> >>> foo = Callable[[T], list[T]]
> >>> list[foo][int]
> list[typing.Callable[[int], list[int]]]
> >>> def bar(x: T, /) -> list[T]: pass
> ...
> >>> list[bar][int]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: There are no type variables left in list[__main__.bar]
>
> ___
> 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/ALW5PMZ3MRIG3BGTX5DVIKFO4JS45MBK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Thanks,
Andrew Svetlov
___
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/MWWWIIYOWH3TCZGAW7J6OHDCO6IDTJWZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-12-17 - 2021-12-24)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7196 (+16)
  closed 50706 (+41)
  total  57902 (+57)

Open issues with patches: 2866 


Issues opened (37)
==

#44598: test_constructor (test.test_ssl.ContextTests) ... Fatal Python
https://bugs.python.org/issue44598  reopened by sxt1001

#46118: Migrate importlib.resources into a package
https://bugs.python.org/issue46118  opened by jaraco

#46119: Update bundled pip to 21.3.1 and setuptools to 59.7.0
https://bugs.python.org/issue46119  opened by kumaraditya303

#46120: Add note to `typing.Union` that it is recommended to use `|` i
https://bugs.python.org/issue46120  opened by sobolevn

#46121: Add a note to QueueListener documentation saying that SimpleQu
https://bugs.python.org/issue46121  opened by iamdbychkov

#46124: Deprecation warning in zoneinfo module
https://bugs.python.org/issue46124  opened by xtreak

#46125: Test the preferred API instead of relying on legacy for covera
https://bugs.python.org/issue46125  opened by jaraco

#46126: Unittest output drives developers to avoid docstrings
https://bugs.python.org/issue46126  opened by jaraco

#46128: Strip IsolatedAsyncioTestCase frames from reported stacktraces
https://bugs.python.org/issue46128  opened by asvetlov

#46133: Unclear whether one can (or how to) provide source to exec-gen
https://bugs.python.org/issue46133  opened by posita

#46134: Confusing error message for AttributeError with dataclasses
https://bugs.python.org/issue46134  opened by landonjpginn

#46141: Fix ipaddress.ip_network TypeErrors
https://bugs.python.org/issue46141  opened by bar.harel

#46142: python --help output is too long
https://bugs.python.org/issue46142  opened by eric.araujo

#46143: [docs] IO > Text Encoding info outdated
https://bugs.python.org/issue46143  opened by gilbertson.david

#46146: Python IDLE fails to start (tk font issue?)
https://bugs.python.org/issue46146  opened by mcepl

#46147: Support AddressSanitizer in Windows build
https://bugs.python.org/issue46147  opened by anthonypjshaw

#46148: Optimize pathlib
https://bugs.python.org/issue46148  opened by kumaraditya303

#46149: FIPS usedforsecurity flag is no longer functional with OpenSSL
https://bugs.python.org/issue46149  opened by florinspatar

#46150: test_pathlib assumes "fakeuser" does not exist as user
https://bugs.python.org/issue46150  opened by twouters

#46151: SimpleCookie.js_output is vulnerable to HTML injection
https://bugs.python.org/issue46151  opened by trungpaaa

#46154: MIMEMultipart enforces line endings also for binary subparts
https://bugs.python.org/issue46154  opened by sophonet

#46156: 3.9.9: python built-in SSL module unable to connect to an IIS 
https://bugs.python.org/issue46156  opened by lkraav

#46157: Typo in JSON documentation
https://bugs.python.org/issue46157  opened by jordan-bonecutter

#46158: Hardcoded sysroot path, to MacOSX11.sdk, in python sysconfig
https://bugs.python.org/issue46158  opened by akumar9

#46159: Segfault when using trace functions in 3.11a3
https://bugs.python.org/issue46159  opened by reaperhulk

#46161: `class A(1, 2, 3, **d): pass` gives bad bytecode
https://bugs.python.org/issue46161  opened by zq1997

#46162: Make `builtins.property` generic
https://bugs.python.org/issue46162  opened by sobolevn

#46163: multiprocessing logger deadlocks if used with logging.handlers
https://bugs.python.org/issue46163  opened by iamdbychkov

#46166: Get "self" args or non-null co_varnames from frame object with
https://bugs.python.org/issue46166  opened by Skylion007

#46167: Parse assert (x == y, "Descriptive text") as statement params 
https://bugs.python.org/issue46167  opened by gregory.p.smith

#46168: Incorrect format specified for the "style" key in the configur
https://bugs.python.org/issue46168  opened by bokunogf

#46169: Same-moment datetimes with different ZoneInfo timezones are no
https://bugs.python.org/issue46169  opened by huonw

#46170: Improving the error message when subclassing NewType
https://bugs.python.org/issue46170  opened by Gobot1234

#46171: venv module produces spurious warning that location has moved
https://bugs.python.org/issue46171  opened by layday

#46172: [doc] Outdated description of `license` object
https://bugs.python.org/issue46172  opened by CCXXXI

#46173: float(x) with large x not raise OverflowError
https://bugs.python.org/issue46173  opened by cykerway

#46174: Feature Request for Python Interfaces
https://bugs.python.org/issue46174  opened by Orie



Most recent 15 issues with no replies (15)
==

#46174: Feature Request for Python Interfaces
https://bugs.python.org/issue46174

#46172: [doc] Outdated description of `license` object
https://bugs.python.org/issue46172

#46170: Improving the error message when subclassing NewTyp

[Python-Dev] Re: Function Prototypes

[Jim J. Jewett]

Steven D'Aprano wrote:
> In comparison, Mark's version:
> @Callable
> def IntToIntFunc(a:int)->int:
> pass
> # in the type declaration
> func: IntToIntFunc
> uses 54 characters, plus spaces and newlines (including 7 punctuation 
> characters); it takes up three extra lines, plus a blank line. As 
> syntax goes it is double the size of Callable.

I think it takes only the characters needed to write the name IntToIntFunc.

The @callable def section is a one-time definition, and not logically part of 
each function definition where it is used.

I get that some people prefer an inline lambda to a named function, and others 
hate naming an infrastructure function, but ...

Why are you even bothering to type the callback function?  If it is complicated 
enough to be worth explicitly typing, then it is complicated enough to chunk 
off with a name.

I won't say it is impossible to understand a function signature on the first 
pass if it takes several lines and whitespace to write ... but it is much 
easier when the the declaration is short enough to fit on a single line.  

An @ on the line above complicates the signature parsing, but can be mentally 
processed separately.  The same is true of a named-something-or-other in the 
middle.

Having to switch parsing modes to understand an internal ([int, float, int] -> 
List[int]), and then to pop that back off the stack is much harder. 
 Hard enough that you really ought to help your reader out with a name, and let 
them figure out what that names means separately, when their brain's working 
memory isn't already loaded with the first part of your own function, but still 
waiting for the last part.

> It separates the type declaration from the point at which it is used, 
> potentially far away from where it is used.

The sort of code that passes around functions tends to pass around many 
functions, but with only a few signatures.

If this is really the only time you'll need that signature (not even when you 
create the functions that will be passed from a calling site?), then ... great. 
 But be nice to your reader anyhow, unless the signature is really so simple 
that the type-checking software should infer it for you.  Then be nice by 
leaving it out as cruft.

[As an aside, I would see some advantage to 

def myfunc(f:like blobfunc) 

pointing to an examplar instead of a specifically constructed function-type.  
You discuss this later as either 

 ... f:blobfunc ... or 
 ... f:blobfunc=blobfunc ...

and I would support those, if other issues can be worked out.]

-jJ
___
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/ZDCSTHMZVSILZZMGI3GTTBTWB53ZRJOI/
Code of Conduct: http://python.org/psf/codeofconduct/