[Python-Dev] Re: Remove formatter module from Python 3.9, deprecated for 7 years (Python 3.4)

[Gregory P. Smith]

As another datapoint, in an internal codebase with a high XX million lines
of Python code, I see a mere 7 uses.  Most of which are in legacy things
that would be trivial to use f-strings instead if the code doesn't just get
deleted when the owners notice. :)

(and my team is responsible for upgrading us to 3.9 so we'd simply make
that happen at that time)

-gps

On Fri, Jan 17, 2020 at 11:09 AM Gregory P. Smith  wrote:

> +1 remove it to match that policy.  I find it unlikely someone will ask
> for it to be restored, but our first response before doing so should be to
> see if they can instead use it as a dependency via PyPI: Someone who wants
> to maintain it for future use can take 3.8 formatter module and put it
> there.
>
> -gps
>
> On Fri, Jan 17, 2020 at 10:43 AM Andrew Svetlov 
> wrote:
>
>> I have no objections, the module raises the explicit deprecation
>> warning since 2013.
>>
>> On Fri, Jan 17, 2020 at 7:31 PM Victor Stinner 
>> wrote:
>> >
>> > Hi,
>> >
>> > I proposed https://bugs.python.org/issue39352 to remove the formatter
>> > module. It's deprecated since Python 3.4. The main reason why it's
>> > still around is the PEP 4 rule:
>> >
>> > "In order to facilitate writing code that works in both Python 2 & 3
>> > simultaneously, any module that exists in both Python 3.5 and Python
>> > 2.7 will not be removed from the standard library until Python 2.7 is
>> > no longer supported as specified by PEP 373."
>> >
>> >
>> https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5
>> >
>> > Python 2.7 is not longer supported. So can we now remove the formatter
>> module?
>> >
>> > The module has no test, I failed to find any user in a dummy GitHub
>> > code search and I didn't know that this module even existed.
>> >
>> > We can still revert the module before 3.9.0 final release if someone
>> > shows up and asks to keep it for one more cycle.
>> >
>> > My intent here is to reduce the size of the Python standard library to
>> > reduce the maintenance burden. Python became quite large and it's more
>> > and more expensive to maintain it. Wait... I'm not asking to remove
>> > all modules of the standard library :-) The decision must be taken on
>> > a case by case basis, for each module. Here I'm only taking about the
>> > formatter module.
>> >
>> > 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/ESSRZXEJ7MWMGNZQKNDURGRWIZ5FQHKP/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>>
>> --
>> Thanks,
>> Andrew Svetlov
>> ___
>> 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/BHCWXBTELE354DCELWADMOX6O6CJOJ2A/
>> 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/IAYJ5HXIMRU7YMZUZDOPW54PQOBPPFDQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove formatter module from Python 3.9, deprecated for 7 years (Python 3.4)

[Gregory P. Smith]

+1 remove it to match that policy.  I find it unlikely someone will ask for
it to be restored, but our first response before doing so should be to see
if they can instead use it as a dependency via PyPI: Someone who wants to
maintain it for future use can take 3.8 formatter module and put it there.

-gps

On Fri, Jan 17, 2020 at 10:43 AM Andrew Svetlov 
wrote:

> I have no objections, the module raises the explicit deprecation
> warning since 2013.
>
> On Fri, Jan 17, 2020 at 7:31 PM Victor Stinner 
> wrote:
> >
> > Hi,
> >
> > I proposed https://bugs.python.org/issue39352 to remove the formatter
> > module. It's deprecated since Python 3.4. The main reason why it's
> > still around is the PEP 4 rule:
> >
> > "In order to facilitate writing code that works in both Python 2 & 3
> > simultaneously, any module that exists in both Python 3.5 and Python
> > 2.7 will not be removed from the standard library until Python 2.7 is
> > no longer supported as specified by PEP 373."
> >
> >
> https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5
> >
> > Python 2.7 is not longer supported. So can we now remove the formatter
> module?
> >
> > The module has no test, I failed to find any user in a dummy GitHub
> > code search and I didn't know that this module even existed.
> >
> > We can still revert the module before 3.9.0 final release if someone
> > shows up and asks to keep it for one more cycle.
> >
> > My intent here is to reduce the size of the Python standard library to
> > reduce the maintenance burden. Python became quite large and it's more
> > and more expensive to maintain it. Wait... I'm not asking to remove
> > all modules of the standard library :-) The decision must be taken on
> > a case by case basis, for each module. Here I'm only taking about the
> > formatter module.
> >
> > 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/ESSRZXEJ7MWMGNZQKNDURGRWIZ5FQHKP/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Thanks,
> Andrew Svetlov
> ___
> 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/BHCWXBTELE354DCELWADMOX6O6CJOJ2A/
> 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/EGKD2KC4ZG2B7ZPA3NCBCWM3GRCJOP5M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove formatter module from Python 3.9, deprecated for 7 years (Python 3.4)

