On 3/30/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Aahz" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > What do we want to tell people who have code like this:
> >
> > keys = d.keys()
> > keys.sort()
>
> Could a good-enough code analyzer detect such, even if separated by
> i
"Aahz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> What do we want to tell people who have code like this:
>
> keys = d.keys()
> keys.sort()
Could a good-enough code analyzer detect such, even if separated by
intervening lines? If so, it could suggest sorted() as a fix. I wo
Alex Martelli wrote:
> On Mar 30, 2006, at 5:53 PM, Greg Ewing wrote:
> ...
>>> Generally speaking I've remained suspicious of adaptation.
>> I think to most people it seems like a solution
>> looking for a problem. In all the code I've ever
>> written, plain duck typing has been perfectly
>> a
> Adam DePrince wrote:
> > No reason we can't make other string operations views as well ...
> > concatenation is one example. If I recall, that's how snobol handles
> > strings, view upon view upon view.
But that's irrelevant for immutable strings -- views are about
semantic links, not implement
Alex Martelli wrote:
> If the framework consuming X requested adaptation-to-X on all objects
> it's passed,
This is the part that bothers me, I think. It
seems like all these adaptation requests would
be a huge burden on the framework developer.
In PyGUI, for example, I currently have about
2 o
On Mar 30, 2006, at 5:53 PM, Greg Ewing wrote:
...
>> Generally speaking I've remained suspicious of adaptation.
>
> I think to most people it seems like a solution
> looking for a problem. In all the code I've ever
> written, plain duck typing has been perfectly
> adequate. I'm willing to con
Adam DePrince wrote:
> Views
> are not generated, they are either directly implemented, or returned.
If you're thinking that the object would keep a set of
pre-allocated views, there's a problem with that --
the views need to have a reference to the base object,
thus creating a circular reference.
Adam DePrince wrote:
> No reason we can't make other string operations views as well ...
> concatenation is one example. If I recall, that's how snobol handles
> strings, view upon view upon view.
I don't think it was quite as bad as that. If I
remember correctly, when you took a substring
you d
Aahz wrote:
> What do we want to tell people who have code like this:
>
> keys = d.keys()
> keys.sort()
I think the view returned in this case should be
immutable, so that the above fails. Then we tell
them to replace it with
keys = sorted(d.keys())
In general, where we're changing the sema
Ian Bicking wrote:
> Though if "Set([(1, None), (2, None)]) ==
> {1: None, 2: None}" is true, that's actually perfectly fine to me.
That would be rather too loose for my tastes. A mapping
can be *represented* as a set of tuples, but that's not
the same thing as it *being* a set of tuples.
> Gen
On 3/30/06, Aahz <[EMAIL PROTECTED]> wrote:
> What do we want to tell people who have code like this:
>
> keys = d.keys()
> keys.sort()
>
> Not so much in terms of the fix, but where/why we drew the line about
> what's supported by the value returned by d.keys() and what's not. I'm
> not getting c
Guido van Rossum wrote:
> But do we really want this? It's a pretty serious change in basic
> semantics of collection data types, *and* it requires us to find a way
> to determine unequivocally whether something is a set, sequence,
> mapping, or multiset (and it can't be more than one!).
If we *
On Thu, Mar 30, 2006, Guido van Rossum wrote:
>
> Java does it this way and I think we can do the same thing:
>
> keys() and items() return views that behave like sets; values()
> returns a view that behaves like a collection (aka multiset or bag).
> Neither behaves like a list, which means that t
Fabien Schwob wrote:
> for x in iter1 and y in iter2:
It would be tricky to avoid having that
parsed as
for x in (iter1 and y in iter2):
since 'in' is also a valid part of an expression.
That's one of ther reasons I suggested parens
around the whole thing, which would make it
unambiguous.
T
Guido van Rossum wrote:
>>A collection-specific protocol for testing equality would be reasonable.
>
>
> I'm not sure what you mean here. Are you proposing using a different
> method than __eq__()?
No, that a collection that wanted to do a nice equality test might do
something like:
class Set:
On 3/30/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Set-like is anything that subclasses baseset?
No, it should to support duck typing.
> But maybe there's a
> deeper answer somewhere, as base* types seem a bit kludgy.
Not just kludgy, but unpythonic.
> A collection-specific protocol for testi
Guido van Rossum wrote:
> On 3/30/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>>Adam DePrince wrote:
>>
>>>There seemed to be a concensus in the community on the size of the view
>>>proposal, and I'm reimplementing the PEP to reflect that. But what I
>>>can't resolve is the other anciliary issu
On 3/30/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Adam DePrince wrote:
> > There seemed to be a concensus in the community on the size of the view
> > proposal, and I'm reimplementing the PEP to reflect that. But what I
> > can't resolve is the other anciliary issue: "To list or iter." I'm no
Adam DePrince wrote:
> There seemed to be a concensus in the community on the size of the view
> proposal, and I'm reimplementing the PEP to reflect that. But what I
> can't resolve is the other anciliary issue: "To list or iter." I'm not
> yet ready to resolve that issue. The views don't resolv
Hello,
On 3/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Barry made me the list owner for python-3000 and python-3000-checkins.
> That's fine for a while, but long term I need to delegate this. Any
> volunteers? (Especially during my trip to the UK I won't have time to
> attend to the list
On Thu, 2006-03-30 at 12:05 +1200, Greg Ewing wrote:
> Adam DePrince wrote:
>
> > SetView implements:
> >.__contains__
> >.add
> >.discard
> >.__len__
>
> But what would there be to inherit from the mixin?
> Each view class will have entirely its own implementation
> of these, d
On Thu, 2006-03-30 at 12:05 +1200, Greg Ewing wrote:
> Stefan Rank wrote:
>
> >A big question is: Should slicing also return views? and why not?
>
> That's been considered before, in relation to strings.
> The stumbling block is the problem of a view of a
> small part of the object keeping th
On Thu, 2006-03-30 at 20:23 +1000, Nick Coghlan wrote:
> Robert Brewer wrote:
> > Nick Coghlan wrote:
> >> There are three big use cases:
> >>
> >>dict.keys
> >>dict.values
> >>dict.items
> >>
> >> Currently these all return lists, which may be expensive in
> >> terms of copying. They
I've got two volunteers. Thanks!
On 3/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Barry made me the list owner for python-3000 and python-3000-checkins.
> That's fine for a while, but long term I need to delegate this. Any
> volunteers? (Especially during my trip to the UK I won't have ti
Guido> Barry made me the list owner for python-3000 and
Guido> python-3000-checkins. That's fine for a while, but long term I
Guido> need to delegate this. Any volunteers?
Feel free to add me. I moderate a number of lists and have a little script
that helps me plow through moderatio
On Thursday 30 March 2006 12:32, Guido van Rossum wrote:
> Barry made me the list owner for python-3000 and python-3000-checkins.
> That's fine for a while, but long term I need to delegate this. Any
> volunteers? (Especially during my trip to the UK I won't have time to
> attend to the list ow
On Wed, 2006-03-29 at 11:08 -0800, Brett Cannon wrote:
> On 3/29/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
> >
> > > set interface where we could have a __container__/__view__/__set__
> >
> > Why would I call a method to get a view on an object when the object can
> > just as well implement the
Barry made me the list owner for python-3000 and python-3000-checkins.
That's fine for a while, but long term I need to delegate this. Any
volunteers? (Especially during my trip to the UK I won't have time to
attend to the list owner responsibilities.)
There's really not much to do, except maybe a
[sni[]
> All I think we're currently missing is an idea of 'what magic methods does an
> object need to provide in order to pretend to be a container, rather than
> just
> an iterable?'
>
> Change dict.keys/values/items to return views which implement that set of
> methods, and all should be g
Save your breath on this one, folks. This isn't going to happen.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http:/
Greg Ewing <[EMAIL PROTECTED]> wrote:
>> for i,(x,y) in enumerate(izip(iter1, iter2)):
>> ...
>>
>> must be translated to:
>>
>> for (i,x in enumerate(iter1), y in iter2):
>
> Maybe the functionality of enumerate() could be
> incorporated into the syntax as well.
>
>for (i in *, x in i
> > And what about the ambiguity in parsing:
> >
> > for (x in iter1,y,z in iter2):
> > ...
>
> It would probably be necessary to require some
> parens there, e.g.
>
>for (x in iter1, (y,z) in iter2):
> ...
I've also a proposition, but I don't know if it can't be done since I
don't
[EMAIL PROTECTED] wrote on
30/03/2006 13:01:25:
> [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote on
> > 30/03/2006 11:38:30:
> >
> >> Jack Diederich wrote:
> >>
> >> > Classes have a unique property in that they are the easiest way to
> > make
> >> > little namespaces in python.
> >>
>
On 3/29/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
Greg Ewing wrote:> On 3/29/06, Adam DePrince <[EMAIL PROTECTED]> wrote:>> rs.execute( "select upc, description, price from my_table" )
> data = "" 'price','upc')> print type( data )>> >> Seems to me it would be a better idea for the DB>
Giovanni Bajo wrote:
> And what about the ambiguity in parsing:
>
> for (x in iter1,y,z in iter2):
> ...
It would probably be necessary to require some
parens there, e.g.
for (x in iter1, (y,z) in iter2):
...
--
Greg
___
Python-3000 mail
Robert Brewer wrote:
> Nick Coghlan wrote:
>> There are three big use cases:
>>
>>dict.keys
>>dict.values
>>dict.items
>>
>> Currently these all return lists, which may be expensive in
>> terms of copying. They all have iter* variants which while
>> memory efficient, are far less conve
Greg Ewing wrote:
> Brett Cannon wrote:
>> Without a direct reason in terms of the language needing a
>> standardization of an interface, perhaps we just don't need
> > views.
>
> On the contrary, views are a very useful idea, *as a
> design pattern*. What we *don't* need in Python, as far
> as I
Adam DePrince wrote:
> On Wed, 2006-03-29 at 21:15 +1000, Nick Coghlan wrote:
>> Paul Moore wrote:
>>> On 3/29/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
Without a direct reason in terms of the language needing a
standardization of an interface, perhaps we just don't need views. If
38 matches
Mail list logo
