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.a
-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" p
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
0xb7f66c
"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 actu
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 th
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
> descr
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
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.
_
"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 Spe
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
> >
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
> "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 officia
> 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 w
| > 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 n
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
>> 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 w
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 printabl
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, si
"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
> 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
i
> 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 al
24 matches
Mail list logo