[Andrew Svetlov]

I have no objections, the module raises the explicit deprecation
warning since 2013.

On Fri, Jan 17, 2020 at 7:31 PM Victor Stinner  wrote:
>
> Hi,
>
> I proposed https://bugs.python.org/issue39352 to remove the formatter
> module. It's deprecated since Python 3.4. The main reason why it's
> still around is the PEP 4 rule:
>
> "In order to facilitate writing code that works in both Python 2 & 3
> simultaneously, any module that exists in both Python 3.5 and Python
> 2.7 will not be removed from the standard library until Python 2.7 is
> no longer supported as specified by PEP 373."
>
> https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5
>
> Python 2.7 is not longer supported. So can we now remove the formatter module?
>
> The module has no test, I failed to find any user in a dummy GitHub
> code search and I didn't know that this module even existed.
>
> We can still revert the module before 3.9.0 final release if someone
> shows up and asks to keep it for one more cycle.
>
> My intent here is to reduce the size of the Python standard library to
> reduce the maintenance burden. Python became quite large and it's more
> and more expensive to maintain it. Wait... I'm not asking to remove
> all modules of the standard library :-) The decision must be taken on
> a case by case basis, for each module. Here I'm only taking about the
> formatter module.
>
> 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/ESSRZXEJ7MWMGNZQKNDURGRWIZ5FQHKP/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Thanks,
Andrew Svetlov
___
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/BHCWXBTELE354DCELWADMOX6O6CJOJ2A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-01-10 - 2020-01-17)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7268 (+17)
  closed 43855 (+63)
  total  51123 (+80)

Open issues with patches: 2847 


Issues opened (54)
==

#16576: ctypes: structure with bitfields as argument
https://bugs.python.org/issue16576  reopened by vinay.sajip

#37751: In codecs,  function 'normalizestring' should convert both spa
https://bugs.python.org/issue37751  reopened by vstinner

#38076: Make struct module PEP-384 compatible
https://bugs.python.org/issue38076  reopened by pablogsal

#39293: Windows 10 64-bit needs reboot
https://bugs.python.org/issue39293  opened by ToKa

#39294: zipfile.ZipInfo objects contain invalid 'extra' fields.
https://bugs.python.org/issue39294  opened by Bram Stolk

#39295: usage of bitfields in ctypes structures changed between 3.7.5 
https://bugs.python.org/issue39295  opened by Matthew Newville

#39296: Windows register keys
https://bugs.python.org/issue39296  opened by ToKa

#39298: add BLAKE3 to hashlib
https://bugs.python.org/issue39298  opened by larry

#39299: Improve test coverage for mimetypes module
https://bugs.python.org/issue39299  opened by xtreak

#39301: Specification of bitshift on integers should clearly state flo
https://bugs.python.org/issue39301  opened by ncoghlan

#39302: Language reference does not clearly describe modern operand co
https://bugs.python.org/issue39302  opened by ncoghlan

#39305: Merge nntplib._NNTPBase and nntplib.NNTP
https://bugs.python.org/issue39305  opened by corona10

#39306: Lib/configparser.py - RawConfigParser.set does not pass non-tr
https://bugs.python.org/issue39306  opened by Strijker

#39309: Please delete my account
https://bugs.python.org/issue39309  opened by sfjwlejfawnf

