[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Petr Viktorin]

On 2/2/21 12:36 PM, Stefano Borini wrote:

Hi all,

I would like to request feedback by python-dev on the current
implementation of PEP 637 - Support for indexing with keyword
arguments.

https://www.python.org/dev/peps/pep-0637/

The PEP is ready for SC submission and it has a prototype
implementation ready, available here (note, not reviewed, but
apparently fully functional)

https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2

(note: not sure if there's a preference for the link to be to the diff
or to the branch, let me know if you prefer I change the PEP link)

Thank you for your help.


+1 from me. This looks quite useful in certain areas and natural to use. 
I like how this makes the dunder implementations (usually libraries), 
rather than users, deal with most of the corner cases -- but still 
allows libraries that don't need this to not care.



The PEP does lack a "How to teach" section.


"Corner case 3" concludes that "best practice suggests that keyword 
subscripts should be flagged as keyword-only when possible":


def __getitem__(self, index, *, direction='north'):

If the PEP is accepted, this should be mentioned in the 
__(get|set|del)item__ documentation and shown in all relevant examples.


Looking at corner case 1, it would also be useful to nudge people to use 
positional-only arguments whenever they accept arbitrary keyword ones. 
(The same goes for function definitions, but tutorials for those are 
already written):


def __getitem__(self, index, /, **named_axes):

It would be great if what gets copied to StackOverflow is examples of 
good practices :)

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

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

[Greg Ewing]

On 3/02/21 10:35 pm, Phil Thompson wrote:

On 02/02/2021 23:08, Greg Ewing wrote:

you have no idea what
kind of C struct it expects to get.


I had assumed that some other magic in typeobject.c (eg. conflicting 
meta-classes) would have raised an exception before getting to this 
stage if there was a conflict.


"No idea" is probably an exaggeration -- there is checking
to ensure that all the C structs involved form a sequence
of extensions. But they still need to be initialised in the
right order, because __new__ methods for later ones assume
that the struct they're extending has already been
initialised.

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

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Paul Bryan]

I like.

On Wed, 2021-02-03 at 15:48 -0800, Guido van Rossum wrote:
> Anyone? I'm +1 on this PEP as it is, and I imagine a few other core
> devs are too (Brandt, Steven). If nobody responds before the end of
> the week I think we can say that there was no disagreement and
> Stefano can submit PEP 637 to the SC.
> 
> On Tue, Feb 2, 2021 at 3:43 AM Stefano Borini
>  wrote:
> > Hi all,
> > 
> > I would like to request feedback by python-dev on the current
> > implementation of PEP 637 - Support for indexing with keyword
> > arguments.
> > 
> > https://www.python.org/dev/peps/pep-0637/
> > 
> > The PEP is ready for SC submission and it has a prototype
> > implementation ready, available here (note, not reviewed, but
> > apparently fully functional)
> > 
> >
> https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2
> > 
> > (note: not sure if there's a preference for the link to be to the
> > diff
> > or to the branch, let me know if you prefer I change the PEP link)
> > 
> > Thank you for your help.
> > 
> > 
> > -- 
> > Kind regards,
> > 
> > Stefano Borini
> > ___
> > 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/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> ___
> 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/67ZLIDZPKQA2BVDNSRUQUUTPO7ZB4OIE/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Guido van Rossum]

Anyone? I'm +1 on this PEP as it is, and I imagine a few other core devs
are too (Brandt, Steven). If nobody responds before the end of the week I
think we can say that there was no disagreement and Stefano can submit PEP
637 to the SC.

On Tue, Feb 2, 2021 at 3:43 AM Stefano Borini 
wrote:

