Greg Ewing wrote:
> Ron Adam wrote:
>
>> 1. Remove None stored as indices in slice objects. Depending on the step
>> value, Any Nones can be converted to 0 or -1 immediately,
>
> But None isn't the same as -1 in a slice. None means the end
> of the sequence, whereas -1 means one less than the en
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > If every operation on a view returned a string copy, then what would be
> > the point of the view in the first place?
>
> String views would have all the same methods as a real
> string, so you could find(), index(), etc. while
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Those are all microbenchmarks. It's easy to prove the superiority of
> an approach that way. But what about realistic applications? What if
> your views don't end up saving memory or time for an application, but
> still cost in terms of added complex
On 8/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > You seem to be utterly convinced of the superior performance of your
> > proposal without having done any measurements.
>
> For my part, superior performance isn't the main
> reason for considering string views. Rathe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 28, 2006, at 9:20 PM, Greg Ewing wrote:
> I'm also not all that happy about forcing slice indices to
> be ints. Traditionally they are, but someone might want to
> define a class that uses them in a more general way.
In fact, we do. Our appli
Guido van Rossum wrote:
> You seem to be utterly convinced of the superior performance of your
> proposal without having done any measurements.
For my part, superior performance isn't the main
reason for considering string views. Rather it's
the simplification that would result from replacing
the
Ron Adam wrote:
> 1. Remove None stored as indices in slice objects. Depending on the step
> value, Any Nones can be converted to 0 or -1 immediately,
But None isn't the same as -1 in a slice. None means the end
of the sequence, whereas -1 means one less than the end.
I'm also not all that happ
Josiah Carlson wrote:
> If every operation on a view returned a string copy, then what would be
> the point of the view in the first place?
String views would have all the same methods as a real
string, so you could find(), index(), etc. while operating
efficiently on the original data. To my min
Raymond Hettinger wrote:
> Georg Brandl wrote:
>
>>In the meantime, I played around with the peepholer and tried to copy
>>the "for x in tuple_or_list" optimization for sets. Results are in SF
>>patch #1548082.
>>
> Did you mean "if x in tuple_or_list"? IIRC, there was some reason that
> mutabl
Guido van Rossum wrote:
>> > However you might be able to just cleanup the grammar so they are
>> > identical, that would be simpler I suspect.
>>
>> Looking at the grammar, there's only testlist_safe left to kill, in
>> favor of or_test like in generator expressions. The old_ rules are still
>> n
On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >> > Georg, can you do something about repr() of an empty set? This
> >> > currently produces "{}" while it should produce "set()".
> >>
> >> Right, forgot about that case. I'll correct that now.
> >> (Grr, I even min
Georg Brandl wrote:
>In the meantime, I played around with the peepholer and tried to copy
>the "for x in tuple_or_list" optimization for sets. Results are in SF
>patch #1548082.
>
>
>
Did you mean "if x in tuple_or_list"? IIRC, there was some reason that
mutable lists were not supposed to be
Those are all microbenchmarks. It's easy to prove the superiority of
an approach that way. But what about realistic applications? What if
your views don't end up saving memory or time for an application, but
still cost in terms of added complexity in all string operations?
Anyway, let me begin wit
Guido van Rossum wrote:
>> > Georg, can you do something about repr() of an empty set? This
>> > currently produces "{}" while it should produce "set()".
>>
>> Right, forgot about that case. I'll correct that now.
>> (Grr, I even mindlessly changed the unittest that would have caught it)
>
> Chec
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> Josiah (and other supporters of string views),
>
> You seem to be utterly convinced of the superior performance of your
> proposal without having done any measurements.
>
> You appear to have a rather naive view on what makes code execute fast
>
On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> At python.org/sf/1547796, there is a preliminary patch for Py3k set
> >> literals
> >> as specified in PEP 3100.
> >
> > Very cool! This is now checked in.
>
>
Guido van Rossum wrote:
> On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> At python.org/sf/1547796, there is a preliminary patch for Py3k set literals
>> as specified in PEP 3100.
>
> Very cool! This is now checked in.
Wow, that's fast...
> Georg, can you do something about repr() of an e
On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> At python.org/sf/1547796, there is a preliminary patch for Py3k set literals
> as specified in PEP 3100.
Very cool! This is now checked in.
Georg, can you do something about repr() of an empty set? This
currently produces "{}" while it should
Guido van Rossum wrote:
> (e.g. you don't seem to appreciate the savings due to a string
> object header and its data being consecutive in memory).
footnote: note that the Unicode string type still doesn't do that (my
original implementation *did* support string views, and nobody's ever
gotten
Josiah (and other supporters of string views),
You seem to be utterly convinced of the superior performance of your
proposal without having done any measurements.
You appear to have a rather naive view on what makes code execute fast
or slow (e.g. you don't seem to appreciate the savings due to a
Not much time to review the patch, but +1 on this -- I've described
this a few times in my Py3k talk, glad that some code is forthcoming
now!
--Guido
On 8/28/06, Brian Quinlan <[EMAIL PROTECTED]> wrote:
> It is my understanding that, in Python 3000, certain functions and
> methods that currently
Brian Quinlan wrote:
> It is my understanding that, in Python 3000, certain functions and
> methods that currently return lists will return some sort of view type
> (e.g. dict.values()) or an iterator (e.g. zip). So certain usage
> patterns will no longer be supported e.g. d.keys().sort().
>
> The
On 28-aug-2006, at 16:21, Edward C. Jones wrote:
>
> Brian Quinlan said:
>> It is my understanding that, in Python 3000, certain functions and
>> methods that currently return lists will return some sort of view
>> type
>> (e.g. dict.values()) or an iterator (e.g. zip). So certain usage
>> patt
On Monday 28 August 2006 10:21, Edward C. Jones wrote:
> d = dict()
> ...
> thekeys = d.keys()
> thekeys.sort()
> for key in thekeys:
> ...
>
> What should I use in Python 3.0?
d = dict()
...
for key in sorted(d.keys()):
...
-Fred
--
Fred L. Drake, Jr.
___
Brian Quinlan said:
> It is my understanding that, in Python 3000, certain functions and
> methods that currently return lists will return some sort of view type
> (e.g. dict.values()) or an iterator (e.g. zip). So certain usage
> patterns will no longer be supported e.g. d.keys().sort().
I us
Guido van Rossum wrote:
> On 8/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> I believe the current mixed model is actually an artifact of the
>> transition
>> from simple slicing to extended slicing,
>
> Really? Extended slicing mostly meant adding a third "step" option to
> the slice syntax,
Nick Coghlan wrote:
> This idea is inspired by the find/rfind string discussion (particularly a
> couple of comments from Jim and Ron), but I think the applicability may prove
> to be wider than just string methods (e.g. I suspect it may prove useful for
> the bytes() type as well).
If I'm foll
At python.org/sf/1547796, there is a preliminary patch for Py3k set literals
as specified in PEP 3100.
Set comprehensions are not implemented.
have fun,
Georg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/p
It is my understanding that, in Python 3000, certain functions and
methods that currently return lists will return some sort of view type
(e.g. dict.values()) or an iterator (e.g. zip). So certain usage
patterns will no longer be supported e.g. d.keys().sort().
The attached patch, which is a d
On 8/28/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> For when/*if* views ever become considered to be a good thing for
> builtin classes, etc, may I suggest that the following syntax be
> reserved for view creation:
>
> obj{start:stop:step}
>
> mapping to something like:
>
> def
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > If one wants a view of text, one needs to manually
> > construct the view via 'view = textview(st, start, stop)' or some
> > equivalent spelling. After that, any operations on a view returns views
>
> Given Guido's sensitivity abo
31 matches
Mail list logo