#39314: Autofill the closing paraenthesis during auto-completion for f
https://bugs.python.org/issue39314  opened by opensource-assist

#39316: settrace skips lines when chaining methods without arguments
https://bugs.python.org/issue39316  opened by alexmojaki

#39318: NamedTemporaryFile could cause double-close on an fd if _Tempo
https://bugs.python.org/issue39318  opened by nneonneo

#39320: Handle unpacking of */** arguments and rvalues in the compiler
https://bugs.python.org/issue39320  opened by Mark.Shannon

#39323: Add test for imghdr cli
https://bugs.python.org/issue39323  opened by xtreak

#39324: Add mimetype for extension .md (markdown)
https://bugs.python.org/issue39324  opened by Ryan Batchelder

#39325: Original window focus when opening IDLE by double clicking Pyt
https://bugs.python.org/issue39325  opened by IrvKalb

#39326: Python-3.8.1 "test_importlib" failed
https://bugs.python.org/issue39326  opened by Divyansh_tiwari

#39327: shutil.rmtree using vagrant synched folder fails
https://bugs.python.org/issue39327  opened by PeterFS

#39328: Allow filename mismatch in local and central directories in zi
https://bugs.python.org/issue39328  opened by cheryl.sabella

#39331: 2to3 mishandles indented imports
https://bugs.python.org/issue39331  opened by galun.guy

#39334: python specific index directives in our doc has been deprecate
https://bugs.python.org/issue39334  opened by mdk

#39336: Immutable module type can't be used as package in custom loade
https://bugs.python.org/issue39336  opened by dino.viehland

#39337: codecs.lookup() ignores non-ASCII characters, whereas encoding
https://bugs.python.org/issue39337  opened by vstinner

#39339: ProcessPoolExecutor()   Exception in thread QueueManagerThread
https://bugs.python.org/issue39339  opened by pythonpython

#39340: shutil.rmtree and write protected files
https://bugs.python.org/issue39340  opened by PeterFS

#39341: [security] zipfile: ZIP Bomb vulnerability, don't check announ
https://bugs.python.org/issue39341  opened by vstinner

#39342: Expose X509_V_FLAG_ALLOW_PROXY_CERTS in ssl
https://bugs.python.org/issue39342  opened by chrisburr

#39343: Travis CI: documentation job fails in library/nntplib.rst with
https://bugs.python.org/issue39343  opened by vstinner

#39344: Getting error while importing ssl " import _ssl # if we can't 
https://bugs.python.org/issue39344  opened by Ajaya

#39345: Py_Initialize Hangs on Windows 10
https://bugs.python.org/issue39345  opened by dhamilton

#39346: gzip module only supports half of possible read/write scenario
https://bugs.python.org/issue39346  opened by ddevault

#39347: Use of argument clinic like parsing and `METH_FASTCALL` suppor
https://bugs.python.org/issue39347  opened by seberg

#39349: Add "cancel_futures" parameter to concurrent.futures.Executor.
https://bugs.python.org/issue39349  opened by aeros

#39352: Remove the formatter module, deprecated since Python 3.4
https://bugs.python.org/issue39352  opened by vstinner

#39353: Deprecate the binhex module, binhex4 and hexbin4 standards

[Python-Dev] Remove formatter module from Python 3.9, deprecated for 7 years (Python 3.4)

[Victor Stinner]

Hi,

I proposed https://bugs.python.org/issue39352 to remove the formatter
module. It's deprecated since Python 3.4. The main reason why it's
still around is the PEP 4 rule:

"In order to facilitate writing code that works in both Python 2 & 3
simultaneously, any module that exists in both Python 3.5 and Python
2.7 will not be removed from the standard library until Python 2.7 is
no longer supported as specified by PEP 373."

https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5

Python 2.7 is not longer supported. So can we now remove the formatter module?

The module has no test, I failed to find any user in a dummy GitHub
code search and I didn't know that this module even existed.

We can still revert the module before 3.9.0 final release if someone
shows up and asks to keep it for one more cycle.

