mk a écrit :
Bruno Desthuilliers wrote:
Thanks, that worked. But in order to make it work I had to get rid of
'self' in print_internal_date signature
Indeed. Using it that way, the print_internal_date will not be wrapped
in a method object.
Hold on! How does Python know what to wrap and what
mk wrote:
> Bruno Desthuilliers wrote:
>>> Thanks, that worked. But in order to make it work I had to get rid of
>>> 'self' in print_internal_date signature
>>
>> Indeed. Using it that way, the print_internal_date will not be wrapped
>> in a method object.
>
> Hold on! How does Python know what to
Bruno Desthuilliers wrote:
Thanks, that worked. But in order to make it work I had to get rid of
'self' in print_internal_date signature
Indeed. Using it that way, the print_internal_date will not be wrapped
in a method object.
Hold on! How does Python know what to wrap and what not to wrap,
Ben Finney a écrit :
Bruno Desthuilliers writes:
perhaps a lighter introductory text could be helpful. So guys, if you
think a revised version of my post would be of interest, I'll take you
on words: provide the hosting, I'll provide the content !-)
Here, let me work my hosting magic: http:/
Bruno Desthuilliers writes:
> perhaps a lighter introductory text could be helpful. So guys, if you
> think a revised version of my post would be of interest, I'll take you
> on words: provide the hosting, I'll provide the content !-)
Here, let me work my hosting magic: http://wiki.python.org/>.
Stephen Hansen wrote:
Or just leave it as a top level function where it was perfectly happy to
live :)
Yes. This is probably the sanest solution anyway, because probably
having many such functions to use, packing them into smth like
package.utils anyway is a good idea. I'm trying mainly to le
Mark Lawrence a écrit :
Ben Finney wrote:
Bruno Desthuilliers writes:
Mmmm... Let's try to explain the whole damn thing. It's really (and
IMHO beautifully) simple once you get it, but I agree it's a bit
peculiar when compared to most mainstream OO languages.
[…]
Bruno, that's the first time
Ben Finney wrote:
Bruno Desthuilliers writes:
Mmmm... Let's try to explain the whole damn thing. It's really (and
IMHO beautifully) simple once you get it, but I agree it's a bit
peculiar when compared to most mainstream OO languages.
[…]
Bruno, that's the first time I've understood the desc
Bruno Desthuilliers writes:
> Mmmm... Let's try to explain the whole damn thing. It's really (and
> IMHO beautifully) simple once you get it, but I agree it's a bit
> peculiar when compared to most mainstream OO languages.
[…]
Bruno, that's the first time I've understood the descriptor protocol,
John Posner a écrit :
> On 2/17/2010 2:44 PM, Bruno Desthuilliers wrote:
>>
> Very nice writeup, Bruno -- thanks!
>
>
>>
>>
>> def __call__(self, *args, **kw):
>> # XXX : all sanity checks removed for readability
>> if self.im_self:
>> args = (self.im_func,
Bruno Desthuilliers writes:
[...]
> class Foo(object):
> def bar(self):
> return "baaz"
>
> print Foo.__dict__.keys()
> print type(Foo.__dict__['bar'])
>
>
> So, why is it that type(Foo.bar) != type(Foo.__dict__['bar']) ? The
> answer is : attribute lookup rules and the descriptor pro
On 2/17/2010 2:44 PM, Bruno Desthuilliers wrote:
Mmmm... Let's try to explain the whole damn thing. It's really (and IMHO
beautifully) simple once you get it, but I agree it's a bit peculiar
when compared to most mainstream OO languages.
Very nice writeup, Bruno -- thanks!
class method(ob
mk a écrit :
> Stephen Hansen wrote:
>
>> You don't have to (and can't) refer to the class within the body.
>> Class statements are sort of... odd. They are code which is directly
>> executed, and the results are then passed into a
>> metaclass/type/whatever and a class object is created. While wi
mk wrote:
Stephen Hansen wrote:
You don't have to (and can't) refer to the class within the body.
Class statements are sort of... odd. They are code which is directly
executed, and the results are then passed into a
metaclass/type/whatever and a class object is created. While within
the clas
On Wed, Feb 17, 2010 at 10:38 AM, mk wrote:
> Thanks, that worked. But in order to make it work I had to get rid of
> 'self' in print_internal_date signature, bc all other functions in tagdata
> have only a single argument:
>
Right, I should have caught that.
You can make print_internal_date a
Stephen Hansen wrote:
You don't have to (and can't) refer to the class within the body. Class
statements are sort of... odd. They are code which is directly executed,
and the results are then passed into a metaclass/type/whatever and a
class object is created. While within the class body, the
On Wed, Feb 17, 2010 at 9:38 AM, mk wrote:
> It works. But if I'd like to def print_internal_date in PYFileInfo body
> like so:
>
> class PYFileInfo(FileInfo):
>'python file properties'
>
>def print_internal_date(self, filename):
>f = open(filename + 'c', "rb")
>data = f.r
Hello everyone,
OK so I have this:
def print_internal_date(filename):
f = open(filename + 'c', "rb")
data = f.read(8)
mtime = struct.unpack("It works. But if I'd like to def print_internal_date in PYFileInfo body
like so:
class PYFileInfo(FileInfo):
'python file properties'
18 matches
Mail list logo
