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
> people want their iterator to have a __len__ method, then fine, they
> can add it without breaking anything, ju
on 29.03.2006 09:11 Brett Cannon said the following:
> On 3/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Adam DePrince wrote:
>>
[snip ... massive over-design.]
>>
>> Python is NOT Java!
>>
>
> What I was taking away from this whole view discussion was basically
> just coming up with a simple,
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
>> people want their iterator to have a __len__ method, then fine, they
>> can add it witho
On Wed, 2006-03-29 at 14:53 +1200, Greg Ewing wrote:
> Adam DePrince wrote:
>
> >The following interface names are abbreviations for the following
> >permutations of the above.
> >
> >* Collection View( SetView + Multiview )
> >* ListView: (SetView + MultiView + OrderedView)
> >
> 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 view? The *only* time we want to call a
method to get a view is when there is not one, single, completing
definition of the obj
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
> >> people want their itera
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 view? The *only* time we want to call a
> method to get a view is
On 3/29/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
> There is more than that. Everybody who accesses a database has to jump
> and down to extract their fields. Wouldn't it be nice if you could say
> to your result set from a database:
>
> >>> rs.execute( "select upc, description, price from my_
Brett Cannon wrote:
> Basically a simple
> set interface where we could have a __container__/__view__/__set__
> whatever method to call to get a view of the data structure.
> Basically a read-only (with a possible delete possibility) mapping
> interface.
If there's an obvious default meaning for
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, depending on the details of the base object.
Inheritance in Python is *entir
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 the whole thing
alive and using up memory.
While having a separate w
Paul Moore wrote:
> I still think my earlier analysis is important - for loops have no
> direct access to the iterator/view/whatever, and inline code has
> access to the original object. So the *only* relevant use cases are
> those where people are writing functions which take "extended
> iterator
On 3/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
>
> > Basically a simple
> > set interface where we could have a __container__/__view__/__set__
> > whatever method to call to get a view of the data structure.
> > Basically a read-only (with a possible delete possibility) map
Adam DePrince wrote:
> dicta.keys() - dictb.keys()
>
> Because each supports the SetView interface, we need only provide a
> single generic SetView.difference operator and move on.
I can see some use for inheritance there. But keep in
mind that there is no multiple inheritance at the C
level, so
Brett Cannon wrote:
> Four? In terms of "atomic" data views, there are keys and values.
> Items could be counted, but that is just a way to pair the different
> types of data in a dict together so I don't know if I would count it
> as a view, let alone whether it would be useful outside of an
>
On 3/29/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
> >>>rs.execute( "select upc, description, price from my_table" )
> >>>data = rs.fetch().fieldby( 'price','upc')
> >>>print type( data )
>
>
Seems to me it would be a better idea for the DB
module to return tuple-with-attributes objects for
th
On Mar 29, 2006, at 6:03 PM, Greg Ewing wrote:
> On 3/29/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
>
> rs.execute( "select upc, description, price from my_table" )
> data = rs.fetch().fieldby( 'price','upc')
> print type( data )
>>
>>
>
> Seems to me it would be a better idea for
Greg Ewing wrote:
> On 3/29/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
>
> rs.execute( "select upc, description, price from my_table" )
> data = rs.fetch().fieldby( 'price','upc')
> print type( data )
>>
>
> Seems to me it would be a better idea for the DB
> module to return tuple-
Ian Bicking wrote:
> Which is off-topic here, except to say that a view on the tuple would be
> useful in a way that returning a fancy tuple would not, because it could
> wrap any DB-API-compliant result set.
A wrapper like that could be built quite generically.
Also, better to wrap the whole s
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 3/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> I like your strawman: if incompatibilities or synergy
>> don't require it to go into Py3k, let's propose it for 2.x.
>
> Yeah, I think this makes a lot of sens
20 matches
Mail list logo