My intent here is to reduce the size of the Python standard library to
reduce the maintenance burden. Python became quite large and it's more
and more expensive to maintain it. Wait... I'm not asking to remove
all modules of the standard library :-) The decision must be taken on
a case by case basis, for each module. Here I'm only taking about the
formatter module.

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

[Python-Dev] Re: Questions about CPython's behavior on addition operator -- binary_op1 (abstract.c) and nb_add (typeobject.c)

[Jeff Allen]

On 16/01/2020 11:27, Raphaël Monat wrote:

Hi all,

I'm looking at CPython's behavior when an addition is called. From 
what I understand, binary_op1 
 
is eventually called, and it calls either slotv or slotw, which seems 
to be the binaryfunc defined as nb_add in the field tp_as_number of 
respectively v / w.


I'm also keen to understand this and think I can elucidate a little, 
from my study of the code. The perspective of someone who *didn't* write 
it might help, but I defer to the authors' version when it appears.


A crucial observation is that there is only one nb_add slot in a type 
definition. Think about adding a int(1) + float(2). Where it lands in 
long_add (v->ob_type->tp_as_number->nb_add) will return NotImplemented, 
because it does not understand the float right-hand argument, but 
float_add (w->ob_type->tp_as_number->nb_add) is able to give an answer, 
since it can float the int, behaving as float.__radd__(f, i). So the 
slots have to implement both __add__ and __radd__.



I have a few questions:
1) In the default case, tp_as_number->nb_add is defined by the 
function slot_nb_add 
 
itself stemming from the macro expansion SLOT1BINFULL 
 
defined in typeobject.c. Both binary_op1(v, w) and slot_nb_add(v, w) 
appear to perform similar checks (if their second argument is a 
subtype of the first, etc), to decide if v's add or w's reverse add 
must be called and in which order. I find this repetition weird, and I 
guess I'm missing something... Any ideas?


The logic is the same as binary_op1, but the function has to deal with 
the possibility that one or other type may already provide a special 
function wrapper function in its nb_add slot, which is what the test 
tp_as_number->SLOTNAME == TESTFUNC is about. TESTFUNC is nearly always 
the same as FUNCNAME. Then it also deals with quite a complex decision 
in method_is_overloaded().


The partial repetition of the logic, which I think is now nested 
(because binary_op1() may have called slot_nb_add) is necessary to 
insert the more complex version into the decision tree. But this is 
roughly where my ability to visualise the paths runs out.




2) From the SLOT1BINFULL macro, both __add__ and __radd__ are defined 
by the slot_nb_add function (with some argument swapping done by 
wrap_binaryfunc_l / wrap_binaryfunc_r). If I want to define a 
different behavior for the reverse operator during a definition with a 
PyTypeObject, I guess I should add an "__radd__" method?


I would not say they are "defined" by the slot_nb_add function. Rather, 
if one or other has been defined (in Python), v.__add__ or w.__radd__ is 
called by the single function slot_nb_add. They cannot be called 
directly from C, but call_maybe() supplies the mechanism.


A confusing factor is that for types defined in C and filling the nb_add 
slot, the slot function (float_add, or whatever) has to be wrapped by 
two descriptors that can then sit in the type's dictionary as "__add__" 
and "__radd__". In that case these *are* defined by a wrapped C 
function, but that function is the function in the implementation of the 
type (float_add, say), not slot_nb_add. There are two kinds of wrapper: 
one used "Python-side out", so Python-calling "__add__" leads to 
nb_add's behaviour, and one "C-side out" so C-calling via nb_add leads 
to "__add__".


3) If I create a user-defined class A, having different methods 
__add__ and __radd__, these methods are added in A's dictionary. From 
what I understand, the function update_one_slot 
 
is then called to change A's tp_as_number->nb_add to point to the 
methods defined by __add__ and __radd__? From the code documentation, 
I think that "a wrapper for the special methods is installed". Where 
exactly is this wrapper applied, and how does it know when to dispatch 
to __add__ or __radd__?



I *think* it is changed to contain slot_nb_add as defined by the macro.

I hope that is somewhere near accurate.

Jeff Allen


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