> Hi all,
>
> I would like to request feedback by python-dev on the current
> implementation of PEP 637 - Support for indexing with keyword
> arguments.
>
> https://www.python.org/dev/peps/pep-0637/
>
> The PEP is ready for SC submission and it has a prototype
> implementation ready, available here (note, not reviewed, but
> apparently fully functional)
>
>
> https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2
>
> (note: not sure if there's a preference for the link to be to the diff
> or to the branch, let me know if you prefer I change the PEP link)
>
> Thank you for your help.
>
>
> --
> Kind regards,
>
> Stefano Borini
> ___
> 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/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(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/67ZLIDZPKQA2BVDNSRUQUUTPO7ZB4OIE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Comments on PEP 558

[Nick Coghlan]

On Wed, 3 Feb 2021, 10:16 pm Sven R. Kunze,  wrote:

> Hi Mark,
>
> I've been working on a project heavily relying on frame.f_locals.
>
> Are you planning to remove it?
>

No, PEP 558 doesn't remove it, it enhances it to be a live view of the
frame state instead of an inconsistently updated snapshot.

The potential incompatibility Mark is referring to is the fact that even
optimised frames currently allow writing to arbitrary keys in
frame.f_locals and making the bound values visible to the locals() builtin
and other consumers of frame.f_locals.

For PEP 558, it's an open question as to whether that behaviour will become
limited to the PyEval_GetLocals() backwards compatible C API, with the
updated Python frame API instead throwing KeyError for attempts to write to
unknown keys on optimised frames.

Regards,
Nick.




>
> On 30.01.21 13:18, Mark Shannon wrote:
> >
> > Given that f_locals is broken, why is keeping compatibility for this
> > obscure, and probably unused case worthwhile?
> >
> > The break in compatibility with locals() seems much more intrusive,
> > yet you are OK with that (as am I).
>
>
> Best,
> Sven
>
>
___
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/YXW2EU5YBFLG3MSNDXW3RMTZ36GG5ZH2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 563: get_type_hints should use closure when available

[Guido van Rossum]

I think this would just perpetuate misunderstanding about how things work.
You're proposing to make it so that changing the body of the function (in
particular, removing `y: T`) would affect the interpretation of the type
annotation. That's just wrong.

On Wed, Feb 3, 2021 at 12:47 PM Caleb Donovick 
wrote:

