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.

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.

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).

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).

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

Buuuump
---
sent by an 11-year old

Can you provide a patch?

I'll give one now.

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."

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

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.

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.

Is there an equivalent of _dummy_thread for threading?

Ignore earlier message.

@Mark
>BTW, in an earlier comment you said: "now threading imports dummy_threading when threading is not available".
My comment only applies to _thread.

Sorry it doesn't apply to anything at all.

Odd.. I download decimal.py from http://hg.python.org/cpython/file/fa959dc5c61d/Lib/decimal.py but it uses "1L" (isn't py3k compliant)

Revision fa959dc5c61d comes from the 2.7 maintenance branch.  Try:

   http://hg.python.org/cpython/file/e5f39546989f/Lib/decimal.py

instead.  Better still, get a clone of the Python repository. :-)

> Odd.. I download decimal.py from http://hg.python.org/cpython/file/fa959dc5c61d/Lib/decimal.py but it uses "1L" (isn't py3k compliant)

Try http://hg.python.org/cpython/file/default/Lib/decimal.py

Clicking 'browse' from http://hg.python.org/cpython/ shows the source tree as it is in 'tip', which is sometimes 2.7 instead of default.

On 31 October 2012 22:04, Mark Dickinson <report@bugs.python.org> wrote:

>
> Mark Dickinson added the comment:
>
> Revision fa959dc5c61d comes from the 2.7 maintenance branch.  Try:
>
>    http://hg.python.org/cpython/file/e5f39546989f/Lib/decimal.py
>
> instead.  Better still, get a clone of the Python repository. :-)
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13701>
> _______________________________________
>

clone is quite big (~300 MB->half an hour)
I know about the way to download the repo's tip as .tar.bz2

Attached is a patch.
I haven't tested it.

I'm not sure whether the patch fixes everything.
Gone to sleep.

New changeset 7ada0faded9b by Mark Dickinson in branch 'default':
Issue #13701: Fix decorator avoidance (due to desire for Python 2.3 compatibility) in decimal module.
http://hg.python.org/cpython/rev/7ada0faded9b

Fixed the unuse of decorator syntax.  I think the dummy_threading changes should be considered a separate issue.

With regards to the patch:  I assume you mean "import dummy_threading as threading" rather than just "import dummy_threading".  Also, it looks to me as though test_decimal would need updating too to do the correct thing when the threading module isn't present.

Closing this issue as fixed;  please open a new issue for the dummy_threading if you think it's worth pursuing.

On 31 October 2012 23:29, Mark Dickinson <report@bugs.python.org> wrote:

>
> Mark Dickinson added the comment:
>
> Fixed the unuse of decorator syntax.  I think the dummy_threading changes
> should be considered a separate issue.
>
> With regards to the patch:  I assume you mean "import dummy_threading as
> threading" rather than just "import dummy_threading".  Also, it looks to me
> as though test_decimal would need updating too to do the correct thing when
> the threading module isn't present.
>
> Closing this issue as fixed;  please open a new issue for the
> dummy_threading if you think it's worth pursuing.
>
> ----------
> assignee: rhettinger -> mark.dickinson
> resolution:  -> fixed
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13701>
> _______________________________________
>

In the docs for dummy_threading, "Be careful to not use this module where
deadlock might occur from a thread being created that blocks waiting for
another thread to be created. This often occurs with blocking I/O."

I'm not quite sure why you're quoting the docs at me.  What's the point you want to make?

On 1 November 2012 14:09, Mark Dickinson <report@bugs.python.org> wrote:

>
> Mark Dickinson added the comment:
>
> I'm not quite sure why you're quoting the docs at me.  What's the point
> you want to make?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13701>
> _______________________________________
>

Does decimal use the dummy_threading module where
deadlock might occur from a thread being created that blocks waiting for
another thread to be created?

No.

Ramchandra Apte <report@bugs.python.org> wrote:
> > I'm not quite sure why you're quoting the docs at me.  What's the point
> > you want to make?
> 
> Does decimal use the dummy_threading module where
> deadlock might occur from a thread being created that blocks waiting for
> another thread to be created?

The modus operandi on the issue tracker is generally like this:

For finished modules like decimal you need to provide a concrete example
that triggers an alleged misbehavior. The reason is simple: In general
no one has time for open-ended questions like the one you asked.

Also, such questions are perfectly on-topic on python-list.

On 1 November 2012 17:12, Stefan Krah <report@bugs.python.org> wrote:

>
> Stefan Krah added the comment:
>
> Ramchandra Apte <report@bugs.python.org> wrote:
> > > I'm not quite sure why you're quoting the docs at me.  What's the point
> > > you want to make?
> >
> > Does decimal use the dummy_threading module where
> > deadlock might occur from a thread being created that blocks waiting for
> > another thread to be created?
>
> The modus operandi on the issue tracker is generally like this:
>
> For finished modules like decimal you need to provide a concrete example
> that triggers an alleged misbehavior. The reason is simple: In general
> no one has time for open-ended questions like the one you asked.
>
> Also, such questions are perfectly on-topic on python-list.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13701>
> _______________________________________
>

I just wanted to ensure that there wouldn't be any bugs by my patch.

> I just wanted to ensure that there wouldn't be any bugs by my patch.

Okay, understood.  Thanks.

Please note that this issue is now closed, though: the 2.3 compatibility workarounds have been dealt with.  The use or non-use of dummy_threading has nothing to do with 2.3 compatibility and so is out of scope for the issue.  You should feel free to open a new issue if there's a demonstrable problem or demonstrable room for improvement w.r.t. the way dummy threading is handled.  (I'm personally not convinced that either of those is true, but others may have different views.)

But my patch does use dummy_threading.

Ramchandra: Your patch wasn't actually used to resolve this issue. Please see http://hg.python.org/cpython/rev/7ada0faded9b for the change that Mark *actually* made to resolve the issue.

There were actually a number of problems with your patch, but there is little point in elaborating them. If you submit more patches, people will surely review them and comment.