Remove Decimal Python 2.3 Compatibility

[RamchandraApte]

BPO	13701
Nosy	@loewis, @rhettinger, @facundobatista, @mdickinson, @ezio-melotti, @skrah, @zware
Files	decimal.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/mdickinson'
closed_at = <Date 2012-10-31.17:59:55.311>
created_at = <Date 2012-01-03.03:01:45.436>
labels = ['type-feature', 'library']
title = 'Remove Decimal Python 2.3 Compatibility'
updated_at = <Date 2012-11-01.17:55:03.917>
user = 'https://bugs.python.org/RamchandraApte'

bugs.python.org fields:

activity = <Date 2012-11-01.17:55:03.917>
actor = 'loewis'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2012-10-31.17:59:55.311>
closer = 'mark.dickinson'
components = ['Library (Lib)']
creation = <Date 2012-01-03.03:01:45.436>
creator = 'Ramchandra Apte'
dependencies = []
files = ['27813']
hgrepos = []
issue_num = 13701
keywords = ['patch']
message_count = 33.0
messages = ['150495', '150503', '150690', '150711', '152370', '174296', '174302', '174303', '174304', '174307', '174308', '174309', '174312', '174313', '174314', '174316', '174318', '174320', '174321', '174323', '174325', '174326', '174347', '174349', '174393', '174394', '174398', '174401', '174402', '174407', '174416', '174418', '174435']
nosy_count = 9.0
nosy_names = ['loewis', 'rhettinger', 'facundobatista', 'mark.dickinson', 'ezio.melotti', 'skrah', 'python-dev', 'Ramchandra Apte', 'zach.ware']
pr_nums = []
priority = 'low'
resolution = 'fixed'
stage = 'needs patch'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue13701'
versions = ['Python 3.4']

[RamchandraApte]

Decimal has compatibility for Python 2.3 (such as not using decorators) as mentioned in comments in the source code for it.
This compatibility should be removed in Python 3.3 and if possible, in Python 3.2.

[mdickinson]

Did you have specific changes in mind?

While we're still maintaining 2.x and 3.x code in parallel, there's a benefit to not having the versions of decimal.py diverge too much. Given that the 2.3-compatible code isn't actually broken, I'm not sure that there's really that much to be gained by changing it.

The ugliest part of the current code is probably the post-application of classmethod instead of using a decorator; I wouldn't object to fixing that.

I do agree with the general principle that the 3.x version of decimal.py doesn't need to stay backwards compatible with Python 2.3.

[loewis]

I suggest to remove all mentionings of 2.3 compatibility from the file (I actually could find only a single one), for 3.3. Changing 3.2 is out of scope, as it isn't a bug fix (except that the one place referring to 2.3 claims that there is a comment at the top of the file which actually doesn't exist anymore).

[rhettinger]

Mark, do you think the C version of decimal is going to happen for 3.3?

If so, it make little sense to make any changes at all the current version of the pure python code.

Another advantage to leaving the pure python code alone is that it will make maintenance easier if we have to make updates (remember, if the spec gets updated, that will be considered a bug fix and backported).

[RamchandraApte]

There is another problem with the code it creates a dummy module when threading is not available but now threading imports dummy_threading when threading is not available.

Thanks

[RamchandraApte]

Buuuump
---
sent by an 11-year old

[ezio-melotti]

Can you provide a patch?

[RamchandraApte]

I'll give one now.

[RamchandraApte]

Do you think this should be fixed - the comments say
"This module is currently Py2.3 compatible and should be kept that way unless a major compelling advantage arises. IOW, 2.3 compatibility is strongly preferred, but not guaranteed."

[ezio-melotti]

That might be true for 2.7, but for 3.4 it can probably be changed.

[mdickinson]

It seems fine to me to change it for 3.4, assuming that the diff isn't huge. Spec updates don't seem likely, and even if they did occur I'd expect them to be small tweaks rather than major additions.

+0 from me.

[mdickinson]

BTW, in an earlier comment you said: "now threading imports dummy_threading when threading is not available".

Do you mean that 'import threading' will always succeed, even on platforms built without thread support? Is this documented somewhere?

The docs at http://docs.python.org/3.3/library/dummy_threading.html seem to say rather that dummy_threading still has to be imported explicitly.