>> So is having mutable bytes just a matter of calling them "byte
>> displays" instead of "byte literals" or does that also require
>> changing something in the back end?
Martin> It's certainly also an issue of language semantics (i.e. changes
Martin> to interpreter code). The
[EMAIL PROTECTED] wrote:
> >> So is having mutable bytes just a matter of calling them "byte
> >> displays" instead of "byte literals" or does that also require
> >> changing something in the back end?
>
> Martin> It's certainly also an issue of language semantics (i.e. changes
>
[+python-3000; replies please remove python-dev]
On 5/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote:
> >
> > On Saturday 05 May 2007, Aahz wrote:
> > > I'm with MAL and Fred on making literals immutable -- that's safe and
> > > lots of newbies
Mike Klaas <[EMAIL PROTECTED]> wrote:
> On 5/4/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
>
> > maybe we could have a "dedent" literal that would remove the first newline
> > and
> > all indentation so that you can just write:
> >
> > call_something( d'''
> > first part
>
I'd like to suggest that we remove all (or nearly all) uses of
xrange from the stdlib. A quick scan shows that most of the usage
of it is unnecessary. With it going away in 3.0, and it being
informally deprecated anyway, it seems like a good thing to go away
where possible.
Any objections?
Ant
But why bother? The 2to3 converter can do this for you.
In a sense using range() is more likely to produce broken results in
3.0: if your code depends on the fact that range() returns a list, it
is broken in 3.0, and 2to3 cannot help you here. But if you use
list(xrange()) today, the converter wil
>> Surely
>>
>> from textwrap import dedent as d
>>
>> is close enough?
Nick> Apart from it happening at run time rather than compile time.
And as someone else pointed out, what if you don't want each chunk of text
terminated by a newline?
Skip
_
On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
> I'd like to suggest that we remove all (or nearly all) uses of
> xrange from the stdlib. A quick scan shows that most of the usage
> of it is unnecessary. With it going away in 3.0, and it being
> informally deprecated anyway, it
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| But why bother? The 2to3 converter can do this for you.
|
| In a sense using range() is more likely to produce broken results in
| 3.0: if your code depends on the fact that range() returns a list, it
| is broken in
> I'd like to suggest that we remove all (or nearly all) uses of
> xrange from the stdlib. A quick scan shows that most of the usage
> of it is unnecessary. With it going away in 3.0, and it being
> informally deprecated anyway, it seems like a good thing to go away
> where possible.
>
>Any obj
On 5/7/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | But why bother? The 2to3 converter can do this for you.
> |
> | In a sense using range() is more likely to produce broken results in
> | 3.0: if your code depen
11 matches
Mail list logo
