Opened a ticket for this and attached a patch. (experimental)
http://bugs.python.org/issue5736
On Fri, Apr 10, 2009 at 8:39 AM, "Martin v. Löwis" wrote:
I assumed there were some decisions behind this, rather than it's just
not implemented yet.
>>> I believe this assumption is wrong - i
>>> I assumed there were some decisions behind this, rather than it's just
>>> not implemented yet.
>> I believe this assumption is wrong - it's really that no code has been
>> contributed to do that.
>
> But doesn't the issue at http://bugs.python.org/issue662923 imply that
> there *was* suitable
"Martin v. Löwis" wrote:
>> I assumed there were some decisions behind this, rather than it's just
>> not implemented yet.
>
> I believe this assumption is wrong - it's really that no code has been
> contributed to do that.
But doesn't the issue at http://bugs.python.org/issue662923 imply that
the
> I assumed there were some decisions behind this, rather than it's just
> not implemented yet.
I believe this assumption is wrong - it's really that no code has been
contributed to do that.
For gdbm, you can also use the firstkey/nextkey methods.
Regards,
Martin
--
http://mail.python.org/mailma
Joshua> Why not
Joshua> for key in d.keys():
Joshua> print key
Joshua> That worked for me.
Time & space. One motivation for using dbm files is to write large (huge,
in fact) mappings to disk. Simply reconstituting the entire set of keys may
consume a lot of time (they must
keys() returns a list and my question was not about "how to" but more
like "why"...
I assumed there were some decisions behind this, rather than it's just
not implemented yet.
Best,
On Friday, April 10, 2009, Joshua Kugler wrote:
> Akira Kitada wrote:
>
>> The loop has to be:
>> """
> k = d.f
Akira Kitada wrote:
> The loop has to be:
> """
k = d.firstkey()
while k != None:
> ...print k
> ...k = d.nextkey(k)
> key2
> key1
> """
Why not
for key in d.keys():
print key
That worked for me.
j
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
I was wondering why *dbm modules in Python do not give us an iterable interface?
Take a look at an example below
"""
# Python 2.6
>>> import gdbm
>>> d = gdbm.open("spam.db", "n")
>>> d["key1"] = "ham"
>>> d["key2"] = "spam"
>>>
>>> for k in d:
... print k
...
Traceback (most recent call
Fredrik Lundh wrote:
> "Bryan" wrote:
>
>>> and how do you make sure that everything subclasses this base class ?
>> in this hypothetical case, i was assuming len() would be put in object and
>> every
>> class subclasses object implicitly or explicitly (ie, new style classes
>> only).
>> if it w
> >>> isinstance(1, object)
> True
>
> What's 1 . len() ?
That's easy!
since 1 is actually syntactic sugar for set([set([])]), clearly 1.len()
== 1.
;-)
v.
(actually, make that frozenset([frozenset([])])...)
--
http://mail.python.org/mailman/listinfo/python-list
Bryan wrote:
> Fredrik Lundh wrote:
>
>>Bryan wrote:
>>
>>
>>>could you get the same result by putting these methods in base
>>
>> > class object that everything subclasses?
>>
>>and how do you make sure that everything subclasses this base class ?
>>
>>
>>
>
> in this hypothetical case, i was as
"Bryan" wrote:
>> and how do you make sure that everything subclasses this base class ?
>
> in this hypothetical case, i was assuming len() would be put in object and
> every
> class subclasses object implicitly or explicitly (ie, new style classes only).
> if it was done that way, would len(obj)
Fredrik Lundh wrote:
> Bryan wrote:
>
>> could you get the same result by putting these methods in base
> > class object that everything subclasses?
>
> and how do you make sure that everything subclasses this base class ?
>
>
>
in this hypothetical case, i was assuming len() would be put in
Terry Reedy wrote:
> "OKB (not okblacke)" <[EMAIL PROTECTED]> wrote in message
[...]
>
> The underlying answer to the original question is that while Pyt;hon is
> object-based, it is not strictly OO but is intentionally multiparadigmatic
> and will remain so. For instance, no one will be force
Paul Rubin wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
>> If len() were a method of string objects, you could try using the
>> unbound method and writing this as::
>>
>> >>> sorted(['aaa', 'bb', 'c'], key=str.len)
>> ['c', 'bb', 'aaa']
>>
>> But then your code would break on lists
Bryan wrote:
> Steven Bethard wrote:
>
>> The advantage of a functional form over a method shows up when you
>> write a function that works on a variety of different types. Below are
>> implementations of "list()", "sorted()" and "join()" that work on any
>> iterable and only need to be defined
Bryan wrote:
> could you get the same result by putting these methods in base
> class object that everything subclasses?
and how do you make sure that everything subclasses this base class ?
--
http://mail.python.org/mailman/listinfo/python-list
Steven Bethard a écrit :
> The advantage of a functional form over a method shows up when you write
> a function that works on a variety of different types. Below are
> implementations of "list()", "sorted()" and "join()" that work on any
> iterable and only need to be defined once::
>
> [... skip
Piet van Oostrum wrote:
>>Bruno Desthuilliers <[EMAIL PROTECTED]> (BD) wrote:
>
>
>>BD> Actually, and AFAIK, len(obj) = lambda obj : obj.__len__().
>
>
> You mean: len = lambda obj : obj.__len__().
yes, of course - not enough caffein, I guess...
Thanks
--
bruno desthuilliers
python -c "p
> Bruno Desthuilliers <[EMAIL PROTECTED]> (BD) wrote:
>BD> Actually, and AFAIK, len(obj) = lambda obj : obj.__len__().
You mean: len = lambda obj : obj.__len__().
--
Piet van Oostrum <[EMAIL PROTECTED]>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: [EMAIL PROTECTED]
--
>- why is len() not a member function of strings? Instead one says len(w).
Coming from a Java background, I also thought this a weird setup.
However IMHO there is another good reason to have len(obj) as we do in
Python: it helps to enforce some sort of uniformity across code.
If I want to fi
"guthrie" wrote:
> But if (as I proposed..!) the user interface is better if presented as a
> method. one could porovide convenience methods which would then
> interface to these underlying library functions; yes?
but if it isn't? and why this obsession with superficial syntax details?
there's
guthrie wrote:
> Good point, thanks.
>
> But if (as I proposed..!) the user interface is better if presented as a
> method. one could porovide convenience methods which would then
> interface to these underlying library functions; yes?
>
Actually, and AFAIK, len(obj) = lambda obj : obj.__len__().
Steven Bethard <[EMAIL PROTECTED]> writes:
> If len() were a method of string objects, you could try using the
> unbound method and writing this as::
>
> >>> sorted(['aaa', 'bb', 'c'], key=str.len)
> ['c', 'bb', 'aaa']
>
> But then your code would break on lists that weren't strings.
s
Steven Bethard wrote:
> Terry Reedy wrote:
>
>> "Gregory Guthrie" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>
>>> - why is len() not a member function of strings? Instead one says
>>> len(w).
>>
>>
>> Consider
>>
> map(len, ('abc', (1,2,3), [1,2], {1:2}))
>>
>> [3, 3, 2
Alex Martelli wrote:
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>...
>
>>>This would allow things like:
>>>key = '',join( list(word.lower().strip()).sort() )
>>
>>key = ''.join(list(sorted(word.lower().strip()))
>
>
> No need to make yet another list here (also, I think eac
Steven Bethard wrote:
> The advantage of a functional form over a method shows up when you write
> a function that works on a variety of different types. Below are
> implementations of "list()", "sorted()" and "join()" that work on any
> iterable and only need to be defined once::
>
> def
Good point, thanks.
But if (as I proposed..!) the user interface is better if presented as a
method. one could porovide convenience methods which would then
interface to these underlying library functions; yes?
So the main datatype classes could support such a method style, and just
layer on t
Many thanks; great information.
Best,
Gregory
Steven Bethard wrote:
> guthrie wrote:
>
>> Steven Bethard wrote:
>>
>>> Why would ``x.len()`` be any more convenient than ``len(x)``? Your
>>> preference here seems pretty arbitrary.
>>
>> -- Perhaps;
>> but having all standard operations as a m
Terry Reedy wrote:
> "Gregory Guthrie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> - why is len() not a member function of strings? Instead one says
>> len(w).
>
> Consider
map(len, ('abc', (1,2,3), [1,2], {1:2}))
> [3, 3, 2, 1]
>
> Now try to rewrite this using meth
guthrie wrote:
> Steven Bethard wrote:
>> Why would ``x.len()`` be any more convenient than ``len(x)``? Your
>> preference here seems pretty arbitrary.
> -- Perhaps;
> but having all standard operations as a method seems more regular (to
> me), and allows a simple chained operation format of a se
"OKB (not okblacke)" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>
>> Consider
> map(len, ('abc', (1,2,3), [1,2], {1:2}))
>> [3, 3, 2, 1]
>>
>> Now try to rewrite this using methods (member functions).
>
> [a.len() for a in ('abc', (1,2,3), [1,2], {1:2})]
Steven Bethard wrote:
> Gregory Guthrie wrote:
>
>> For example,
>>- why is len() not a member function of strings? Instead one says
>> len(w).
>
> Why would ``x.len()`` be any more convenient than ``len(x)``? Your
> preference here seems pretty arbitrary.
-- Perhaps;
but having all standa
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
...
> > This would allow things like:
> > key = '',join( list(word.lower().strip()).sort() )
>
> key = ''.join(list(sorted(word.lower().strip()))
No need to make yet another list here (also, I think each of you omitted
a needed closed-
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Length is an obvious property of any one-dimensional non-scalar, not just
> strings. As such, it makes sense to have a length function that takes an
> argument. As a design decision, it could go either way, but early
> Python wasn't fully object-oriente
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> >> Now try to rewrite this using methods (member functions).
> > [a.len() for a in ('abc', (1,2,3), [1,2], {1:2})]
>
> Did you actually try that?
No of course not. It's in a hypothetical python where .len() is a
class operation instead of a global fu
Steven D'Aprano wrote:
> On Sun, 09 Jul 2006 22:45:53 +, OKB (not okblacke) wrote:
>
>> Terry Reedy wrote:
>>
>>> Consider
>> map(len, ('abc', (1,2,3), [1,2], {1:2}))
>>> [3, 3, 2, 1]
>>>
>>> Now try to rewrite this using methods (member functions).
>> [a.len() for a in ('abc', (1,2,3), [
On Sun, 09 Jul 2006 22:45:53 +, OKB (not okblacke) wrote:
> Terry Reedy wrote:
>
>> Consider
> map(len, ('abc', (1,2,3), [1,2], {1:2}))
>> [3, 3, 2, 1]
>>
>> Now try to rewrite this using methods (member functions).
>
> [a.len() for a in ('abc', (1,2,3), [1,2], {1:2})]
Did you actually
On Sun, 09 Jul 2006 12:19:13 -0500, Gregory Guthrie wrote:
> I am comparing Python to a few other scripting languages, and used a simple
> anagrams program as a sample.
>
> I was surprised ast a few python features that did not work as I would
> expect/wish; which caused less compact/expressive
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> Consider
> >>> map(len, ('abc', (1,2,3), [1,2], {1:2}))
> [3, 3, 2, 1]
>
> Now try to rewrite this using methods (member functions).
[x.len() for x in ('abc', (1,2,3), [1,2], {1:2})]
> > - Why doesn't sort() return a value?
>
> Because it is an in-pl
Terry Reedy wrote:
> Consider
map(len, ('abc', (1,2,3), [1,2], {1:2}))
> [3, 3, 2, 1]
>
> Now try to rewrite this using methods (member functions).
[a.len() for a in ('abc', (1,2,3), [1,2], {1:2})]
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, inste
"Gregory Guthrie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> - why is len() not a member function of strings? Instead one says
> len(w).
Consider
>>> map(len, ('abc', (1,2,3), [1,2], {1:2}))
[3, 3, 2, 1]
Now try to rewrite this using methods (member functions).
> - Why d
Gregory Guthrie wrote:
> I am comparing Python to a few other scripting languages, and used a simple
> anagrams program as a sample.
>
> I was surprised ast a few python features that did not work as I would
> expect/wish; which caused less compact/expressive program styles that I
> wanted - rever
Gregory Guthrie a écrit :
> I am comparing Python to a few other scripting languages, and used a simple
> anagrams program as a sample.
>
> I was surprised ast a few python features that did not work as I would
> expect/wish; which caused less compact/expressive program styles that I
> wanted -
Gregory Guthrie wrote:
> For example,
>- why is len() not a member function of strings? Instead one says len(w).
Why would ``x.len()`` be any more convenient than ``len(x)``? Your
preference here seems pretty arbitrary.
> - Why doesn't sort() return a value?
>
> This would allow thing
I am comparing Python to a few other scripting languages, and used a simple
anagrams program as a sample.
I was surprised ast a few python features that did not work as I would
expect/wish; which caused less compact/expressive program styles that I
wanted - reverting to a FORTRAN like series of
Lawrence D'Oliveiro wrote:
> In article <[EMAIL PROTECTED]>,
> "Carl Banks" <[EMAIL PROTECTED]> wrote:
>
>
>>bruno at modulix wrote:
>>
>>>[EMAIL PROTECTED] wrote:
>>>
I was wondering, why you always have to remember to call bases'
constructors
>>>
>>>
>>>s/constructors/__init__/
>>>
>>>
Lawrence D'Oliveiro wrote:
> In article <[EMAIL PROTECTED]>,
> "Carl Banks" <[EMAIL PROTECTED]> wrote:
>
> >bruno at modulix wrote:
> >> [EMAIL PROTECTED] wrote:
> >> > I was wondering, why you always have to remember to call bases'
> >> > constructors
> >>
> >>
> >> s/constructors/__init__/
> >
Lawrence D'Oliveiro wrote:
>>In other words, the object is constructed in Python before any
>>__init__ is called, but in C++ it isn't constructed until after all
>>the base class constructors have returned.
>
> But if "construction" is what a constructor does, then you're wrong.
>
I may be wrong
In article <[EMAIL PROTECTED]>,
"Carl Banks" <[EMAIL PROTECTED]> wrote:
>bruno at modulix wrote:
>> [EMAIL PROTECTED] wrote:
>> > I was wondering, why you always have to remember to call bases'
>> > constructors
>>
>>
>> s/constructors/__init__/
>>
>> the __init__() method is *not* the construct
In article <[EMAIL PROTECTED]>,
Duncan Booth <[EMAIL PROTECTED]> wrote:
>Carl Banks wrote:
>
>> You know, Python's __init__ has almost the same semantics as C++
>> constructors (they both initialize something that's already been
>> allocated in memory, and neither can return a substitute object).
Brian van den Broek wrote:
> Bruno Desthuilliers said unto the world upon 25/04/06 06:52 PM:
>
>> Duncan Booth a écrit :
>>
(snip)
>>> Apart from the fact that you can delete the method 'dothis' from both
>>> classes with no effect on the code?
>>
>> Mmmm... Oh, I see. Agreed, this is not a very g
Bruno Desthuilliers said unto the world upon 25/04/06 06:52 PM:
> Duncan Booth a écrit :
>
>>bruno at modulix wrote:
>>
>>
>>
>>>class Base(object):
>>> def __init__(self, arg1):
>>> self.attr1 = arg1
>>> self.dothis()
>>>
>>> def dothis(self):
>>> return self.attr1
>>>
>>>class Derived(Base
Duncan Booth wrote:
> bruno at modulix wrote:
>
>
>>It's *already* split : __new__ construct the object, __init__
>>initialize it.
>>
>>>That's why I would go for the 2-phase construction:
>>
>>But that's already what you have.
>
> Very good point.
>
>
>>>after the first phase
>>>you have an
bruno at modulix wrote:
> It's *already* split : __new__ construct the object, __init__
> initialize it.
>
>> That's why I would go for the 2-phase construction:
>
> But that's already what you have.
Very good point.
>> after the first phase
>> you have an object which is fully initialised,
Duncan Booth wrote:
> Alex Martelli wrote:
>
> >> What I think I'm trying to get at is that I believe that most
> >> situations where someone actually tries to do something in the base
> >> initialiser which requires calling a virtual method are probably also
> >> cases where the initialiser is do
Duncan Booth wrote:
> Alex Martelli wrote:
>
>
>>>What I think I'm trying to get at is that I believe that most
>>>situations where someone actually tries to do something in the base
>>>initialiser which requires calling a virtual method are probably also
>>>cases where the initialiser is doing t
Alex Martelli wrote:
>> What I think I'm trying to get at is that I believe that most
>> situations where someone actually tries to do something in the base
>> initialiser which requires calling a virtual method are probably also
>> cases where the initialiser is doing too much: i.e. separating th
Duncan Booth <[EMAIL PROTECTED]> wrote:
...
> Actually, this is quite an interesting example becaue it wouldn't work in
> C++: if you tried the same trick the call to dothis from the base
> constructor (even assuming it is virtual) would actually call Base.dothis.
Yep.
> I think you have demo
Duncan Booth a écrit :
> bruno at modulix wrote:
>
>
>>class Base(object):
>> def __init__(self, arg1):
>>self.attr1 = arg1
>>self.dothis()
>>
>> def dothis(self):
>>return self.attr1
>>
>>class Derived(Base):
>> def __init__(self, arg1, arg2=0):
>>self.attr2 = arg2
>>Base.
bruno at modulix wrote:
> class Base(object):
> def __init__(self, arg1):
> self.attr1 = arg1
> self.dothis()
>
> def dothis(self):
> return self.attr1
>
> class Derived(Base):
> def __init__(self, arg1, arg2=0):
> self.attr2 = arg2
> Base.__init__(self, arg1)
>
> de
Duncan Booth wrote:
> bruno at modulix wrote:
>
>
>>Duncan Booth wrote:
>>(snip)
>>
>>>Usually though, if a subclass doesn't immediately call the base class
>>>constructors as the first thing it does in __init__ it indicates poor
>>>code and should be refactored.
>>
>>Not necessarily. It's a comm
Duncan Booth wrote:
> In other words, the object is constructed in Python before any __init__ is
> called, but in C++ it isn't constructed until after all the base class
> constructors have returned.
That's true. Good point.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Carl Banks wrote:
> You know, Python's __init__ has almost the same semantics as C++
> constructors (they both initialize something that's already been
> allocated in memory, and neither can return a substitute object).
There is a significant difference: imagine B is a base type and C a
subclas
bruno at modulix wrote:
> [EMAIL PROTECTED] wrote:
> > I was wondering, why you always have to remember to call bases'
> > constructors
>
>
> s/constructors/__init__/
>
> the __init__() method is *not* the constructor. Object's instanciation
> is a two-stage process: __new__() is called first, t
bruno at modulix wrote:
> Duncan Booth wrote:
> (snip)
>> Usually though, if a subclass doesn't immediately call the base class
>> constructors as the first thing it does in __init__ it indicates poor
>> code and should be refactored.
>
> Not necessarily. It's a common case to have some computati
[EMAIL PROTECTED] wrote:
> Heiko Wundram wrote:
> > Because sometimes you don't want to call the base classes constructors?
> Sounds strange to me at the moment, but I'll try to adjust to this
> thought.
In Java and C++, classes have private members that can only be accessed
by the class itself (a
[EMAIL PROTECTED] wrote:
> I was wondering, why you always have to remember to call bases'
> constructors
s/constructors/__init__/
the __init__() method is *not* the constructor. Object's instanciation
is a two-stage process: __new__() is called first, then __init__().
--
bruno desthuillier
Duncan Booth wrote:
(snip)
> Usually though, if a subclass doesn't immediately call the base class
> constructors as the first thing it does in __init__ it indicates poor code
> and should be refactored.
Not necessarily. It's a common case to have some computations to do/some
attributes to set i
[EMAIL PROTECTED] wrote:
> Heiko Wundram wrote:
>> Because sometimes you don't want to call the base classes constructors?
> Sounds strange to me at the moment, but I'll try to adjust to this
> thought.
It makes sense in more static languages such as C++. The base class is
initialised by the con
> Well, I can imagine it's done to make sure that the base(s) are
> properly constructed. Sound s sensible to me.
It often is - there are popular examples in python where missing a
constructor will cause a program to fail spectacular. But is it _always_ a
sensible thing to do? No. If you only want
[EMAIL PROTECTED]:
>I think I'll need some shift in thinking after C++.
+1 qotw
--
René Pijlman
--
http://mail.python.org/mailman/listinfo/python-list
Heiko Wundram wrote:
> Because sometimes you don't want to call the base classes constructors?
Sounds strange to me at the moment, but I'll try to adjust to this
thought.
> Python zen says: "Better explicit than implicit," and in this case it hits
> the nail on the head. Better to see right away
Diez B. Roggisch wrote:
> I have another question for you: why does JAVA enforce that a constructor of
> a base-class must be called prior to everything else in the derived class's
> constructor?
Well, I can imagine it's done to make sure that the base(s) are
properly constructed. Sound s sensible
[EMAIL PROTECTED] wrote:
> I was wondering, why you always have to remember to call bases'
> constructors explicitly from the derived class constructor? Why hasn't
> this been enforced by the language?
I have another question for you: why does JAVA enforce that a constructor of
a base-class must
Am Dienstag 25 April 2006 12:34 schrieb [EMAIL PROTECTED]:
> I was wondering, why you always have to remember to call bases'
> constructors explicitly from the derived class constructor? Why hasn't
> this been enforced by the language?
Because sometimes you don't want to call the base classes cons
[EMAIL PROTECTED]:
>I was wondering, why you always have to remember to call bases'
>constructors explicitly from the derived class constructor? Why hasn't
>this been enforced by the language?
Probably because the language doesn't know whether the subclass wants to
override its base class's constr
I was wondering, why you always have to remember to call bases'
constructors explicitly from the derived class constructor? Why hasn't
this been enforced by the language?
--
http://mail.python.org/mailman/listinfo/python-list
78 matches
Mail list logo
