Phillip J. Eby wrote:
> I'm tempted to say it would be even better if there was a command line
> option that could be used to force all binary opens to result in bytes, and
> require all text opens to specify an encoding.
For Python 3000? -1. There shouldn't be command line switches that have
th
Neil Hodgson wrote:
>I'd like to more tightly define Unicode strings for Python 3000.
> Currently, Unicode strings may be implemented with either 2 byte
> (UCS-2) or 4 byte (UTF-32) elements. Python should allow strings to
> contain any Unicode character and should be indexable yielding
> chara
Tim Peters wrote:
>[Adam Olsen]
>
>>https://sourceforge.net/tracker/index.php?func=detail&aid=1334979&group_id=5470&atid=305470>
>>
>>That patch removes the division from the loop (and fixes the bugs),
>>but gives only a small increase in speed.
>>
>In any case, I agree it _should_ fix the bugs (a
Guido van Rossum:
> Folks, please focus on what Python 3000 should do.
>
> I'm thinking about making all character strings Unicode (possibly with
> different internal representations a la NSString in Apple's Objective
> C) and introduce a separate mutable bytes array data type. But I could
> use s
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a bit incomplet
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Reinhold Birkenfeld wrote:
> > Michele Simionato wrote:
> >> As other explained, the syntax would not work for functions (and it is
> >> not intended to).
> >> A possible use case I had in mind is to define inlined modules to be
> >> used as bunches
> >
At 06:06 PM 10/23/2005 -0700, Guido van Rossum wrote:
>Folks, please focus on what Python 3000 should do.
>
>I'm thinking about making all character strings Unicode (possibly with
>different internal representations a la NSString in Apple's Objective
>C) and introduce a separate mutable bytes array
On Oct 23, 2005, at 6:06 PM, Guido van Rossum wrote:
> Folks, please focus on what Python 3000 should do.
>
> I'm thinking about making all character strings Unicode (possibly with
> different internal representations a la NSString in Apple's Objective
> C) and introduce a separate mutable bytes a
Folks, please focus on what Python 3000 should do.
I'm thinking about making all character strings Unicode (possibly with
different internal representations a la NSString in Apple's Objective
C) and introduce a separate mutable bytes array data type. But I could
use some validation or feedback on
On Sunday 23 October 2005 18:10, Jason Orendorff wrote:
> -1 on keeping the source encoding of string literals. Python should
> definitely decode them at compile time.
>
> -1 on decoding implicitly "as needed". This causes decoding to happen
> late, in unpredictable places. Decodes can fail; the
On Oct 23, 2005, at 3:10 PM, Jason Orendorff wrote:
> -1 on decoding implicitly "as needed". This causes decoding to happen
> late, in unpredictable places. Decodes can fail; they should happen
> as early and as close to the data source as possible.
That's not necessarily true... Some codecs c
On 10/23/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a b
On 10/23/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Actually, you've just pointed out a new complication introduced by having
> __context__. The return value of __context__ is supposed to have an
> __enter__ and an __exit__. Is it a type error if it doesn't? How do we
> handle that, exactly
I've had this PEP laying around for quite a few months. It was inspired
by some code we'd written which wanted to be able to get immutable
versions of arbitrary objects. I've finally finished the PEP, uploaded
a sample patch (albeit a bit incomplete), and I'm posting it here to see
if there is an
-1 on keeping the source encoding of string literals. Python should
definitely decode them at compile time.
-1 on decoding implicitly "as needed". This causes decoding to happen
late, in unpredictable places. Decodes can fail; they should happen
as early and as close to the data source as possi
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> I'd like to start the subversion switchover this coming Wednesday,
> with a total commit freeze at 16:00 GMT.
Yay! Thanks again for doing this.
Cheers,
mwh
--
[Perl] combines all the worst aspects of C and Lisp: a billion
different sublangua
On 10/23/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Actually, you've just pointed out a new complication introduced by having
> __context__. The return value of __context__ is supposed to have an
> __enter__ and an __exit__. Is it a type error if it doesn't? How do we
> handle that, exactly
[EMAIL PROTECTED] wrote:
> How could I build the python interpreter for an embedded linux target system
> (arm9 based), cross-compiling on a linux PC host?
No. news:comp.lang.python (aka: mailto:python-list@python.org) would be
the right list.
This would be the right list for the question "I mad
There's a patch on sourceforge for cross compiling. I haven't used it
personally.
http://sourceforge.net/tracker/index.php?func=detail&aid=1006238&group_id=5470&atid=305470
Jeff
pgpzVmD49shTu.pgp
Description: PGP signature
___
Python-Dev mailing lis
I'd like to start the subversion switchover this coming Wednesday,
with a total commit freeze at 16:00 GMT. If you have larger changes
to commit that you would like to commit before the switchover, but
after that date, please let me know.
At that point, I will set the repository to read-only (thro
At 09:19 AM 10/23/2005 -0700, Guido van Rossum wrote:
>On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > However, I'm still concerned about the fact that the following class has a
> > context manager that doesn't actually work:
> >
> >class Broken(object):
> > def __context__(self):
On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However, I'm still concerned about the fact that the following class has a
> context manager that doesn't actually work:
>
>class Broken(object):
> def __context__(self):
> print "This never gets executed"
> yield
>
is this the right place to ask:
How could I build the python interpreter for an embedded linux target system
(arm9 based), cross-compiling on a linux PC host?
thanks, Giovanni Angeli.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
M.-A. Lemburg wrote:
> I've checked in a whole bunch of newly generated codecs
> which now make use of the faster charmap decoding variant added
> by Walter a short while ago.
>
> Please let me know if you find any problems.
I think we should work on eliminating the decoding_map variables.
There
[Phillip J. Eby]
> your observation actually means that the bug, if any, was somewhere
> else, or was inadvertently fixed or hidden by the AST branch merge.
What a nice side benefit :-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://
Reinhold Birkenfeld wrote:
> Michele Simionato wrote:
>> As other explained, the syntax would not work for functions (and it is
>> not intended to).
>> A possible use case I had in mind is to define inlined modules to be
>> used as bunches
>> of attributes. For instance, I could define a module as
Guido van Rossum wrote:
> Here's another argument against automatically decorating __context__.
>
> What if I want to have a class with a __context__ method that returns
> a custom context manager that *doesn't* involve applying
> @contextmanager to a generator?
>
> While technically this is poss
27 matches
Mail list logo