> > Here we want to know what the 'C' refers to in g's annotations. But g's
> closures are no help (unless g's body were to also reference C, which is
> not likely in typical code).
>
> I understand the limitation.  I was proposing changing
> https://github.com/python/cpython/blob/3.9/Lib/typing.py#L1431-L1433 to
> use the `nonlocal_vars` instead of `globalns` for the default localns (or
> possibly a chainmap of the two).  I agree that it may only work on a small
> fraction of code but the performance cost seems pretty minimal especially
> for a function like `get_type_hints`, so why not?  But I trust judgement,
> if you think that creating an apparent inconsistency around when
> `get_type_hints` will work and when it won't is not worth being able to
> resolve a few extra cases it probably isn't.
>
> - Caleb Donovick
>
> On Wed, Feb 3, 2021 at 8:55 AM Guido van Rossum  wrote:
>
>> Sadly this won't work, because the annotations are "evaluated" (or not)
>> in the surrounding scope, not in the function's scope. Example:
>> ```
>> >>> def f(a: int):
>> ...   class C: pass
>> ...   def g(b: C): pass
>> ...   return g
>> ...
>> >>> g = f(1)
>> >>> g.__annotations__
>> {'b': 'C'}
>> >>> g.__closure__
>> >>>
>> ```
>> Here we want to know what the 'C' refers to in g's annotations. But g's
>> closures are no help (unless g's body were to also reference C, which is
>> not likely in typical code).
>>
>> --Guido
>>
>> On Tue, Feb 2, 2021 at 6:10 PM Caleb Donovick 
>> wrote:
>>
>>> The discussion around PEP 649 got me thinking about what I believe is
>>> the largest downside to PEP 563: the inability to evaluate annotations
>>> created with closures.  While this is in general unavoidable,  if the type
>>> is ever referenced in an annotated function (including as an annotation) it
>>> should be resolvable via `__closure__`.
>>>
>>> For example:
>>> ```
>>> from __future__ import annotations
>>> import typing
>>> def gen(T):
>>> def f(x: T):
>>> y: T = ...
>>> return f
>>>
>>> f = gen(int)
>>> nonlocal_vars = {
>>>   var : cell.cell_contents
>>>   for var, cell in zip(f.__code__.co_freevars, f.__closure__)
>>> }
>>> assert typing.get_type_hints(f, localns=nonlocal_vars)  == {'x': int}
>>> ```
>>>
>>> I would just open a PR to have `get_type_hints` attempt to resolve
>>> closure variables by default.  However, this would require an update to PEP
>>> 563 and I don't know what the protocol is there.
>>>
>>> -  Caleb Donovick
>>> ___
>>> 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/L2XH2EIFCEPT5DQRPRFR6WYEM6M2LM2V/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>> 
>>
>

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(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/QHOB5JXKRVH4MI3JARJANUMDR5HLHLNH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 563: get_type_hints should use closure when available

[Caleb Donovick]

> Here we want to know what the 'C' refers to in g's annotations. But g's
closures are no help (unless g's body were to also reference C, which is
not likely in typical code).

I understand the limitation.  I was proposing changing
https://github.com/python/cpython/blob/3.9/Lib/typing.py#L1431-L1433 to use
the `nonlocal_vars` instead of `globalns` for the default localns (or
possibly a chainmap of the two).  I agree that it may only work on a small
fraction of code but the performance cost seems pretty minimal especially
for a function like `get_type_hints`, so why not?  But I trust judgement,
if you think that creating an apparent inconsistency around when
`get_type_hints` will work and when it won't is not worth being able to
resolve a few extra cases it probably isn't.

- Caleb Donovick

On Wed, Feb 3, 2021 at 8:55 AM Guido van Rossum  wrote:

> Sadly this won't work, because the annotations are "evaluated" (or not) in
> the surrounding scope, not in the function's scope. Example:
> ```
> >>> def f(a: int):
> ...   class C: pass
> ...   def g(b: C): pass
> ...   return g
> ...
> >>> g = f(1)
> >>> g.__annotations__
> {'b': 'C'}
> >>> g.__closure__
> >>>
> ```
> Here we want to know what the 'C' refers to in g's annotations. But g's
> closures are no help (unless g's body were to also reference C, which is
> not likely in typical code).
>
> --Guido
>
> On Tue, Feb 2, 2021 at 6:10 PM Caleb Donovick 
> wrote:
>
>> The discussion around PEP 649 got me thinking about what I believe is the
>> largest downside to PEP 563: the inability to evaluate annotations created
>> with closures.  While this is in general unavoidable,  if the type is ever
>> referenced in an annotated function (including as an annotation) it should
>> be resolvable via `__closure__`.
>>
>> For example:
>> ```
>> from __future__ import annotations
>> import typing
>> def gen(T):
>> def f(x: T):
>> y: T = ...
>> return f
>>
>> f = gen(int)
>> nonlocal_vars = {
>>   var : cell.cell_contents
>>   for var, cell in zip(f.__code__.co_freevars, f.__closure__)
>> }
>> assert typing.get_type_hints(f, localns=nonlocal_vars)  == {'x': int}
>> ```
>>
>> I would just open a PR to have `get_type_hints` attempt to resolve
>> closure variables by default.  However, this would require an update to PEP
>> 563 and I don't know what the protocol is there.
>>
>> -  Caleb Donovick
>> ___
>> 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/L2XH2EIFCEPT5DQRPRFR6WYEM6M2LM2V/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(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/T7AYBEUPKPZ7QLI3WRPLMSBU6BPPHOMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Upcoming 3.7.10 and 3.6.13 Security Releases

[Victor Stinner]

On Thu, Jan 21, 2021 at 5:09 AM Senthil Kumaran  wrote:
> And another security issue was brought up to our attention here (today):
> https://bugs.python.org/issue42987

This one was already fixed (the issue is closed).

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/SYPPDTQESDXOFS6OB27QONBJSPUOX4YX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 563: get_type_hints should use closure when available

[Guido van Rossum]

Sadly this won't work, because the annotations are "evaluated" (or not) in
the surrounding scope, not in the function's scope. Example:
```
>>> def f(a: int):
...   class C: pass
...   def g(b: C): pass
...   return g
...
>>> g = f(1)
>>> g.__annotations__
{'b': 'C'}
>>> g.__closure__
>>>
```
Here we want to know what the 'C' refers to in g's annotations. But g's
closures are no help (unless g's body were to also reference C, which is
not likely in typical code).

--Guido

On Tue, Feb 2, 2021 at 6:10 PM Caleb Donovick 
wrote:

> The discussion around PEP 649 got me thinking about what I believe is the
> largest downside to PEP 563: the inability to evaluate annotations created
> with closures.  While this is in general unavoidable,  if the type is ever
> referenced in an annotated function (including as an annotation) it should
> be resolvable via `__closure__`.
>
> For example:
> ```
> from __future__ import annotations
> import typing
> def gen(T):
> def f(x: T):
> y: T = ...
> return f
>
> f = gen(int)
> nonlocal_vars = {
>   var : cell.cell_contents
>   for var, cell in zip(f.__code__.co_freevars, f.__closure__)
> }
> assert typing.get_type_hints(f, localns=nonlocal_vars)  == {'x': int}
> ```
>
> I would just open a PR to have `get_type_hints` attempt to resolve closure
> variables by default.  However, this would require an update to PEP 563 and
> I don't know what the protocol is there.
>
> -  Caleb Donovick
> ___
> 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/L2XH2EIFCEPT5DQRPRFR6WYEM6M2LM2V/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(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/XKQCC5G5ZS5Y4FPT63HQMBIJZ3WUIVD3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 563: get_type_hints should use closure when available

[Terry Reedy]

On 2/2/2021 8:37 PM, Caleb Donovick wrote:
The discussion around PEP 649 got me thinking about what I believe is 
the largest downside to PEP 563: the inability to evaluate annotations 
created with closures.  While this is in general unavoidable,  if 
the type is ever referenced in an annotated function (including as an 
annotation) it should be resolvable via `__closure__`.


For example:
```
from __future__ import annotations
import typing
def gen(T):
     def f(x: T):
         y: T = ...
     return f

f = gen(int)
nonlocal_vars = {
   var : cell.cell_contents
   for var, cell in zip(f.__code__.co_freevars, f.__closure__)
}
assert typing.get_type_hints(f, localns=nonlocal_vars)  == {'x': int}
```

I would just open a PR to have `get_type_hints` attempt to resolve 
closure variables by default.  However, this would require an update to 
PEP 563 and I don't know what the protocol is there.


Once a PEP is accepted and implemented, the PEP document itself is 
frozen and not updated.  The Python language and docs and the CPython 
implementation are still subject to what is hopefully further progress.


You are free to open an thread on python-ideas list or an issue on bpo, 
optionally with a PR, or both.  It would be good to reference the PEP 
and note whether this idea appears there or not.  Further discussion of 
the idea itself would depend on whether is was a rejected alternative, a 
deferred addition, or just mentioned.


A speculative PR for an idea not yet accepted in principle may be 
rejected but may help gain acceptance.


PS: I don't use type hints yet and have not much opinion about about 
your idea (it naively seems plausible), so the above is a generic answer.


--
Terry Jan Reedy

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

[Python-Dev] Re: Comments on PEP 558

[Sven R. Kunze]

Hi Mark,

I've been working on a project heavily relying on frame.f_locals.

Are you planning to remove it?


On 30.01.21 13:18, Mark Shannon wrote:


Given that f_locals is broken, why is keeping compatibility for this 
obscure, and probably unused case worthwhile?


The break in compatibility with locals() seems much more intrusive, 
yet you are OK with that (as am I).



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

[Python-Dev] Python 3.10.0a5 is now available

[Pablo Galindo Salgado]

Well, this one took a bit more time due to some surprise last time
reference leaks and release blockers to fix, but now Python 3.10.0a5 it’s
here. Will this be the first release announcement of the 3.10 series
without copy-paste typos? Go get it here:

https://www.python.org/downloads/release/python-3100a5/

*Major new features of the 3.10 series, compared to 3.9*

Python 3.10 is still in development. This release, 3.10.0a5 is the fifth of
seven planned alpha releases. Alpha releases are intended to make it easier
to test the current state of new features and bug fixes and to test the
release process. During the alpha phase, features may be added up until the
start of the beta phase (2021-05-03) and, if necessary, may be modified or
deleted up until the release candidate phase (2021-10-04). Please keep in
mind that this is a preview release and its use is not recommended for
production environments.

Many new features for Python 3.10 are still being planned and written.
Among the new major new features and changes so far:

   - PEP 623  – Remove wstr from
   Unicode
   - PEP 604  – Allow writing
   union types as X | Y
   - PEP 612  – Parameter
   Specification Variables
   - PEP 626  – Precise line
   numbers for debugging and other tools.
   - bpo-38605 : from __future__ import
   annotations (PEP 563 ) is now
   the default.
   - PEP 618  – Add Optional
   Length-Checking To zip.
   - bpo-12782 : Parenthesized context
   managers are now officially allowed.
   - (Hey, fellow core developer, if a feature you find important is
   missing from this list, let Pablo know .)

The next pre-release of Python 3.10 will be 3.10.0a6, currently scheduled
for 2021-03-01.
And now for something completely different

The Chandrasekhar limit is the maximum mass of a stable white dwarf star.
White dwarfs resist gravitational collapse primarily through electron
degeneracy pressure, compared to main sequence stars, which resist collapse
through thermal pressure. The Chandrasekhar limit is the mass above which
electron degeneracy pressure in the star’s core is insufficient to balance
the star’s own gravitational self-attraction. Consequently, a white dwarf
with a mass greater than the limit is subject to further gravitational
collapse, evolving into a different type of stellar remnant, such as a
neutron star or black hole. Those with masses up to the limit remain stable
as white dwarfs. The currently accepted value of the Chandrasekhar limit is
about 1.4 M☉ (2.765×1030 kg). So we can be safe knowing that our sun is not
going to become a black hole!

Regards from cloudy London,

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

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

[Phil Thompson via Python-Dev]

On 02/02/2021 23:08, Greg Ewing wrote:

On 3/02/21 4:52 am, Phil Thompson wrote:

Thanks - that's fairly definitive, although I don't really understand 
why __new__ has this particular requirement.


The job of tp_new is to initialise the C struct. To do this,
it first has to initialise the fields of the struct it
inherits from, then initialise any fields of its own that
it adds, in that order.


Understood.


Initialising the inherited fields must be done by calling
the tp_new for the struct that it inherits from. You don't
want to call the tp_new of some other class that might have
got inserted into the MRO, because you have no idea what
kind of C struct it expects to get.


I had assumed that some other magic in typeobject.c (eg. conflicting 
meta-classes) would have raised an exception before getting to this 
stage if there was a conflict.



Cooperative calling is a nice idea, but it requires rather
special conditions to make it work. All the methods must
have exactly the same signature, and it mustn't matter what
order they're called in. Those conditions don't apply to
__new__, especially at the C level where everything is much
more strict type-wise.


Thanks for the explanation.

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

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

[Martin Teichmann]

Hi Greg, Hi List,

Greg wrote:

>  class MyClass(B, Mixin):
> >"whatever"
> >
> > this leads to an MRO of MyClass -> B -> Mixin -> A -> object.
>
> If you do the tp_new stuff correctly at the C level, you can still
> create such a class. The only limitation is that if Mixin has a __new__
> method written in Python, it won't get called.


Yes, it is indeed possible to write a class like this. But that would be,
as mentioned in the comment, silly. Now there is nothing bad with being
silly once in a while, especially while programming that cannot be avoided
at times, I am just warning to use such a construct in a wider context.

Because the limitation is actually much more general: if the Mixin has any
method written in Python, it won't get called, unless you do a lot of heavy
lifting. Now why do you write something in C at all? Two reasons: once for
speed, which we can effectively exclude here because the super() construct
is slow, or because you want to interact with a library written in another
language. Unless your library knows about cooperative inheritance, which is
very unlikely, the code from class B is not aware that it is not supposed
to call the method inherited from A, but the one from the Mixin instead.

So by writing

   class MyClass(B, Mixin):
"whatever"

I have major problems to understand what you actually want to achieve, what
you could not achieve by writing

class MyClass(Mixin, B):
"whatever"

Since one cannot achieve anything with the former that could not be
achieved by the latter, just with much less hassle, I would call the former
code silly.

That said, I might be wrong and there is indeed something one can achieve
with the former but not with the latter, I would be very pleased to hear
about this, so please come forward! (For sure, all is based on B and A
being written in C, not Python)

Cheers

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