Terry Reedy wrote:
> If orig_data were mutable (the new buffer, as proposed in the PEP), would
> not
>
> for i in range(len(orig_data)):
> orig_data[i] &= 0x1F
>
> do it in place? (I don't have .0a1 to try on the current bytes.)
Good catch!
Python 3.0a1 (py3k:58282, Sep 29 2007, 15:07:57)
[G
I am hereby accepting my own PEP 3137. The responses fell into three
categories: enthusiastic +1s, textual corrections, and ideas for
future enhancements. That's about as positive as it gets for any
proposal. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
I've submitted patches to emacs for python 3000 support. It does not
handle any new syntax but the emacs<->python interaction works again.
This applies to the python.el that ships with emacs22, not
python-mode.el.
The changes are available in emacs cvs. If you don't want to build a
new copy it s
On 10/2/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
> I've submitted patches to emacs for python 3000 support. It does not
> handle any new syntax but the emacs<->python interaction works again.
> This applies to the python.el that ships with emacs22, not
> python-mode.el.
Just curious -- how do pyt
On 10/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Just curious -- how do python.el and python-mode.el differ?
Off the top of my head:
* python-mode.el did not play well with transient-mark-mode
(mark-block didn't work). transient-mark-mode highlights the marked
region and is required
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 2, 2007, at 11:28 AM, Adam Hupp wrote:
> On 10/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>
>> Just curious -- how do python.el and python-mode.el differ?
>
> Off the top of my head:
>
> * python-mode.el did not play well with transien
"Christian Heimes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
| > If orig_data were mutable (the new buffer, as proposed in the PEP),
would
| > not
| >
| > for i in range(len(orig_data)):
| > orig_data[i] &= 0x1F
| >
| > do it in place? (I don't have .0a1
So is python.el a descendant of python-mode.el, or an independent development?
On 10/2/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
> On 10/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > Just curious -- how do python.el and python-mode.el differ?
>
> Off the top of my head:
>
> * python-mo
On 10/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So is python.el a descendant of python-mode.el, or an independent development?
I've never seen a definitive statement but I believe it was developed
independently.
--
Adam Hupp | http://hupp.org/adam/
_
Guido> So is python.el a descendant of python-mode.el, or an independent
Guido> development?
Adam> I've never seen a definitive statement but I believe it was
Adam> developed independently.
Correct.
Skip
___
Python-3000 mailing list
Py
Dnia 28-09-2007, Pt o godzinie 18:58 +0200, Victor Stinner pisze:
> I don't know GMP internals. I thaught that GMP uses an hack for small
> integers.
It does not.
(And I'm glad that it does not, because it allows for super-specialized
representation of small integers where even the space for mpz
In Python 3.0a1, exec() appears to normalize strings, but in other cases
they don't appear to be normalized, and this leads to results that
appear to be counter-intuitive in some cases, at least to me.
>>> c1 = "\u00C7"
>>> c2 = "C\u0327"
>>> c3 = "\u0043\u0327"
>>> c1, c2, c3
String objects are arrays of code units. They can represent normalized
and unnormalized Unicode text just as easily, and even invalid data,
like half a surrogate and other illegal code units. It is up to the
application (or perhaps at some point the library) to implement
various checks and normaliz
13 matches
Mail list logo
