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
-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
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
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
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
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
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
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
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
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
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
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
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
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
| 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
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
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
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
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
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
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
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
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
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:
24 matches
Mail list logo
