[Python-ideas] Re: Should Python enforce Type-checking in the future?
Some additional comments.
On Thu, Dec 09, 2021 at 08:32:43PM +, deavid wrote:
> 1) On really big codebases and complex projects, it's very easy to lose
> track of what things do. Types help detecting bugs early.
Static types help detecting *some* kinds of bugs early.
Python doesn't stop you from running static type checks on your code.
That's what mypy, and other type checkers, already do. What does
integration gain us apart from forcing people who care nothing about
static type checking to care, whether they want to or not?
> (Ask anyone that
> has used Rust + Clippy, the amount of errors that are catched is amazing,
> programs tend to work on the first try)
Isn't that a contradiction? If the work on the first try, then obviously
there weren't any errors to be caught. If there are errors that are
caught and need to be fixed, then it wasn't your first try.
In any case, I can often say the same about Python code, with no static
checking. Typically, after writing some functions, and fixing a handful
of typos -- I've been writing Python more than 20 years and I still
sometimes write {key=value} in dicts -- my unit tests Just Work.
(Unless they don't. *cough*)
But when they don't work, it's almost never *type* checks that fail. Its
logic errors and programming errors in the algorithm, and static typing
doesn't solve those.
> 2) Libraries are currently the top bottleneck for any team to start using
> MyPy/Pytype. Making types mandatory would ensure all libraries have type
> support.
Making types mandatory would more like ensure that many libraries would
just stop being supported and they would move to other languages.
> Of course, types have their own set of drawbacks; for example it could make
> Python look harder to code for newcomers, or it might get in the way for
> things like Jupyter notebooks, ML, and similar stuff.
Right.
> Because of this, an
> escape hatch must always exist. (maybe there are even more problems I am
> not aware about, I'd love to hear)
But if there is an escape hatch, then the types are not mandatory, and
many libraries will not use them, many projects will not use them, and
you have the status quo except mypy is bundled with CPython.
So all you will actually gain is avoiding running
pip install mypy
or whatever command you use to install it. That's a lot of disruption to
the entire Python ecosystem just so people can avoid installing mypy.
--
Steve
___
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/GRI6EDFFWVK355QVU5TDC3PNQEP5D3C4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python standard library TOML module
Yes. This is desperately needed. Usually I'm not a big fan of adding new standard library modules but in this case since toml is becoming such a critical part of packaging it seems like a no-brainer. ___ 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/B5T6TMAK2MSCQ4IV3VLRSFS6FBVGHRVN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
On Fri, Dec 10, 2021 at 12:03:15AM +, Gabriele N Tornetta wrote: > class Side(object): > def __getattribute__(self, name): > ValueError(name) You forgot to actually *raise* the exception. That will just instantiate the ValueError instance, and then immediately garbage collect it. In any case, type() and isinsance() do not work the same way. type() does not inspect the `__class__` attribute. ___ 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/GW6ZKJD3DQJUWPA4VP2IO3XYVCDRIIVA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
Hi David, I think there's an important distinction to be made between "enforcing types" as in "type annotations that are present are checked for consistency at compile time and enforced at runtime, instead of only being checked by a linter and possibly totally wrong at runtime" vs "enforcing types" as in "everything must always be fully typed." It seems that you are proposing both together, and so far readers are mostly reacting against the second. But I would like to observe that the one does not have to imply the other. I think requiring types everywhere is pretty much a non-starter for the Python language and community; the resulting language would no longer be Python, it would be a very different language with Python's syntax. But I think integrating optional types more closely into the language, so that users can trust that the type annotations that are present are not well-intentioned lies, and the compiler can make use of them to optimize some operations, increases the value of type annotations and the experience of using them, and can still fully allow for untyped and partially-typed code in the places where static types don't make sense (because the code is highly dynamic or because its just a quick script or prototype.) I currently work on a project we call "Static Python" (not a great name, since really it's fully dynamic Python with optional static types) which does exactly this. Types remain fully optional, the type system is gradual, but where you do specify annotations of types that are built-ins or are defined in modules opted into the Static Python compiler, you get compile-time type checking and runtime checks that the values used match the annotated types. This is currently only available if you use the fork of CPython in which we develop it [1]. We hope that at some point it may be possible to instead make it available as a pip-installable extension to normal CPython, but this is probably a long ways out yet. We are building this primarily for the performance benefits. The benefit of being able to use statically known and trusted type information to elide some costly dynamic operations more than makes up for the cost of the added runtime type checks, partly because our compiler is able to intelligently elide those runtime type checks in static-to-static calls, only checking when values first are passed in from untyped sources. This is early experimental work, and very far from anything that might be considered for mainstream CPython, but if you're interested in this area, you might find it worth taking a look at this early stage! Carl [1] https://github.com/facebookincubator/cinder ___ 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/ZM22AKAFIQDHF2E7VPHQ2DZJNBXPTRFM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
Another project you may want to look at is MyPyC [1], which is similar in concept but takes a different approach; it compiles type-annotated Python to CPython C extension code. MyPyC is much more mature and something you could easily try out today. Carl [1] https://github.com/mypyc/mypyc ___ 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/E66XKIJSQ2XWD4VVLE3CXZ5AJTKFBUVF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2
On 2021-12-09 12:47:28, Paul Bryan wrote: > On Thu, 2021-12-09 at 19:01 +, Simão Afonso wrote: > > I'm using docstrings bellow the attributes (analogous to functions > > and > > classes), I think it works well. > > It helps with distinguishing the class docstring from the arguments. > > I think you'll find on close inspection that those strings don't "go > anywhere" (i.e. they're not in help documentation, they're not > introspectable.) Wow, that's right, I stand corrected. They do appear on Sphinx auto-generated documentation, so I assumed it was a regular annotation, like classes and functions. ___ 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/KRMCFF7EH35X3SUKOAOLPAMWNCF2GHDJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On 12/6/2021 1:24 AM, Christopher Barker wrote: On Sun, Dec 5, 2021 at 10:38 AM David Mertz, Ph.D. wrote: I first discussed the idea of a "generalized deferred object/type" on this list at least two years ago, probably more than three (I haven't looked through archives lately to be sure the dates). The idea got some vague interest, but I was too lazy, or too busy, or whatever, to write an actual PEP or implementation. I don’t think a full PEP is required at this point, but throughout this discussion, the idea of a deferred object being a better solution to this same problem has been brought up. My sense it that some folks think if we want late-bound defaults, we really should just do deferred objects. But I honestly don’t get it. My idea of a deferred object would be quite different that this, would not be a great replacement for this, and could quite happily co-exist with this idea. Clearly I’m missing something. I've used this example before. Let's assume backticks create a "deferred object" (a name I hate, but I'll continue to use in this discussion). I realize backticks won't fly, I'm using them deliberately so as to not argue about the syntax here. If I want to specify a late bound dataclasses default parameter, currently I have to say: @dataclasses.dataclass class A: my_list: list = dataclasses.field(default_factory=list) What I'd like to be able to say: @dataclasses.dataclass class A: my_list: list = `[]` In the class A, before @dataclass is called, I want A.my_list to be a "deferred object" that I could then use when @dataclass is generating __init__(). Exactly how and when the "deferred object" would get evaluated is debatable, but not so important for the sake of this discussion. Suffice it to say that it would either be explicitly or implicitly evaluated at the start of __init__. I think you can see that this would benefit from similar functionality to late-bound parameters, and that if we had this more general mechanism that late-bound parameters could use the same underlying mechanism. Had these "deferred objects" existed when I designed dataclasses, I would have used them instead of the clunky default_factory. PEP 671 does not help with this use case, where a late-bound parameter isn't specified in a function definition. I need the late-bound parameter to be stored in an object I can refer to later. Eric ___ 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/MGXJ34KNQ3WIQMZJ7ETOFPPTJNT4AK3D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
I’m still not clear if this is a disagreement about something more than
terminology, but as I understand it, other languages that have non-constant
defaults use late binding, and call them “defaults”.
It seems to be a well accepted term.
-CHB
On Thu, Dec 9, 2021 at 12:45 AM Brendan Barnwell
wrote:
> On 2021-12-08 23:22, Chris Angelico wrote:
> > On Thu, Dec 9, 2021 at 5:54 PM Brendan Barnwell
> wrote:
> >>
> >> On 2021-12-08 20:36, Chris Angelico wrote:
> >> > Remember, though: The comparison should be to a function that looks
> like this:
> >> >
> >> > def f(a=[], b=_SENTINEL1, c=_SENTINEL2, d=_SENTINEL3):
> >> > if b is _SENTINEL1: b = {}
> >> > if c is _SENTINEL2: c = some_function(a, b)
> >> > if d is _SENTINEL3: d = other_function(a, b, c)
> >> >
> >> > If you find the long-hand form more readable, use the long-hand form!
> >> > It's not going away. But the introspectability is no better or worse
> >> > for these two. The late-bound defaults "{}", "some_function(a, b)",
> >> > and "other_function(a, b, c)" do not exist as objects here. Using PEP
> >> > 671's syntax, they would at least exist as string constants, allowing
> >> > you to visually see what would happen (and, for instance, see that in
> >> > help() and inspect.signature).
> >>
> >> I don't want to get bogged down in terminology but I am becoming
> >> increasingly frustrated by you using the term "default" both for things
> >> that are values and things that are not, as if there is no difference
> >> between them.
> >
> > That's absolutely correct: I am using the term "default" for anything
> > that provides a default for an optional argument that was omitted. In
> > some cases, they are default values. In other cases, they are default
> > expressions. If your docstring says "omitting d will use the length of
> > a", then the default for d is len(a).
>
> Your definition is somewhat circular, because you say that a
> default is
> "anything that provides a default". But that says "default" again. So
> what is a default?
>
> By your definition, any arbitrary code inside a function body that
> eventually assigns something to an argument name is a default. (It is
> not clear to me whether you would consider some code a default if it may
> or may not assign a value to an argument, depending on some conditions.)
> So I don't agree with that definition. That can be default BEHAVIOR,
> but it is function behavior; it is not an argument default.
>
> >> There are no late-bound defaults here, in the sense that
> >> I mean, which as I said before has to do with default VALUES. There is
> >> just code in the function body that does stuff. I am fine with code in
> >> a function body doing stuff, but that is the purview of the function and
> >> not the argument. An individual ARGUMENT having a default VALUE is not
> >> the same as the FUNCTION defining BEHAVIOR to deal with a missing value
> >> for an argument.
> >
> > In a technical sense, the default value for b is _SENTINEL1, but would
> > you describe that in the docstring, or would you say that omitting b
> > would use a new empty dictionary? You're getting bogged down, not in
> > terminology, but in mechanics. At an abstract level, the default for
> > that argument is whatever would be used if the argument is omitted.
>
> I don't agree. At an abstract level, there is no clear dividing
> line
> between what you call an argument default and just "arbitrary behavior
> of the function". What if "what would be used" depends on random
> numbers or data from some external source?
>
> Or, again, what you are describing is not an argument default (in
> my
> conception). It may be the BEHAVIOR of the function to do a certain
> thing (like use a certain value in place of an omitted argument) but
> unless that behavior is segmented and associated with the argument
> itself (not merely part of the function's code flow) I don't consider it
> an argument default.
>
> As for the docstring, yes, I might well mention _SENTINEL1 in the
> docstring. I certainly wouldn't see anything wrong with that. That's
> what the default is. Again, the function may USE that value in some
> way, but that doesn't mean that's not what the default is; it just means
> the function conditions its behavior on its argument value, as any
> function may do on any argument value, omitted or not. I get the
> impression you think that in a case like that the default "really is"
> something else defined in the body of the function, but again I
> disagree. The default really is _SENTINEL1. Conceptually we may
> understand that the function will use that value in a special way, but
> that is not really any different than understanding that passing "r" to
> open() will open the file for reading while passing "w" will open it for
> writing. It's just that to know how to use a function you need to know
> more than the default values of the arguments; you need t
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Thu, Dec 9, 2021 at 2:31 AM Paul Moore wrote > Your email client is doing "white on white" again. You should try to > get that fixed :-( Aarrgg— it was iPhone “dark mode” — white on black for me. Why the heck it preserves the text color (and not the background) is beyond me. I hope this works now. My point was more specific, though - that whenever deferred > expressions have been discussed in the past (and they do come up every > so often) it's fairly clear that one case they would be expected to > handle would be calculating function defaults at call time (at least, > that's my impression). So if they ever do get implemented, they would > render this PEP obsolete. But that’s exactly my question. I can see how a general purpose deferred expression system could be used for the implementation of late-bound defaults. But I can’t see how one would be both generally useful, and clear and simple when used for late bound defaults. Which is why I don’t think this PEP would be rendered obsolete— maybe the reference implementation would be, but syntax specific to late bound defaults would still be helpful. This is different than the switch-case example, where pattern matching is a clear superset. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/VYJHLMXARJTM5HSZPO4INUHWITUD5PG4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2
On Fri, Dec 10, 2021, 6:08 AM Simão Afonso wrote: > On 2021-12-09 12:47:28, Paul Bryan wrote: > > On Thu, 2021-12-09 at 19:01 +, Simão Afonso wrote: > > > I'm using docstrings bellow the attributes (analogous to functions > > > and > > > classes), I think it works well. > > > It helps with distinguishing the class docstring from the arguments. > > > > I think you'll find on close inspection that those strings don't "go > > anywhere" (i.e. they're not in help documentation, they're not > > introspectable.) > > Wow, that's right, I stand corrected. > > They do appear on Sphinx auto-generated documentation, so I assumed it > was a regular annotation, like classes and functions. > Very very interesting that Sphinx already treats a bare string under the parameter as documentation! I had no idea. Does it do the same thing at the module level? > ___ 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/U5D53FEEDHL6WXCQHTCOSTR3FTYQAVF6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python standard library TOML module
Yes please! It always seemed very odd to me that the standard packaging system would require a non-standard library. Surely TOML is stable enough by now? -CHB On Fri, Dec 10, 2021 at 4:06 AM Valentin Berlier wrote: > Yes. This is desperately needed. Usually I'm not a big fan of adding new > standard library modules but in this case since toml is becoming such a > critical part of packaging it seems like a no-brainer. > ___ > 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/B5T6TMAK2MSCQ4IV3VLRSFS6FBVGHRVN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/33BQIQVJAAJZWIYPZJRJLXLW5VOPXTKQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
On Fri, Dec 10, 2021 at 4:10 AM Carl Meyer wrote: > Another project you may want to look at is MyPyC [1], Or Cython, which has used a non-standard typing system for years, and is currently working on adopting the new types. It’s a very tricky business though, because Cython is generating C code, so it can’t use even semi-dynamic types. E.g. needs to know if something is an actual list, rather than a MutableSequence. I wonder how MyPyC handles that. Honestly, I’m concerned that the Trent towards static typing will turn Python into a very different language, as it’s much easy to use “locked down” static types than truly dynamic ones. E.g list rather than MutableSequence, or even better, the Protocol types. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/EIPYUMCJQ3SGNSGL54OMROP74RHCJLK3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2
On 2021-12-10 08:20:25, Ricky Teachey wrote: > Very very interesting that Sphinx already treats a bare string under the > parameter as documentation! I had no idea. Does it do the same thing at the > module level? Yes. > $ cat module.py > """This is the module docs""" > > class CLS: > """CLS docs""" > > attr: int > """CLS.attr doc""" ___ 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/HTFID5VQYMO65JACAPDTQDRXJVYWKLL7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python standard library TOML module
There is already some info/discussion over on the bug tracker: https://bugs.python.org/issue40059 Sebastian ___ 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/ZQOD6TEOWAB47WL2IMQS2W67IAKS46NR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
On Fri, Dec 10, 2021 at 08:32:27AM -0800, Christopher Barker wrote: > On Fri, Dec 10, 2021 at 4:07 AM Steven D'Aprano wrote: > > > > 1) On really big codebases and complex projects, it's very easy to lose > > > track of what things do. Types help detecting bugs early. > > > > Static types help detecting *some* kinds of bugs early. > > > Exactly. I’ve been advocating for Python for decades — and I think that > static type checking catches lots of bugs, but they are usually shallow > bugs — that is most get caught the first time you try to ru the code anyway > — or certainly if you have decent tests. That seems to be close to the opinion of Robert C Martin: http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html He also has some comments on languages like Koitlin and Swift that have gone down that path of mandatory static typing: http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html -- Steve ___ 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/374OAS5KUHWI3QS5J4KMXY6XERA45B3D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2
On Fri, Dec 10, 2021 at 11:46 AM Simão Afonso < simao.afo...@powertools-tech.com> wrote: > On 2021-12-10 08:20:25, Ricky Teachey wrote: > > Very very interesting that Sphinx already treats a bare string under the > > parameter as documentation! I had no idea. Does it do the same thing at > the > > module level? > > Yes. > > > $ cat module.py > > """This is the module docs""" > > > > class CLS: > > """CLS docs""" > > > > attr: int > > """CLS.attr doc""" I meant to ask about a (global) module member, not the module docstring itself. Like MY_GLOBAL below: """This is the module docs""" MY_GLOBAL = None """MY_GLOBAL docs""" class CLS: """CLS docs""" attr: int """CLS.attr doc""" Is this "global docstring" recognized by Sphinx as a docstring, too? --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler ___ 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/643W2H5YJZN7G5AAQUE4HL7VCAERVEUF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
Steven D'Aprano wrote:
> > That seems to be close to the opinion of Robert C Martin:
> http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html
> He also has some comments on languages like Koitlin and Swift that have
> gone down that path of mandatory static typing:
> http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html
Yet another example of "Uncle Bob" writing stuff that's "not even wrong". Of
course, typing doesn't catch all bugs; but neither does Uncle Bob's
testing-testing-testing. And never will. Programmers need all the help they can
in catching bugs and also in understanding other people's code - and types are
really helpful for that ... I can't count the number of hours I've spent at
Google, figuring out how something works so that I can add some functionality -
often by adding stuff like logging.info("Type of qqsv: %s", qqsv.__class_).
(On Mondays, Wednesdays, and Fridays, I think that mandatory typing would be
fabulous (to paraphrase Brian Reid: "most people won't use types even when you
threaten them"). On Tuesdays, Thursdays, and Saturdays, I meditate on how
difficult it is to write types in Haskell, which is far easier for typing than
Python. On Sundays, I go for a head-clearing walk in the park.)
PS: For another example of "Uncle Bob" nonsense:
https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ
___
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/L6FPYNFJKFJPD4Z4NHVP2E5BXERDDPT4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2
On 2021-12-10 12:20:44, Ricky Teachey wrote: > I meant to ask about a (global) module member, not the module docstring > itself. Like MY_GLOBAL below: > > """This is the module docs""" > > MY_GLOBAL = None > """MY_GLOBAL docs""" > > class CLS: >"""CLS docs""" > >attr: int >"""CLS.attr doc""" > > Is this "global docstring" recognized by Sphinx as a docstring, too? My bad. Double checked and that's right, it is recognised as such. ___ 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/XWTA2CRUUUAGSBG3O6TIYDQNSOWLXGD5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
On Thu, 9 Dec 2021 at 17:54, deavid wrote: > Hi, I would like to hear the opinion of Python's community on enforcing > types in the future for the language. > here goes opinion: "no"! strong no. while _using_ tooling that have correct typing is a bit easier, it can make it hard to write code, code harder to read, and in some instances, simply make it almost impossible type correctly what once has been one of the best features of the language: things that are broad into what they accept, strict in what they return, while not being ambiguous. As an example, I will let you with the buitin functions "min" and "max". Write teh pure-Python correct annotation for those, and you will understand what people mean by "typing can be painful". Moreover, you missed that there are very different profiles of Python users. Professional coders working in big projects can take advantage of all the points you listed - but a lot of people just want a way to "give orders to the computer". ___ 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/X7WS7IOT5Q7ECXIX3OWXQSEHY5A7PMFS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
Well, this has a lot of strong opinions already! I didn't expect less :-) I'm not sure how to answer so many thoughts without making this super-long. I'll try to reply in general. I agree that a compile-time python makes no sense, it would be a different language and we would lose 90% of what Python actually is. This is not what I was suggesting (sorry, I might not have been clear on my first email). I'm talking about something similar to what Typescript is. (mypy even when strict, is closer to what Typescript does than to C++/Rust) But there must be a way to skip typing altogether, both in programs and libraries. (It could also be by file extension... just suggesting more stuff here) When I said earlier in "compile time", I was just trying to refer to the parsing step, or pre-parsing step. Or maybe means that "python a.py" => "mypy a.py && python a.py". I'm being very ambiguous here on purpose because there are tons of ways to do this and "how to do it" or the cons of a particular method aren't something that I wanted to discuss, I just wanted to get a general idea of where the community stands. A lot of you are referring to scripting, learning, and other ways of using Python that would be badly impacted. I already acknowledged that these exist (or at least I didn't notice here any other that I wasn't aware), and that's why I mentioned that there should be a way to avoid type-enforcing for these scenarios. Maybe by flag, by Python version, file extension... The method doesn't matter much at this moment. If it were "easy" to continue writing the old programs without types, what's the problem in trying to make types more popular? And yes, types cannot cover everything. I guess this goes for any language, but especially in Python it is really impossible to type everything. But as Typescript has demonstrated (I think), having a bit of types is better than no types at all. MyPy is there for those that want to use it, of course; but needs to be promoted (this one or different tool) and encouraged. Otherwise most python libraries are just impossible to use with MyPy; and using Python without libraries is quite limiting. >> Exactly. I’ve been advocating for Python for decades — and I think that >> static type checking catches lots of bugs, but they are usually shallow >> bugs — that is most get caught the first time you try to ru the code anyway >> — or certainly if you have decent tests. > >That seems to be close to the opinion of Robert C Martin: This is not true unless your testing covers every branch in every possible state input. This also means that your unit testing in dynamic languages needs to be way more extensive than in static languages; because static checking gives you certain proofs of correctness that you don't need to test. More importantly, it removes the burden of remembering to do those test cases for those tricky scenarios. Overall, your tests will be shorter and easier to maintain. But I would say that even with extensive testing still will not cover all bugs that static type checks can catch: static type checks also can cover future bugs, not only present ones. A type check will prevent someone from calling a function/method in unexpected ways. Because type checks serve to define contracts, and 6 months later you might have forgot that the function assumed certain constraints for the input. > Another project you may want to look at is MyPyC [1], which is similar > in concept but takes a different approach; it compiles type-annotated > Python to CPython C extension code. MyPyC is much more mature and > something you could easily try out today. > [1] https://github.com/mypyc/mypyc There you have it. I'm amazed that this is already a thing and the discussion of "enforcing types" didn't happen up to now. If MyPyC can compile to C and get a 4x performance boost, it means that Python is leaving a 4x boost on the table. When creating the bytecode (old *.pyc files) Python could create for some functions a second one that internally doesn't use Python objects, for those cases where the types actually match. And the GIL could be released (sometimes) during the execution of those. (It might look that the above statement is far too simplistic. But it should be roughly true with lots of caveats.) Anyway, I see that people are generally against what I'm suggesting. But on the other hand I also see that there are projects that are working towards faster python implementations via type-checking. I now noticed that PyPI includes filters for typed packages; I didn't recall this from 3 years ago. I wish they promoted typed ones a bit more, but well, at least we can filter. El vie, 10 dic 2021 a las 17:49, Peter Ludemann () escribió: > Steven D'Aprano wrote: > > > > That seems to be close to the opinion of Robert C Martin: > > http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html > > He also has some comments on languages like Koitlin and Swift that have > > gone down that path of ma
[Python-ideas] Re: Should Python enforce Type-checking in the future?
On Sat, Dec 11, 2021 at 7:44 AM deavid wrote: > When I said earlier in "compile time", I was just trying to refer to the > parsing step, or pre-parsing step. Or maybe means that "python a.py" => "mypy > a.py && python a.py". > I'm being very ambiguous here on purpose because there are tons of ways to do > this and "how to do it" or the cons of a particular method aren't something > that I wanted to discuss, I just wanted to get a general idea of where the > community stands. > You could make a shell alias that does that, if that's what you want. > A lot of you are referring to scripting, learning, and other ways of using > Python that would be badly impacted. I already acknowledged that these exist > (or at least I didn't notice here any other that I wasn't aware), and that's > why I mentioned that there should be a way to avoid type-enforcing for these > scenarios. Maybe by flag, by Python version, file extension... The method > doesn't matter much at this moment. > If it were "easy" to continue writing the old programs without types, what's > the problem in trying to make types more popular? > Or by simply running Python without first running MyPy. That's a method. > > Another project you may want to look at is MyPyC [1], which is similar > > in concept but takes a different approach; it compiles type-annotated > > Python to CPython C extension code. MyPyC is much more mature and > > something you could easily try out today. > > [1] https://github.com/mypyc/mypyc > > There you have it. I'm amazed that this is already a thing and the discussion > of "enforcing types" didn't happen up to now. > If MyPyC can compile to C and get a 4x performance boost, it means that > Python is leaving a 4x boost on the table. When creating the bytecode (old > *.pyc files) Python could create for some functions a second one that > internally doesn't use Python objects, for those cases where the types > actually match. And the GIL could be released (sometimes) during the > execution of those. > (It might look that the above statement is far too simplistic. But it should > be roughly true with lots of caveats.) > >From the MyPyC docs: """These are our near-term focus areas for improving mypyc: * Improved compatibility with Python""" The 4x speed boost is only if you restrict yourself to the things it can handle. That's fine if a project specifically chooses to do that, but not for general work. And it is definitely NOT a reason to push type checking into the core language. Side question: What if someone wants to use a different type checker than MyPy? Why should that one single checker be blessed with language support? Type annotations are intended to be there for *every* type checker to use. ChrisA ___ 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/NCZZZNH34SNOZZ434GFKEMI5OCA4XHQ6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
On 2021-12-10 at 20:20:05 +, deavid wrote: > A lot of you are referring to scripting, learning, and other ways of > using Python that would be badly impacted. I already acknowledged that > these exist (or at least I didn't notice here any other that I wasn't > aware), and that's why I mentioned that there should be a way to avoid > type-enforcing for these scenarios. Maybe by flag, by Python version, > file extension... The method doesn't matter much at this moment. If > it were "easy" to continue writing the old programs without types, > what's the problem in trying to make types more popular? I concede that certain programmers believe that type declarations and static type checking are unilaterally and universally beneficial, and that's why I think that there should be a way to request type-enforcing for these scenarios. Maybe by flag, by Python version, file extension... The method doesn't matter, because in all my decades of writing software, in a dozen or more languages, getting the types right at coding time has never been an issue. It's very easy to get type checking if you want it, what's the problem in trying to make types more popular? [insert your own perfect-joking-serious-balance emoticon (no emoji, please!) here] ___ 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/LQ4CQOKHQXI6QTTYSFFCXPVZR26W3MPI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
Hi, (NB: I'm just a lurker here, posting for almost the first time. I may say silly things.) Le 09/12/2021 à 21:32, deavid a écrit : Hi, I would like to hear the opinion of Python's community on enforcing types in the future for the language. I've been using Python as my main language for everything for around 10 years, until I started moving to Rust 2 years ago; one of the main factors was types. Just before moving to Rust I started to use mypy heavily, which I liked a lot and uncovered tons of potential problems. Now (2 years later), it seems the situation hasn't changed much; I might be wrong, so let me know what improvements you think landed in this area in the last 2-3 years. I don't follow typing closely at all, but I do nevertheless see quite a number of typing PEPs getting accepted. Here are a few recent ones gathered just by reading the index in PEP 0: https://www.python.org/dev/peps/pep-0589/ https://www.python.org/dev/peps/pep-0586/ https://www.python.org/dev/peps/pep-0585/ https://www.python.org/dev/peps/pep-0591/ https://www.python.org/dev/peps/pep-0593/ https://www.python.org/dev/peps/pep-0604/ https://www.python.org/dev/peps/pep-0612/ https://www.python.org/dev/peps/pep-0613/ https://www.python.org/dev/peps/pep-0647/ I feel it's possible this topic might cause a lot of passionate answers, but I just want to hear honest opinions on this. I firmly believe that Python's future would be better if types were enforced by default at "compile time" (whatever this means in Python), with an option/flag to disable this, and integrate MyPy or similar into the interpreter. I'm fully aware that a transition like this would be very hard and long, but I don't think it's impossible. Here's a list of my reasons to think that Python is better if it was typed: 1) On really big codebases and complex projects, it's very easy to lose track of what things do. Types help detecting bugs early. (Ask anyone that has used Rust + Clippy, the amount of errors that are catched is amazing, programs tend to work on the first try) 2) Libraries are currently the top bottleneck for any team to start using MyPy/Pytype. Making types mandatory would ensure all libraries have type support. (If anyone has any other proposal to enforce this, I would like to hear) 3) IDE integration is way simpler and better with types. 4) The interpreter could take further optimizations if it can prove that a function or piece of code is guaranteed to have a limited set of types. This could be used by libraries to have great speed ups that currently are not possible. 5) Static analysis tools could also benefit from types to gain more insight on what the code is trying to do. These are benefits of types in general, but I don't see clearly how having checks built as part of the standard CPython interpreter will increase them. Performance perhaps, but the projects using annotations to eliminate runtime overhead are in experimental stage. Asking a genuine question here: is it actually possible to generate optimized code that supports all of Python? What about things like int subclasses? MyPyC doesn't support them as far as I can see, and I don't see how it could when trying to generate optimized code. It might only optimize int operations when it can prove that all callers don't pass int subclasses, but this means recompiling when a new caller does pass a subclass -- which turns Python into far more of a compiled language. Or am I missing something? On the other hand, with the specializing adaptive that is the result of the Faster CPython project, it might become eventually possible to specialize based on types, and have a cheaper code path when the annotation is int that will still fall back to a slower path when an int subclass instance is passed. Also, you seem to imply that having typing more tied to the core language will bring it more popularity. How will this happen exactly? People don't like it when you break their code. If Python 4 causes trouble for users who don't need/want typing, these users will not suddenly start using typing, but simply stay with Python 3. You'd apparently want to require libraries to be annotated for them to support Python 4, which means pain that the ecosystem simply cannot afford, I think. -- And if the annotations remain optional, then I guess I don't really understand how it's going to push people to add them, especially on large libraries, where this is a significant endeavor. All the best, Jean ___ 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/YU2CL5VLW5RPPNNKGFMLDDNRJMSXG5U7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On 12/9/2021 10:32 AM, Eric V. Smith wrote: On 12/6/2021 1:24 AM, Christopher Barker wrote: But I honestly don’t get it. My idea of a deferred object would be quite different that this, would not be a great replacement for this, and could quite happily co-exist with this idea. Clearly I’m missing something. I've used this example before. Let's assume backticks create a "deferred object" (a name I hate, but I'll continue to use in this discussion). I realize backticks won't fly, I'm using them deliberately so as to not argue about the syntax here. If I want to specify a late bound dataclasses default parameter, currently I have to say: @dataclasses.dataclass class A: my_list: list = dataclasses.field(default_factory=list) What I'd like to be able to say: @dataclasses.dataclass class A: my_list: list = `[]` In the class A, before @dataclass is called, I want A.my_list to be a "deferred object" that I could then use when @dataclass is generating __init__(). Exactly how and when the "deferred object" would get evaluated is debatable, but not so important for the sake of this discussion. Suffice it to say that it would either be explicitly or implicitly evaluated at the start of __init__. I think you can see that this would benefit from similar functionality to late-bound parameters, and that if we had this more general mechanism that late-bound parameters could use the same underlying mechanism. And in case I wasn't clear: to get the late-bound parameter functionality using this syntax, you'd use: def foo(my_list = `[]`): That's why I think we should have a larger concept that just late-bound parameters: I think there's a general concept here that can be extended beyond parameters. And that's why I thing not restricting it to a function-definition-only syntax is important: we should produce a syntax that can be used in more places than just functions. This is why I think we need to decide on this larger scope before accepting the narrow function-definition-only syntax: if we decide to add "deferred objects" later, we'd have two ways to specify late-bound parameters [0]. Eric [0]: Or arguments, I can never remember which is which: someone needs to invent a memorable mnemonic device. Had these "deferred objects" existed when I designed dataclasses, I would have used them instead of the clunky default_factory. PEP 671 does not help with this use case, where a late-bound parameter isn't specified in a function definition. I need the late-bound parameter to be stored in an object I can refer to later. Eric ___ 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/T62V6IMOJDADAFWJ2DIAS4WHJQMI4CHU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sat, Dec 11, 2021 at 9:26 AM Eric V. Smith wrote: > > On 12/9/2021 10:32 AM, Eric V. Smith wrote: > > On 12/6/2021 1:24 AM, Christopher Barker wrote: > > > > But I honestly don’t get it. My idea of a deferred object would be quite > different that this, would not be a great replacement for this, and could > quite happily co-exist with this idea. Clearly I’m missing something. > > I've used this example before. > > Let's assume backticks create a "deferred object" (a name I hate, but I'll > continue to use in this discussion). I realize backticks won't fly, I'm using > them deliberately so as to not argue about the syntax here. > > If I want to specify a late bound dataclasses default parameter, currently I > have to say: > > @dataclasses.dataclass > class A: > my_list: list = dataclasses.field(default_factory=list) > > What I'd like to be able to say: > > @dataclasses.dataclass > class A: > my_list: list = `[]` > > In the class A, before @dataclass is called, I want A.my_list to be a > "deferred object" that I could then use when @dataclass is generating > __init__(). Exactly how and when the "deferred object" would get evaluated is > debatable, but not so important for the sake of this discussion. Suffice it > to say that it would either be explicitly or implicitly evaluated at the > start of __init__. > > I think you can see that this would benefit from similar functionality to > late-bound parameters, and that if we had this more general mechanism that > late-bound parameters could use the same underlying mechanism. > > And in case I wasn't clear: to get the late-bound parameter functionality > using this syntax, you'd use: > > def foo(my_list = `[]`): > > That's why I think we should have a larger concept that just late-bound > parameters: I think there's a general concept here that can be extended > beyond parameters. And that's why I thing not restricting it to a > function-definition-only syntax is important: we should produce a syntax that > can be used in more places than just functions. This is why I think we need > to decide on this larger scope before accepting the narrow > function-definition-only syntax: if we decide to add "deferred objects" > later, we'd have two ways to specify late-bound parameters [0]. > It's larger than argument defaults, but also smaller: def bisect(a, hi=`len(a)`): Would this work by your theory? Remember that it must still be possible to pass a simple number (eg bisect(stuff, 5)), so the default needs to coalesce to an actual value immediately. The overlap with late-bound defaults is the simple case of mutable objects that you want to freshly construct every time, but ultimately, that's not hugely different from a lambda function: stuff = defaultdict(lambda: []) stuff = defaultdict(`[]`) The only difference might be that you could use isinstance to distinguish a deferred expression from some other sort of function. I'm not sure whether that would be significant enough for dataclasses to take advantage of. (Another theoretical difference is that a deferred expression is parsed in the context of its *usage* rather than its *definition*, but that would break all manner of things in Python and is quite impractical.) ChrisA ___ 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/C4E3UZRFUM7UHSFLX3JIUZJ57I7TCTRA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On 2021-12-10 at 17:24:22 -0500, "Eric V. Smith" wrote: > [0]: Or arguments, I can never remember which is which: someone needs > to invent a memorable mnemonic device. Pass Arguments Accept Parameters (I don't know. I just made that up. For some reason, the fact that functions have "formal parameters" stuck with me (to me?) from somewhere, and then I can put the pieces together to figure out where the arguments must come from. And you can't unsee it now; sorry.) ___ 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/3KR5WACTXRJQDNXNEBQ6RXEYKNDBXGPN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sat, Dec 11, 2021 at 9:43 AM <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 2021-12-10 at 17:24:22 -0500, > "Eric V. Smith" wrote: > > > [0]: Or arguments, I can never remember which is which: someone needs > > to invent a memorable mnemonic device. > > Pass Arguments > Accept Parameters > > (I don't know. I just made that up. For some reason, the fact that > functions have "formal parameters" stuck with me (to me?) from > somewhere, and then I can put the pieces together to figure out where > the arguments must come from. And you can't unsee it now; sorry.) Formal parameters are the placeholders - the variable names that receive values. Arguments or "actual parameters" are what got used when the function got called. An optional parameter can have a default argument which is used when there is no argument passed. In some languages, a parameter can be optional without a default, in which case it won't have a value, but in current Python, defaults and optionality always go together. Whether 'self' counts as a parameter, and whether the object to the left of the dot counts as an argument, depends on your point of view. :) ChrisA ___ 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/77VNOGOZ43IN4WIUULX6FJMHFDL4CDQD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
>> a memorable mnemonic device. > Pass Arguments > Accept Parameters Darn — the P and A are swapped there. But that’s the paradox with mnemonics — that may help me remember it :-) -CHB > > > (I don't know. I just made that up. For some reason, the fact that > functions have "formal parameters" stuck with me (to me?) from > somewhere, and then I can put the pieces together to figure out where > the arguments must come from. And you can't unsee it now; sorry.) > ___ > 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/3KR5WACTXRJQDNXNEBQ6RXEYKNDBXGPN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/GQ5F3WXTXOLKABLXEFH6AI7PRU45OGGD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: inline Python functions and methods
So I went back and revised my idea for inline functions in python, and I realized that it would be harder to implement them in python the way I had originally thought about them, due to Python’s dynamic nature. However, the idea itself doesn’t seem so original, as Cinder already implements inline byte-code caching which significantly boosts its performance. I do not think they ever upstreamed these changes however. So a modification of my idea goes like this. The inline functions can still be written with the inline keyword, but evaluated at runtime. This is because there are some cases such as in conditions where are function might never be called at all, so it wouldn’t need to be optimized in that case so in cases where someone writes code like, if True: inline def func_version_one(*args): #func body pass else: inline def func_version_two(*args): #func body pass The right function to perform inlining on shall be determined at runtime and cached in the same scope as where it’s performing it’s operations from cases where the program performs large iterations or even in infinite loops and other cases that need optimization. Like I said before, it’s still a work-in-progress, and I’m still putting lots of factors into consideration, including your incredible insight as the core dev team. ___ 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/J44HVJLGKYA4I62WJDQTUZCOUQI2IU2H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings – take 2
Simão Afonso writes: > On 2021-12-10 12:20:44, Ricky Teachey wrote: > > I meant to ask about a (global) module member, not the module docstring > > itself. Like MY_GLOBAL below: > > > > """This is the module docs""" > > > > MY_GLOBAL = None > > """MY_GLOBAL docs""" > > > > Is this "global docstring" recognized by Sphinx as a docstring, too? > > My bad. > > Double checked and that's right, it is recognised as such. To my mind Sphinx is sufficiently widely used that this settles the "above or below" question. Steve ___ 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/EQKNZVG3NQBSTDYHLYWNW2A3U6E2MRXZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
Eric V. Smith writes: > That's why I think we should have a larger concept that just late-bound > parameters: I think there's a general concept here that can be extended > beyond parameters. One advantage of Chris's preferred syntax is that as a default in a function's parameter list it could do whatever it needs to do there, while in an executable context, it could return the object, as := does. That's a bit inconsistent and quite ugly, I guess, and it might lead to code like def foo(x=>[]): a = bar() return x foo(x=>[a]) which I think would be rather confusing. Whether it would be acceptable is a question of how often it would be used as an assignment expression rather than as an assignment statement. I think I've just convinced myself this is a non-starter, but I'll leave it in as documentation that defining the syntax is a nontrivial issue. > later, we'd have two ways to specify late-bound parameters [0]. We might want that anyway. One of the aspects of Chris's proposal is that late-bound parameters get resolved to objects in a well-specified (if complicated) order at call time, before entering the function body. In foo(x=othermodule.bar()) the compiler cannot know that x's value is a "deferred object" (aside: how about "autoevaluated expression object", presumably with an abbreviated form such as "autoeval" for normal use). I don't see how we can guarantee order of evaluation without syntax for late binding of parameters. I think the predictability is a potentially valuable aspect of Chris's proposal that might justify special syntax for late-bound defaults of formal arguments.[1] > [0]: Or arguments, I can never remember which is which: someone needs to > invent a memorable mnemonic device. C: argv and argc refer to the actual arguments, not the parameter list. I just use "formal" vs. "actual" to modify "argument". Footnotes: [1] I write "potential" not to deprecate it but because I have no particular use case for late-bound defaults that demands them, rather than the sentinel idiom. So I have no sense whether this predictability is a big deal. ___ 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/2Y5GOHDLAWWP5D337BWVRISW65M3Q5CW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sat, Dec 11, 2021 at 5:35 PM Stephen J. Turnbull wrote: > > Eric V. Smith writes: > > > That's why I think we should have a larger concept that just late-bound > > parameters: I think there's a general concept here that can be extended > > beyond parameters. > > One advantage of Chris's preferred syntax is that as a default in a > function's parameter list it could do whatever it needs to do there, > while in an executable context, it could return the object, as := > does. That's a bit inconsistent and quite ugly, I guess, and it might > lead to code like > > def foo(x=>[]): > a = bar() > return x > > foo(x=>[a]) > > which I think would be rather confusing. Whether it would be > acceptable is a question of how often it would be used as an > assignment expression rather than as an assignment statement. I'm not sure what that last line would mean. My proposal doesn't change the call site in any way, so I'm trying to figure out what you mean by that call. Are you saying that x=>[a] would be an assignment statement that sets x to an unevaluated expression? If so, that's independent of the default argument. If it's a special way to pass keyword arguments to a function, which passes unevaluated expressions that are collapsed into values upon usage, then this would be extremely interesting, but highly bizarre behaviour. It would also require significant changes to the way that nonlocal names are looked up (or would be restricted in what nonlocals it can refer to, possibly none at all). > > later, we'd have two ways to specify late-bound parameters [0]. > > We might want that anyway. One of the aspects of Chris's proposal is > that late-bound parameters get resolved to objects in a well-specified > (if complicated) order at call time, before entering the function > body. In > > foo(x=othermodule.bar()) > > the compiler cannot know that x's value is a "deferred object" (aside: > how about "autoevaluated expression object", presumably with an > abbreviated form such as "autoeval" for normal use). I don't see how > we can guarantee order of evaluation without syntax for late binding > of parameters. I think the predictability is a potentially valuable > aspect of Chris's proposal that might justify special syntax for > late-bound defaults of formal arguments.[1] Indeed. But here's the question: If a deferred object is to be a replacement for default_factory, then it must by definition be able to be stored for later. So it can't be autoevaluated unless there's some mechanism for delaying the autoevaluation. This seems like an incredibly messy approach. The use-cases for deferred evaluation differ based on whether you need it to be evaluated once or multiple times, whether you want names to be looked up in the caller's or the callee's context, etc, etc, etc. What would have overlap with argument defaults isn't the same thing that would be useful for dataclasses. So there would need to be multiple variants, or multiple ways to use them. ChrisA ___ 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/OW2VX4FJPTVMNVV3TBJCO6TJEV37ZAJX/ Code of Conduct: http://python.org/psf/codeofconduct/
