Re: [Python-Dev] \code or \constant in tex markup
On Wednesday 09 May 2007, Neal Norwitz wrote:
Which is correct?
\constant was introduced much more recently than \code (though it's not really
new anymore). The intent for \constant when it was introduced was that it be
used for names that were treated as constants in code (such as
string.ascii_letters or doctest.REPORT_NDIFF), not syntactic literals like 3
or abc.
At the time, None, True, and False were just named values in the __builtin__
module. I don't think the support for None as a real constant should
change the status of the value as just another named constant other than in
the implementation details.
So I think \constant is right for all three; we just haven't gone back and
changed all the older instances of \code{None}, \code{True}, and
\code{False}. We've generally resisted that sort of blanket change, but
consistency is valuable too. Perhaps it's time to make the change across the
board.
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Official version support statement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This came up in a different context. I originally emailed this to the python.org admins, but Aahz rightly points out that we should first agree here that this actually /is/ our official stance. - -snip- We have an official unofficial policy of supporting only Python 2.current and 2.(current - 1), and /not/ supporting anything earlier. Do we already have an official statement to this effect on the website? The closest thing I could find was on the download page, but that's not really definitive. What do you think about adding something like the following to the top of the download page: The Python Software Foundation officially supports the current stable major release and one prior major release. Currently, Python 2.5 and 2.4 are officially supported. Where appropriate and necessary, patches for earlier releases may be made available, but no earlier versions are officially supported by the PSF. We do not make releases of unsupported versions, although patched versions may become available through other vendors. - -Barry P.S. On re-reading this, I realize this text would need amending when Python 3.x is released, but I don't care about that right now. pdo admins: I also slightly changed the proposed text. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkM1/XEjvBPtnXfVAQJufwP9E4A7cbHyDRk0v/hONjlt3ZJ2eCtwYZL6 hlitMIBb8YxJsGNo6p1kC0KkB/DObqmCarTy8YXIM+v8j32UmEbiRmJFxexuKdVw I0EqziHnYdSkkp3cN+EGP2jahfLFVMaA2A2Ohj0o0mLGZEQU7TTF4F6U33PlooXs G6zKmDzuLT4= =BWxm -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Hard-to-find problem with set().test_c_api()
Could anyone help me debug the following? This is in a debug build of
the trunk. I've been banging my head against the wrong wall for too
long to see the issue here... :-(
$ ./python -S -c set('abc').test_c_api()
[6872 refs]
Fatal Python error: ../Objects/stringobject.c:4971 object at
0xb7f66ca0 has negative ref count -606348326
Aborted
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
Barry Warsaw [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | This came up in a different context. I originally emailed this to | the python.org admins, but Aahz rightly points out that we should | first agree here that this actually /is/ our official stance. | | - -snip- | | We have an official unofficial policy of supporting only Python | 2.current and 2.(current - 1), and /not/ supporting anything earlier. | | Do we already have an official statement to this effect on the | website? The closest thing I could find was on the download page, | but that's not really definitive. | | What do you think about adding something like the following to the | top of the download page: | | The Python Software Foundation officially supports the current | stable major release and one prior major release. Currently, Python | 2.5 and 2.4 are officially supported. Where appropriate and | necessary, patches for earlier releases may be made available, but no | earlier versions are officially supported by the PSF. We do not make | releases of unsupported versions, although patched versions may | become available through other vendors. This strikes me as a bit over-officious (the 'officially' adds nothing to me except a bit of stuffiness). Worse, it seems wrong and hence, to me, misleading. The current de facto policy is that when a new major release comes out, there is a *final* minor, bugfix release of the previous major version. Thus, 2.5 is being supported while 2.6 is being worked on. As I understand it, there are no more plans to touch 2.4 than 2.3 and so on. So the current message is: If you want a 2.5 bug fixed, find it, report it, and help get it fixed now before 2.6 is released. I am aware that if a trustworthy person or persons were to backport some substantial numbers of fixes from 2.5 to 2.4, greenlight the test suite on several systems, cut release candidates, and repond to reports, the file would appear on the official Python site. But currently, as far as I know, this 'support' is as empty as the Official Help-Yourself Plate of Donated Cookies on my kitchen table. The reason, is seems to me, that prior major releases do not get support is that they do not much need it. For practical purposes, core CPython is pretty much bug free. Module bugs get reported and fixed or worked around. Old users can upgrade if they want fixes that appear later. And new users generally start with the current major release. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hard-to-find problem with set().test_c_api()
Never mind, I found it via bisection of the offending function, and fixed it:
Committed revision 55227.
--Guido
On 5/10/07, Guido van Rossum [EMAIL PROTECTED] wrote:
Could anyone help me debug the following? This is in a debug build of
the trunk. I've been banging my head against the wrong wall for too
long to see the issue here... :-(
$ ./python -S -c set('abc').test_c_api()
[6872 refs]
Fatal Python error: ../Objects/stringobject.c:4971 object at
0xb7f66ca0 has negative ref count -606348326
Aborted
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] \u and \U escapes in raw unicode string literals
I just discovered that, in all versions of Python as far back as I have access to (2.0), \u escapes are interpreted inside raw unicode strings. Thus: a = ur\u1234 len(a) 1 Contrast this with: a = ur\x12 len(a) 4 The \U escape has the same behavior, in versions that support it. Does anyone remember why it is done this way? The reference manual describes this behavior, but doesn't give an explanation: When an r or R prefix is used in conjunction with a u or U prefix, then the \u and \U escape sequences are processed while all other backslashes are left in the string. For example, the string literal ur\u0062\n consists of three Unicode characters: `LATIN SMALL LETTER B', `REVERSE SOLIDUS', and `LATIN SMALL LETTER N'. Backslashes can be escaped with a preceding backslash; however, both remain in the string. As a result, \u escape sequences are only recognized when there are an odd number of backslashes. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 10/05/07, Guido van Rossum [EMAIL PROTECTED] wrote: I just discovered that, in all versions of Python as far back as I have access to (2.0), \u escapes are interpreted inside raw unicode strings. Thus: [...] Does anyone remember why it is done this way? The reference manual describes this behavior, but doesn't give an explanation: My memory is so dim as to be more speculation than anything else, but I suspect it's simply because there's no other way of including characters outside the ASCII range in a raw string. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 2007-05-10 20:53, Paul Moore wrote: On 10/05/07, Guido van Rossum [EMAIL PROTECTED] wrote: I just discovered that, in all versions of Python as far back as I have access to (2.0), \u escapes are interpreted inside raw unicode strings. Thus: [...] Does anyone remember why it is done this way? The reference manual describes this behavior, but doesn't give an explanation: My memory is so dim as to be more speculation than anything else, but I suspect it's simply because there's no other way of including characters outside the ASCII range in a raw string. This is per design (see PEP 100) and was done for the reason given by Paul. The motivation for the chosen approach was to make Python's raw Unicode strings compatible to Java's raw Unicode strings: http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 10 2007) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
On Thursday 10 May 2007, Barry Warsaw wrote: This came up in a different context. I originally emailed this to the python.org admins, but Aahz rightly points out that we should first agree here that this actually /is/ our official stance. +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New operations in Decimal
Facundo Batista [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Nick Maclaren wrote: | | Am I losing my marbles, or is this a proposal to add the logical | operations to FLOATING-POINT? | | Sort of. This is a proposal to keep compliant with the General Decimal | Arithmetic Specification, as we promised. | | http://www2.hursley.ibm.com/decimal/ I oppose adding this illogical nonsense to Python. Who would ever use it? An intention and promise to keep compliant with a *decimal arithmetic* standard cannot sanely be a blind, open-ended promise to add whatever *non-decimal* functions that IBM puts where they do not belong as part of its commercial strategem. To me, the same would go for any other standard similarly twisted. Supposed IBM defined a mapping between pairs of decimal digits and an ascii subset (printables and the few control chars actually used by most people). Suppose IBM further defined string functions for decimal nuumbers intrerpreted as strings. An example might be 'capitalize', such that capitalize(010203) == 010203 capitalize(121110) == 424140 # 10='a', 40 = 'A', etc And suppose that IBM shoved this into the decimal standard the same way it did with the decimal-interpreded-as-binary-string' functions. Would you really add them to be 'compliant' with IBM? If you really do put them in, turn 'invert' into 'prefix_not'. For the prefix, please not 'logical' but something like 'lu' (for 'lunatic') or, less provocatively, 'ibm'. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 5/10/07, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2007-05-10 20:53, Paul Moore wrote: On 10/05/07, Guido van Rossum [EMAIL PROTECTED] wrote: I just discovered that, in all versions of Python as far back as I have access to (2.0), \u escapes are interpreted inside raw unicode strings. Thus: [...] Does anyone remember why it is done this way? The reference manual describes this behavior, but doesn't give an explanation: My memory is so dim as to be more speculation than anything else, but I suspect it's simply because there's no other way of including characters outside the ASCII range in a raw string. This is per design (see PEP 100) and was done for the reason given by Paul. The motivation for the chosen approach was to make Python's raw Unicode strings compatible to Java's raw Unicode strings: http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html I'm not sure what Java compatibility buys us. It is also far from perfect -- IIUC, in Java if you write \u0022 (that's the character) it counts as an opening or closing quote, and if you write \u005c (a backslash) it can be used to escape the following character. OTOH, in Python, you can write urC:\Program Files\u005c and voila, a raw string terminating in a backslash. (In Java this would escape the instead.) However, I understand the other reason (inclusion of non-ASCII characters in raw strings) and I reluctantly agree with it. Reluctantly, because it means I can't create a raw string containing a \ followed by u or U -- I needed one of those today. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 2007-05-11 00:11, Guido van Rossum wrote: On 5/10/07, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2007-05-10 20:53, Paul Moore wrote: On 10/05/07, Guido van Rossum [EMAIL PROTECTED] wrote: I just discovered that, in all versions of Python as far back as I have access to (2.0), \u escapes are interpreted inside raw unicode strings. Thus: [...] Does anyone remember why it is done this way? The reference manual describes this behavior, but doesn't give an explanation: My memory is so dim as to be more speculation than anything else, but I suspect it's simply because there's no other way of including characters outside the ASCII range in a raw string. This is per design (see PEP 100) and was done for the reason given by Paul. The motivation for the chosen approach was to make Python's raw Unicode strings compatible to Java's raw Unicode strings: http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html I'm not sure what Java compatibility buys us. It is also far from perfect -- IIUC, in Java if you write \u0022 (that's the character) it counts as an opening or closing quote, and if you write \u005c (a backslash) it can be used to escape the following character. OTOH, in Python, you can write urC:\Program Files\u005c and voila, a raw string terminating in a backslash. (In Java this would escape the instead.) http://mail.python.org/pipermail/python-dev/1999-November/001346.html http://mail.python.org/pipermail/python-dev/1999-November/001392.html and all the other postings in that month related to this. However, I understand the other reason (inclusion of non-ASCII characters in raw strings) and I reluctantly agree with it. Reluctantly, because it means I can't create a raw string containing a \ followed by u or U -- I needed one of those today. print ur\u005cu \u -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 11 2007) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
The Python Software Foundation officially supports the current stable major release and one prior major release. Currently, Python 2.5 and 2.4 are officially supported. If you take officially supported to mean there will be further bugfix releases, then no: 2.4 is not anymore officially supported. Only 2.5 is officially supported. There may, of course, be security patches released for 2.4 if there is a need. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
However, I understand the other reason (inclusion of non-ASCII characters in raw strings) and I reluctantly agree with it. I actually disagree with that. It is fairly easy to include non-ASCII characters in a raw Unicode string - just type them in. Or, if that fails, use string concatenation with a non-raw string: rfoo\uhallo \u20ac rwelt Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New operations in Decimal
| Am I losing my marbles, or is this a proposal to add the logical | operations to FLOATING-POINT? | | Sort of. This is a proposal to keep compliant with the General Decimal | Arithmetic Specification, as we promised. | | http://www2.hursley.ibm.com/decimal/ I oppose adding this illogical nonsense to Python. Who would ever use it? Doesn't matter. What is more important is that we provide a module that is fully compliant with the specification and passes all of its tests. The value is in the compliance, not in the relative value of individual parts of the spec. This is somewhat akin to modules supporting RFC specs or internet protocols. It is more important to be standard than it is to pick and choose the parts you like. The same is true of writing ANSI spec compilers -- you write to the spec, not to the language you wish had been adopted. While I question the sanity of the spec writers in this case, I do trust that overall, they have provided an extremely well thought-out spec, have gone through extensive discussion/feedback cycles, and have provided a thorough test-suite. It is as good as it gets. Raymond Hettinger ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 5/10/07, Martin v. Löwis [EMAIL PROTECTED] wrote: However, I understand the other reason (inclusion of non-ASCII characters in raw strings) and I reluctantly agree with it. I actually disagree with that. It is fairly easy to include non-ASCII characters in a raw Unicode string - just type them in. That violates the convention used in many places that source code should only contain printable ASCII, and all non-ASCII or unprintable characters should be written using \x or \u escapes. Or, if that fails, use string concatenation with a non-raw string: rfoo\uhallo \u20ac rwelt That makes for pretty unreadable source code though. Looking for a third opinion, -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
I actually disagree with that. It is fairly easy to include non-ASCII characters in a raw Unicode string - just type them in. That violates the convention used in many places that source code should only contain printable ASCII, and all non-ASCII or unprintable characters should be written using \x or \u escapes. Following that convention: How do you get a non-ASCII byte into a raw byte string in Python 2.x? You can't - so why should you be able to get a non-ASCII character into a raw Unicode string? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 5/10/07, Martin v. Löwis [EMAIL PROTECTED] wrote: I actually disagree with that. It is fairly easy to include non-ASCII characters in a raw Unicode string - just type them in. That violates the convention used in many places that source code should only contain printable ASCII, and all non-ASCII or unprintable characters should be written using \x or \u escapes. Following that convention: How do you get a non-ASCII byte into a raw byte string in Python 2.x? You can't - so why should you be able to get a non-ASCII character into a raw Unicode string? Fair enough. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
Martin v. Löwis wrote: why should you be able to get a non-ASCII character into a raw Unicode string? The analogous question would be why can't you get a non-Unicode character into a raw Unicode string. That wouldn't make sense, since Unicode strings can't even hold non-Unicode characters (or at least they're not meant to). But it doesn't seem unreasonable to want to put Unicode characters into a raw Unicode string. After all, if it only contains ASCII characters there's no need for it to be a Unicode string in the first place. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
On 5/10/07, Greg Ewing [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: why should you be able to get a non-ASCII character into a raw Unicode string? The analogous question would be why can't you get a non-Unicode character into a raw Unicode string. That wouldn't make sense, since Unicode strings can't even hold non-Unicode characters (or at least they're not meant to). But it doesn't seem unreasonable to want to put Unicode characters into a raw Unicode string. After all, if it only contains ASCII characters there's no need for it to be a Unicode string in the first place. This is what prompted my question, actually: in Py3k, in the str/unicode unification branch, r\u1234 changes meaning: before the unification, this was an 8-bit string, where the \u was not special, but now it is a unicode string, where \u *is* special. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New operations in Decimal
Raymond Hettinger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | I oppose adding this illogical nonsense to Python. Who would ever use it? | | Doesn't matter. What is more important is that we provide a module that is | fully compliant with the specification and passes all of its tests. The value | is in the compliance, not in the relative value of individual parts of the spec. To repeat my further question: if IBM adds string functions or anything else to the 'decimal arithmetic' spec, should we unthinkingly add them also? Is there there no limit to the size of the camel that comes in with the nose? Suppose the next edition of the spec contains decimal versions of the functions in numpy (BLAS, LINPACK, FTTPACK, and so on). Should they be included in the standard lib even while numpy is excluded. We supposedly have a standard for additions to the standard lib. I cannot think of any other module being admitted with what amounts to an unlimited blank check for further additions. | This is somewhat akin to modules supporting RFC specs or internet | protocols. It is more important to be standard than it is to pick and choose | the parts you like. My impresssion from reading this list is that some of the modules supporting such specs/protocols are not complete and that there has been some picking and choosing. Wasn't there recently discussion about DOM level compliance? In any case, once RFCs are finalized, they does not, as far as I know, grow with additions, sane or crazy. Nex stuff goes in a new RFC which can be evaluated separately against our normal criteria for stdlib additions. | While I question the sanity of the spec writers in this case, I do trust that | overall, they have provided an extremely well thought-out spec, have gone | through extensive discussion/feedback cycles, and have provided a thorough | test-suite. It is as good as it gets. I had the same opinion until I saw the logic stuff. But I have known IBM and its products, good and bad, for over 40 years, so it does not surprise me when they act somewhat imperialistically for commercial advantage. This strikes me as likely such a case. But I may give M.C. a chance to better educate me. In the meanwhile here is my suggestion. Segregate the binary digit functions, and anything else of their ilk, in a separate module, say decimal_extras, and make it available on PyPI. In decimal, add try: from decimal_extras import * except ImportError: pass Then the tests could pass without junking up the stdlib with stuff that would never even be proposed, let alone accepted. And should I be proved wrong, and these functions find favor with the community and usage in production code, then they can be seamlessly moved into the stdlib and the decimal module after having met the test of other additions. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New operations in Decimal
We supposedly have a standard for additions to the standard lib. I cannot think of any other module being admitted with what amounts to an unlimited blank check for further additions. xml.dom.minidom, xml.sax, posix, htmlentitydefs, Tkinter. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
Greg Ewing schrieb: Martin v. Löwis wrote: why should you be able to get a non-ASCII character into a raw Unicode string? The analogous question would be why can't you get a non-Unicode character into a raw Unicode string. No, that would not be analogous. The string type in Python is not an ASCII string type, but a byte string type. It does not necessarily only hold ASCII characters, but can (and, in hundreds of applications) does hold arbitrary bytes. There is (in the non-raw form) support of filling arbitrary bytes into a byte string literal. So no, this is not analogous. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] \u and \U escapes in raw unicode string literals
This is what prompted my question, actually: in Py3k, in the str/unicode unification branch, r\u1234 changes meaning: before the unification, this was an 8-bit string, where the \u was not special, but now it is a unicode string, where \u *is* special. That is true for non-raw strings also: the meaning of \u1234 also changes. However, traditionally, there was *no* escaping mechanism in raw strings in Python, and I feel that this is a good principle, because it is easy to learn (if you leave out the detail that \ can't be the last character in a raw string - which should get fixed also, IMO). So I think in Py3k, \u1234 should continue to be a string with 6 characters. Otherwise, people will complain that os.stat(rc:\windows\system32\user32.dll) fails. Telling them to write os.stat(rc:\windows\system32\u005Cuser32.dll) will just cause puzzled faces. Windows path names are one of the two primary applications of raw strings (the other being regexes). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
