[issue16422] Decimal constants should be the same for py & c module versions

Stefan Krah added the comment: In the version I committed the string constants are interned, so anything but legacy strings should be reasonably fast. -- assignee: -> skrah components: +Extension Modules resolution: -> fixed stage: -> committed/rejected status: open -> closed ___

[issue16422] Decimal constants should be the same for py & c module versions

Roundup Robot added the comment: New changeset 733bb4fd9888 by Stefan Krah in branch '3.3': Issue #16422: Use strings for rounding mode constants for better readability http://hg.python.org/cpython/rev/733bb4fd9888 -- nosy: +python-dev ___ Python trac

[issue16422] Decimal constants should be the same for py & c module versions

Stefan Krah added the comment: In the absence of an enum type, string constants are nicer to read in the REPL, so here's a patch. Translating between strings and ints is fast if you use the module constants. -- keywords: +patch Added file: http://bugs.python.org/file28736/issue16422.diff

[issue16422] Decimal constants should be the same for py & c module versions

Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue16422] Decimal constants should be the same for py & c module versions

Stefan Krah added the comment: Well, I suppose one could use a cascaded switch statement, starting with the 7th letter and then (in the case of HALF*) proceed with the 12th letter: "ROUND_CEILING" "ROUND_FLOOR" "ROUND_UP" "ROUND_DOWN" "ROUND_HALF_UP" "ROUND_HALF_DOWN" "ROUND_HALF_EVEN" "ROUND_0

[issue16422] Decimal constants should be the same for py & c module versions

Stefan Krah added the comment: It would be possible to translate strings to integers; the infrastructure is already there for pickling. The decision not to do that was actually deliberate: Up to now no one has requested string constants for rounding modes and I *suspect* that there's a performanc

[issue16422] Decimal constants should be the same for py & c module versions

Yury Selivanov added the comment: Right ;) Is there any chance we can fix that in next 3.3 point release or 3.4? -- ___ Python tracker ___ __

[issue16422] Decimal constants should be the same for py & c module versions

Stefan Krah added the comment: I see that you mentioned the use case in your first mail. Yes, that isn't possible right now. -- ___ Python tracker ___ ___

[issue16422] Decimal constants should be the same for py & c module versions

Stefan Krah added the comment: So what data structure are you trying to serialize interchangeably? -- ___ Python tracker ___ ___ Pytho

[issue16422] Decimal constants should be the same for py & c module versions

Yury Selivanov added the comment: Well, I don't care about py 3.2 & 3.3 pickle compatibility in this particular issue. This one is about compatibility of py & c decimal modules in 3.3. -- ___ Python tracker _

[issue16422] Decimal constants should be the same for py & c module versions

Stefan Krah added the comment: Pickling changed in 3.3 to make the C and Python versions compatible. So pickled contexts in 3.3 are actually interchangeable. Pickling a list of rounding modes is not compatible. -- ___ Python tracker

[issue16422] Decimal constants should be the same for py & c module versions

Mark Dickinson added the comment: I think it's already true that pickling a Decimal context on Python 3.2 and unpickling on Python 3.3 doesn't work. Stefan: do I recall that this is a known issue? -- ___ Python tracker

[issue16422] Decimal constants should be the same for py & c module versions

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue16422] Decimal constants should be the same for py & c module versions

New submission from Yury Selivanov: Right now decimal.py defines 'ROUND_DOWN' as 'ROUND_DOWN' (string), whereas C version define it as 1 (integer). While using constant values directly in your code is not a good idea, there is another case where it doesn't work: if you serialize decimal values