* PEP 697: Changes based on initial implementation & docs
- Use a flag, `Py_TPFLAGS_ITEMS_AT_END`, rather than a slot. This way the subclass doesn't need to worry about items (if the superclass is set up right).
- The result of `PyObject_GetTypeDataSize` may be higher than requested by -basicsize (e.g. due to alignment). It is safe to use all of it (e.g. with memset).
- Mention that `basicsize == 0` and `itemsize == 0` already work. I’ll add explicit docs & tests though.
- Add link to initial implementation
- Add endorsements
- Add a “big picture” decision tree
- Rewording
- Mention possible flags for alternative item layouts
* Apply suggestions from code review
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
The prefix is very visible, so:
- No opt-in macro
- No new Include/ subdirectory
Removed frame evaluation API: I haven't found a way to use it,
so I can't test it.
Mention that unstable API should be documented and tested.
Add link to rough reference implementation.
We claimed that there are two disadvantages to overrides:
it makes code more verbose, and requires developers to update
subclasses when possibly-breaking changes happen to base classes.
In discussion, it was pointed out that the second disadvantage is
kind of strange - it is exactly the same as the advantage of
using @override in the first place because the whole point is that
it is not usually safe to assume subclasses can be unchanged when
a method they override is removed from a base class.
I think just pointing out verbosity is good enough, I think it's
understood that more verbose code potentially requires more edits
to change, and in reality I think the case when it was safe to
ignore invalidated overrides is pretty rare so making that a big
focus seems a little weird.
* Fix Author and Created date headers of PEP 248.
* Fix date formatting to make linter happy
* Change the Author header to work around missing editor field.
* Use a different way of mentioning the editor characterization
* Remove the "Editor" notice form the Author field.
Add a short blurb explaining the roles in the acks.
* Add optional Connection.autocommit attribute as discussed on the DB-SIG ML.
Fix the creation date to point to the announcement date of the
DB-API 2.0.
Add years to the acknowledgements.
Minor editorial changes.
* Fix spelling.
* Fix another spelling mistake.
At this time, Pyre still does not have strict override enforcement.
This (and supporting codemod tools) are still something we want,
but given that we have not yet delivered this and do not have a firm
ETA we should not make claims about specific plans in the PEP text.
We decided to add this for two reasons:
- It was specifically requested by the author of the `overrides`
library, because there there are some handy runtime uses
of override information (such as propagating docstrings, which
we highlight as a concrete example)
- We realized that we actually added `__final__` to
`@typing.final` in spite of it not being specified in PEP 591,
which we felt strongly suggests that even if we omit it we
would later change our minds.
This runtime behavior is currently implemented in typing_extensions
(see https://github.com/python/typing_extensions/pull/86) as well
as pyre_extensions.