[Python-Dev] Re: What is a public API?
PEP 8 would concur, whatever the current preferred style was. Under "Naming Conventions": """New modules and packages (including third party frameworks) should be written to these standards, but where an existing library has a different style, internal consistency is preferred.""" The requirement for internal consistency (essential for readability in code of any size) alone justifies Raymond's wish to update it. On Wed, Jul 17, 2019 at 1:32 AM Brett Cannon wrote: > Raymond Hettinger wrote: > > > On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka [email protected]... > wrote: > > > Could we strictly define what is considered a public module interface > in Python? > > > The RealDefinition™ is that whatever we include in the docs is public, > otherwise > > not. > > Beyond that, there is a question of how users can deduce what is public > when they run > > "import somemodule; print(dir(some module))". > > In some modules, we've been careful to use both all and to use an > > underscore prefix to indicate private variables and helper functions > (collections and > > random for example). IMO, when a module has shown that care, future > maintainers should > > stick with that practice. > > The calendar module is an example of where that care was taken for many > years and then > > a recent patch went against that practice. > > I agree with Raymond that if the calendar module was following the leading > underscore practice (which we should probably encourage all new modules to > follow for consistency going forward) then I think the module should be > updated to keep the practice going. > > -Brett > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/WRREKS5LYMB5VYFON7RWGDKZW4KTYMIE/ > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/6MZ62L2CIY72NRMHHGBLTD7X6MYMUDU4/
[Python-Dev] Re: Long-term deprecation policy
On Tue, Jul 16, 2019 at 11:07 PM Jeroen Demeyer wrote: > > On 2019-07-16 15:33, Inada Naoki wrote: > >> We currently have a deprecation policy saying that functions deprecated > >> in version N cannot be removed before version N+2. That's a reasonable > >> policy but some deprecation purists insist that it MUST (instead of MAY) > >> be removed in version N+2. Following this reasoning, we cannot deprecate > >> something that we cannot remove. > > > > Really? Any example? > > * https://bugs.python.org/issue29548#msg287775 > OK, Stable ABI was special. We can not remove it until Python 4 regarding to PEP 384. In 2017, Python 4 was looked like "forever". But for now, we should think Python 4 is the real future in 2020s, not 3000 or 4000. I think we should deprecate APIs in stable API like non-stable API if we want to remove it after Python 4.0. -- Inada Naoki ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/WR4SE2GFZHW2CFD6C7Z4BI7A2FWK5SMQ/
[Python-Dev] Re: Long-term deprecation policy
Jeroen Demeyer wrote: > On 2019-07-17 02:34, Brett Cannon wrote: > > I prefer removal for ease of maintenance (people > > always want to update code even if it's deprecated), and to help make sure > > people who > > don't read the docs but discover something via the REPL or something and > > don't run with > > warnings on do not accidentally come to rely on something that's deprecated. > > I see what you mean but it doesn't really answer my question. > I was asking about a scenario where you plan on purpose a long > deprecation period because you know in advance that you cannot remove > the functionality soon (because of PEP 384 or because it's used a lot, > for example collections ABCs). Sorry, I misread the question you were asking. Yes, I agree that even if you can't remove something for a while you should still deprecate it. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/265QKTU3MDYMDZQ6MHZRPTELSZFURU46/
