Aw: Re: Any possible type alias that can also set a default value for a function arg?
> > or something like that. Basically, any way to avoid writing `= None` over > > and over again. > > Fundamentally no, at least not without some shenanigans. Type hints do > not affect the regular running of the code, Except when they do ;-) ... depending on what counts as (valid) code ... In Python a distinction can be made between "runnable" and "valid" :-D Karsten -- https://mail.python.org/mailman/listinfo/python-list
Re: Re: Any possible type alias that can also set a default value for a function arg?
On Thu, 19 Oct 2023 at 18:04, Karsten Hilbert wrote: > > > > or something like that. Basically, any way to avoid writing `= None` over > > > and over again. > > > > Fundamentally no, at least not without some shenanigans. Type hints do > > not affect the regular running of the code, > > Except when they do ;-) > > ... depending on what counts as (valid) code ... > > In Python a distinction can be made between "runnable" and "valid" :-D > Can you give a counter-example? I mean, yes, any code can be written that inspects the annotations at runtime and makes whatever changes it likes, but that's part of what I described as "shenanigans". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Re: Any possible type alias that can also set a default value for a function arg?
> > > Fundamentally no, at least not without some shenanigans. Type hints do
> > > not affect the regular running of the code,
> >
> > Except when they do ;-)
> >
> > ... depending on what counts as (valid) code ...
> >
> > In Python a distinction can be made between "runnable" and "valid" :-D
> >
>
> Can you give a counter-example?
As per my recent foray into abusing existence-checking for Singleton assurance
along such lines as
>>> try: self.initialized
>>> except AttributeError: print('first instantiation'); self.initialized = True
and then changing that to
>>> try: self.initialized:bool
Karsten
--
https://mail.python.org/mailman/listinfo/python-list
Re: Re: Re: Any possible type alias that can also set a default value for a function arg?
On Thu, 19 Oct 2023 at 18:25, Karsten Hilbert wrote:
>
> > > > Fundamentally no, at least not without some shenanigans. Type hints do
> > > > not affect the regular running of the code,
> > >
> > > Except when they do ;-)
> > >
> > > ... depending on what counts as (valid) code ...
> > >
> > > In Python a distinction can be made between "runnable" and "valid" :-D
> > >
> >
> > Can you give a counter-example?
>
> As per my recent foray into abusing existence-checking for Singleton assurance
> along such lines as
>
> >>> try: self.initialized
> >>> except AttributeError: print('first instantiation'); self.initialized =
> >>> True
>
> and then changing that to
>
> >>> try: self.initialized:bool
But that's not equivalent code. You might just as well say that the
ellipsis here suddenly changes the code:
self.initialized
self.initialized = ...
These are completely different, and they behave differently. Both are
valid, but they mean different things.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Re: Re: Any possible type alias that can also set a default value for a function arg?
> > As per my recent foray into abusing existence-checking for Singleton
> > assurance
> > along such lines as
> >
> > >>> try: self.initialized
> > >>> except AttributeError: print('first instantiation'); self.initialized =
> > >>> True
> >
> > and then changing that to
> >
> > >>> try: self.initialized:bool
>
> But that's not equivalent code.
I learned as much (RHS vs LHS).
But it did not _intuitively_ resonate with the sentiment
"type annotation does not change the running of code".
Karsten
--
https://mail.python.org/mailman/listinfo/python-list
Re: Re: Re: Re: Any possible type alias that can also set a default value for a function arg?
On Thu, 19 Oct 2023 at 19:34, Karsten Hilbert wrote:
>
> > > As per my recent foray into abusing existence-checking for Singleton
> > > assurance
> > > along such lines as
> > >
> > > >>> try: self.initialized
> > > >>> except AttributeError: print('first instantiation'); self.initialized
> > > >>> = True
> > >
> > > and then changing that to
> > >
> > > >>> try: self.initialized:bool
> >
> > But that's not equivalent code.
>
> I learned as much (RHS vs LHS).
>
> But it did not _intuitively_ resonate with the sentiment
> "type annotation does not change the running of code".
Unfortunately, that simply means that your intuition was wrong. It
doesn't change my prior statement.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Where I do ask for a new feature
> You can actually just do that with simple assignment! > > short_view = my_object.stuff.long_stuff.sub_object > print(short_view.some_method()) but then have to delete the variable manually del short_view -- https://mail.python.org/mailman/listinfo/python-list
RE: Where I do ask for a new feature
Bongo, Variables in most programming languages either have to be removed manually or allowed to drift outside a boundary when they disappear for scoping reasons and perhaps are garbage collected at some point. There are many ways to make transient variables that disappear at some time and do we need yet another? Yes, you can create one of those ways but what is the big deal with deleting a variable when no longer used? Examples might be the "finally" clause or the "with" statement or just putting the variable in a nested scope. -Original Message- From: Python-list On Behalf Of Bongo Ferno via Python-list Sent: Thursday, October 19, 2023 9:33 PM To: [email protected] Subject: Re: Where I do ask for a new feature > You can actually just do that with simple assignment! > > short_view = my_object.stuff.long_stuff.sub_object > print(short_view.some_method()) but then have to delete the variable manually del short_view -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Where I do ask for a new feature
On Thursday, October 19, 2023 at 11:26:52 PM UTC-3, [email protected] wrote: > There are many ways to make transient variables that disappear at some time > and do we need yet another? Yes, you can create one of those ways but what > is the big deal with deleting a variable when no longer used? Assigning a variable to something can be anything else than a temporal alias. A with statement makes clear that the alias is an alias and is local, and it automatically clears the variable after the block code is used. Python clutters the variable space with vars that are needed only on certain places, and an alias doesn't has a scope. Convenient alias are short names, and short names are limited in quantity. If the space is cluttered with short alias, it opens risks for wrong utilization. Its like writing a "for i" in a list comprehension and having to worry if "i" was already used in another place.. -- https://mail.python.org/mailman/listinfo/python-list
Re: Where I do ask for a new feature
On 19Oct2023 20:16, Bongo Ferno wrote:
A with statement makes clear that the alias is an alias and is local,
and it automatically clears the variable after the block code is used.
No it doesn't:
>>> with open('/dev/null') as f:
... print(f)
...
<_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>
>>> print(f)
<_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>
--
https://mail.python.org/mailman/listinfo/python-list
