At first I was going to post the following:
<!-- beginning of my original post -->
I just discovered the inspect module, which contains the isfunction and
ismethod functions. For some reason, I used to be under the impression
that Python methods are no different from Python functions. Naturally,
I wondered why both of these needed to exist (I also later discovered
the isroutine function). So I started to experiment at prompt. Here's
what I did:
>>from inspect import *
def dan(): pass
....
>>ismethod(dan)
False
>>isfunction(dan)
True
>>class Foo:
.... def meth(self): pass
....
>>m = Foo.meth
m
<unbound method Foo.meth>
>>ismethod(m)
True
>>Foo.func = dan # <-- Appearantly, something magical happens here, because...
Foo.func
<unbound method Foo.dan>
>>f = Foo.func
f is dan # <-- things begins to look suprising here.
False
>>ismethod(f)
True
Imagine my surprise. Why would Python do this?
<!-- end of my original post, with ending censored -->
but then I tried this:
>>res = Foo.__dict__['func']
res is dan
True
And it all started to make sense. The surprising thing turned out to be
not so surprising: When the expression Foo.func gets evaluated, we get
a method which is just a wrapper around dan. Therefore, f is not dan!
This is still a little bit of magic, which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case, why not use some more dot-magic to implement
privates? Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
BTW, I am aware of Python's name mangling feature. 36  1835 
I guess the python devs are not interested in implementing something
that would require new syntax and does not give something entirely new
to the language.
The good thing about python is, that the devs are only implementing
ideas that are very cool. There are a lot of cool (!= very cool) ideas
in rejected peps - but they were never implemented for good reasons.
If you *really* need privates, just use the naming convention.
danielx wrote:
This is still a little bit of magic, which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case, why not use some more dot-magic to implement
privates? Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
You can do this now, kind of:
>>class Foo(object):
.... x = property()
.... def doStuffWithX(self):
.... self.__dict__['x'] = 123
.... print self.__dict__['x']
....
>>bar = Foo()
bar.doStuffWithX()
123
>>bar.x
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: unreadable attribute
If you're proposing that self.x and bar.x should give different results,
then that's quite a bit more magic than property() and methods use. They
both use the descriptor API; for more information on that, read
<http://python.org/download/releases/2.2.3/descrintro/>.
danielx wrote:
>>>Foo.func = dan # <-- Appearantly, something magical happens here,
because...
>>>Foo.func
<unbound method Foo.dan>
>>>f = Foo.func
f is dan # <-- things begins to look suprising here.
False
>>>ismethod(f)
True
Imagine my surprise. Why would Python do this?
Nothing magical happens at the point you said. The assignment is just an
assignment and you saw that the function was stored unchanged when you
looked in the class's dictionary.
The magic happens when you access a member of a class or an instance. If
the value is a descriptor then its __get__ method is called. Roughly
speaking, Foo.func is equivalent to:
>>Foo.__dict__['func'].__get__(None, Foo)
<unbound method Foo.dan>
Python does this so that it can support other descriptor types such as
property, classmethod, staticmethod.
You can see this happening if you define your own descriptor:
>>class MyDesc(object):
def __get__(self, *args):
print "__get__ called", args
return None
>>d = MyDesc()
Foo.oops = d
Foo.oops
__get__ called (None, <class __main__.Foo at 0x00B3F930>) http://docs.python.org/ref/descriptor-invocation.html has a description of
this. Although it claims "Note that descriptors are only invoked for new
style objects or classes (ones that subclass object() or type())." the
descriptor mechanism is partially implemented for old style classes.
Several aspects of descriptors don't work properly though in old-style
classes which is one reason why you should always use new-style classes.
Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
You could implement that using a data descriptor, but if you are going to
prevent access to your private variables using the dot operator, then your
code is going to look pretty silly with a lot of references to
self.__dict__['theprivate'] which doesn't gain anything in readability over
self.__theprivate.
danielx wrote:
At first I was going to post the following:
<!-- beginning of my original post -->
(snip)
>
<!-- end of my original post, with ending censored -->
but then I tried this:
>>>>res = Foo.__dict__['func']
res is dan
True
And it all started to make sense. The surprising thing turned out to be
not so surprising: When the expression Foo.func gets evaluated, we get
a method which is just a wrapper around dan. Therefore, f is not dan!
This is still a little bit of magic,
FWIW, the function class implements the descriptor protocol... Here's
the "magic".
which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case,
"unexpected" ? Did you ever wondered how the instance or class was
passed as first arg when doing method calls ?
why not use some more dot-magic to implement
privates?
What for ? What makes you think we need language-inforced access
restriction ?
(snip)
BTW, I am aware of Python's name mangling feature.
Name mangling is mainly here to protect from accidental overridding. The
convention for implementation attributes is single-leading-underscore.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Bruno Desthuilliers wrote:
danielx wrote:
At first I was going to post the following:
<!-- beginning of my original post -->
(snip)
<!-- end of my original post, with ending censored -->
but then I tried this:
>>>res = Foo.__dict__['func']
res is dan
True
And it all started to make sense. The surprising thing turned out to be
not so surprising: When the expression Foo.func gets evaluated, we get
a method which is just a wrapper around dan. Therefore, f is not dan!
This is still a little bit of magic,
FWIW, the function class implements the descriptor protocol... Here's
the "magic".
which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case,
"unexpected" ? Did you ever wondered how the instance or class was
passed as first arg when doing method calls ?
Not knowing what's going on during method calls is exactly what
motivated me to post.
>
why not use some more dot-magic to implement
privates?
What for ? What makes you think we need language-inforced access
restriction ?
I knew someone would bring this up. The motivation would not be to
provide restriction, but to help maintain clean api's. If you intended
for users to use only a subset of the methods in your class, why not
help them learn your api by presenting the stuff they can use not along
side the stuff they should not?
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python. This is exactly what it's there for. If nothing is
hidden, a user could be easily mislead to believe he can use a method
when he really shouldn't.
>
(snip)
BTW, I am aware of Python's name mangling feature.
Name mangling is mainly here to protect from accidental overridding. The
convention for implementation attributes is single-leading-underscore.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Leif K-Brooks wrote:
danielx wrote:
This is still a little bit of magic, which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case, why not use some more dot-magic to implement
privates? Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
You can do this now, kind of:
>>class Foo(object):
... x = property()
... def doStuffWithX(self):
... self.__dict__['x'] = 123
... print self.__dict__['x']
...
>>bar = Foo()
>>bar.doStuffWithX()
123
>>bar.x
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: unreadable attribute
If you're proposing that self.x and bar.x should give different results,
then that's quite a bit more magic than property() and methods use. They
Yes, I had not considered that very carefully...
both use the descriptor API; for more information on that, read
<http://python.org/download/releases/2.2.3/descrintro/>.
Let me finish reading that before I get back to your point.
Duncan Booth wrote:
danielx wrote:
>>Foo.func = dan # <-- Appearantly, something magical happens here,
because...
>>Foo.func
<unbound method Foo.dan>
>>f = Foo.func
f is dan # <-- things begins to look suprising here.
False
>>ismethod(f)
True
Imagine my surprise. Why would Python do this?
Nothing magical happens at the point you said. The assignment is just an
assignment and you saw that the function was stored unchanged when you
looked in the class's dictionary.
The magic happens when you access a member of a class or an instance. If
the value is a descriptor then its __get__ method is called. Roughly
speaking, Foo.func is equivalent to:
>Foo.__dict__['func'].__get__(None, Foo)
<unbound method Foo.dan>
Python does this so that it can support other descriptor types such as
property, classmethod, staticmethod.
You can see this happening if you define your own descriptor:
>class MyDesc(object):
def __get__(self, *args):
print "__get__ called", args
return None
>d = MyDesc()
Foo.oops = d
Foo.oops
__get__ called (None, <class __main__.Foo at 0x00B3F930>)
http://docs.python.org/ref/descriptor-invocation.html has a description of
this. Although it claims "Note that descriptors are only invoked for new
style objects or classes (ones that subclass object() or type())." the
descriptor mechanism is partially implemented for old style classes.
Several aspects of descriptors don't work properly though in old-style
classes which is one reason why you should always use new-style classes.
Privates don't have to be entirely absent from Klass.__dict__
(which would make Python not introspective); they can just be invisible
when using the dot-syntax.
You could implement that using a data descriptor, but if you are going to
prevent access to your private variables using the dot operator, then your
code is going to look pretty silly with a lot of references to
self.__dict__['theprivate'] which doesn't gain anything in readability over
self.__theprivate.
I believe you are talking about the same thing as Leif, but I can't
quite tell. I'll need to read your paper as well :P.
danielx wrote:
Bruno Desthuilliers wrote:
>>danielx wrote:
(snip)
>>>which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case,
"unexpected" ? Did you ever wondered how the instance or class was
passed as first arg when doing method calls ?
Not knowing what's going on during method calls is exactly what
motivated me to post.
!-)
Ok, so now you have to read about descriptors, __getattribute__ and
__setattr__.
>
>>>why not use some more dot-magic to implement
privates?
What for ? What makes you think we need language-inforced access
restriction ?
I knew someone would bring this up.
Indeed.
The motivation would not be to
provide restriction, but to help maintain clean api's. If you intended
for users to use only a subset of the methods in your class, why not
help them learn your api by presenting the stuff they can use not along
side the stuff they should not?
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python.
....and source code...
This is exactly what it's there for. If nothing is
hidden, a user could be easily mislead to believe he can use a method
when he really shouldn't.
Single leading underscore means "implementation, don't touch or you're
on your own".
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Bruno Desthuilliers wrote:
danielx wrote:
Bruno Desthuilliers wrote:
>danielx wrote:
(snip)
>>which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case,
"unexpected" ? Did you ever wondered how the instance or class was
passed as first arg when doing method calls ?
Not knowing what's going on during method calls is exactly what
motivated me to post.
!-)
Ok, so now you have to read about descriptors, __getattribute__ and
__setattr__.
>>why not use some more dot-magic to implement
privates?
What for ? What makes you think we need language-inforced access
restriction ?
I knew someone would bring this up.
Indeed.
The motivation would not be to
provide restriction, but to help maintain clean api's. If you intended
for users to use only a subset of the methods in your class, why not
help them learn your api by presenting the stuff they can use not along
side the stuff they should not?
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python.
...and source code...
*shudders* What happened to all the goodness of abstraction?
>
This is exactly what it's there for. If nothing is
hidden, a user could be easily mislead to believe he can use a method
when he really shouldn't.
Single leading underscore means "implementation, don't touch or you're
on your own".
I'll remember that. I had forgotten what the convention was for
labeling things "do not touch".
>
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
danielx wrote:
Bruno Desthuilliers wrote:
danielx wrote:
At first I was going to post the following:
>
<!-- beginning of my original post -->
>
(snip)
>
<!-- end of my original post, with ending censored -->
>
but then I tried this:
>
>
>>>>res = Foo.__dict__['func']
>>>>res is dan
>
True
>
And it all started to make sense. The surprising thing turned out to be
not so surprising: When the expression Foo.func gets evaluated, we get
a method which is just a wrapper around dan. Therefore, f is not dan!
This is still a little bit of magic,
FWIW, the function class implements the descriptor protocol... Here's
the "magic".
which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case,
"unexpected" ? Did you ever wondered how the instance or class was
passed as first arg when doing method calls ?
Not knowing what's going on during method calls is exactly what
motivated me to post.
why not use some more dot-magic to implement
privates?
What for ? What makes you think we need language-inforced access
restriction ?
I knew someone would bring this up. The motivation would not be to
provide restriction, but to help maintain clean api's. If you intended
for users to use only a subset of the methods in your class, why not
help them learn your api by presenting the stuff they can use not along
side the stuff they should not?
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python. This is exactly what it's there for. If nothing is
hidden, a user could be easily mislead to believe he can use a method
when he really shouldn't.
if you prefix with a single underscore, that tells the user, DON'T MESS
WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
and it gets ommited from all the doc generation
if you prefix with a double underscore, then they have to go even
FARTHER out of their way to shoot themselves in the foot.
Python takes the stance of "personal responsiblity" when it comes to
access control. Which in NO WAY dimishes its "robustness" or anything
else.
just read the DailyWTF.com, incompentent people will abuse any language
features in any language, and will figure out how to break programatic
access control no matter how it is implemented. Matter of fact, Java
which in another thread someone was ADAMANT that did not expose private
anything from reflection ( and was wrong ) specifically allows you to
access all the private members, functions, everything. You just need to
tell it to turn all the "safeties" off.
>From the api:
public void setAccessible(boolean flag)
throws SecurityException
Set the accessible flag for this object to the indicated boolean value.
A value of true indicates that the reflected object should suppress
Java language access checking when it is used. A value of false
indicates that the reflected object should enforce Java language access
checks.
Setting the accessible flag in a reflected object permits sophisticated
applications with sufficient privilege, such as Java Object
Serialization or other persistence mechanisms, to manipulate objects in
a manner that would normally be prohibited.
so anything added to Python to enforce "access control" would
immediately be forced to provide some means to over-ride the checks for
pickle and the like. Not to even mention the argument that it would
break crap loads of existing code base.
danielx <da********@berkeley.eduwrote:
...and source code...
*shudders* What happened to all the goodness of abstraction?
<http://www.joelonsoftware.com/articles/LeakyAbstractions.htm>
Alex
Alex Martelli schrieb:
danielx <da********@berkeley.eduwrote:
>>...and source code...
*shudders* What happened to all the goodness of abstraction?
<http://www.joelonsoftware.com/articles/LeakyAbstractions.htm>
Misses an l at the end: http://www.joelonsoftware.com/articl...tractions.html
Diez
danielx wrote:
Bruno Desthuilliers wrote:
>>danielx wrote:
(snip)
>>>
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python.
...and source code...
*shudders* What happened to all the goodness of abstraction?
Compared to machine language, Python source code is really abstration.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
On 2006-07-21, fuzzylollipop <ja*************@gmail.comwrote:
>
danielx wrote:
>Bruno Desthuilliers wrote:
danielx wrote:
At first I was going to post the following:
<!-- beginning of my original post -->
(snip)
<!-- end of my original post, with ending censored -->
but then I tried this:
res = Foo.__dict__['func']
res is dan
True
And it all started to make sense. The surprising thing turned out to be
not so surprising: When the expression Foo.func gets evaluated, we get
a method which is just a wrapper around dan. Therefore, f is not dan!
This is still a little bit of magic,
FWIW, the function class implements the descriptor protocol... Here's
the "magic".
which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case,
"unexpected" ? Did you ever wondered how the instance or class was
passed as first arg when doing method calls ?
Not knowing what's going on during method calls is exactly what
motivated me to post.
>
why not use some more dot-magic to implement
privates?
What for ? What makes you think we need language-inforced access
restriction ?
I knew someone would bring this up. The motivation would not be to
provide restriction, but to help maintain clean api's. If you intended
for users to use only a subset of the methods in your class, why not
help them learn your api by presenting the stuff they can use not along
side the stuff they should not?
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python. This is exactly what it's there for. If nothing is
hidden, a user could be easily mislead to believe he can use a method
when he really shouldn't.
if you prefix with a single underscore, that tells the user, DON'T MESS
WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
Personnaly I don't like this convention. It isn't clear enough.
Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module. So now I have
variables with an underscore which have two different meanings:
1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
2) This is an implemantation detail of the other module,
I should be extra carefull using it.
And I find variable starting or ending with an underscore ugly. :-)
--
Antoon Pardon
Antoon Pardon wrote:
On 2006-07-21, fuzzylollipop <ja*************@gmail.comwrote:
>>danielx wrote:
(snip)
>>
if you prefix with a single underscore, that tells the user, DON'T MESS
WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
Personnaly I don't like this convention.
To bad for you.
It isn't clear enough.
Oh yes ?
Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module.
So now I have
variables with an underscore which have two different meanings:
1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
2) This is an implemantation detail of the other module,
I should be extra carefull using it.
Either you imported with the "from othermodule import *" form (which you
shouldn't do), and you *don't* have the implementation of othermodule,
or your used the "import othermodule" form, in which case it's pretty
obvious which names belongs to othermodule.
Have any other, possibly valid, reason ?
And I find variable starting or ending with an underscore ugly. :-)
Too bad for you. Choose another language then... PHP, Perl, Ruby ?-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
On 2006-07-20 18:10:21, danielx wrote:
>>When supporting documents aren't sufficient to learn an api (I'm sure
this never happens, so just humor me), you can always turn to
interactive Python.
...and source code...
*shudders* What happened to all the goodness of abstraction?
Abstraction as you seem to use it requires complete docs of the interface.
Which is what you said you don't have... So the original abstractor broke
the abstraction when publishing insufficient docs, not the one who looks
into the sources to find out what actually happens.
(This independently of the merits of abstraction.)
Gerhard
Antoon Pardon wrote:
Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module. So now I have
variables with an underscore which have two different meanings:
you don't understand what "implementation detail" means, it means it is
NOT part of the public API and no client code should ever use it.
If you reference _vara in your code and it is in someone elses module
you don't understand YOU ARE NOT SUPPOSED TO DO THAT!
1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
Users of your module should NEVER KNOW any of the _ or __ stuff exists
to begin with.
2) This is an implemantation detail of the other module,
I should be extra carefull using it.
You should NEVER use it.
And I find variable starting or ending with an underscore ugly. :-)
--
Antoon Pardon
But like my previous post states, you can mark stuff private in Java
all you want, you can still access. Having the compiler or runtime
enforce that just adds an extra step to turn that enforcement off.
You can do the same thing, in C++.
So WHY does a language need this enforcement.
And the "large code base" needs the "robustness" is not a valid
argument.
Since Apple has proven this NOT to be the case with Cocoa which is in
Objective-C and "knows about access control but doesn't really use
them"
Anyone that things a language HAS to have these constructs enforced by
the compiler or runtime, lacks disipline.
Python has exactly what every other language EFFECTIVELY has, a common
way to document or "tag" what is _private but might need "Friend"
access, and what is REALLY __private.
If you don't like this, then that is your problem go use a language
that gives you that false sense of secuirty, don't expect it to change.
Bruno Desthuilliers wrote:
danielx wrote:
Bruno Desthuilliers wrote:
>danielx wrote:
(snip)
>>
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python.
...and source code...
*shudders* What happened to all the goodness of abstraction?
Compared to machine language, Python source code is really abstration.
And machine language is an abstraction of pushing electrons around
circuits. I'm not sure I see your point, unless it is simply that
Python is easier than asm.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Gerhard Fiedler wrote:
On 2006-07-20 18:10:21, danielx wrote:
>When supporting documents aren't sufficient to learn an api (I'm sure
this never happens, so just humor me), you can always turn to
interactive Python.
...and source code...
*shudders* What happened to all the goodness of abstraction?
Abstraction as you seem to use it requires complete docs of the interface.
Which is what you said you don't have... So the original abstractor broke
the abstraction when publishing insufficient docs, not the one who looks
into the sources to find out what actually happens.
Absolutely. I didn't mean the user was breaking abstraction (let's not
blame the victim). I was saying that we should really have more
sympathy for him.
>
(This independently of the merits of abstraction.)
Gerhard
danielx a écrit :
Bruno Desthuilliers wrote:
>>danielx wrote:
>>>Bruno Desthuilliers wrote:
danielx wrote:
(snip)
>>>>>Obviously, such things would be omitted from your docs, but users also
>learn by interacting with Python, which is really one of Python's great
>virtues. When supporting documents aren't sufficient to learn an api
>(I'm sure this never happens, so just humor me), you can always turn to
>interactive Python.
...and source code...
*shudders* What happened to all the goodness of abstraction?
Compared to machine language, Python source code is really abstration.
And machine language is an abstraction of pushing electrons around
circuits. I'm not sure I see your point, unless it is simply that
Python is easier than asm.
Python is very hi-level, and very often well-written Python code is it's
own better documentation.
fuzzylollipop wrote:
danielx wrote:
Bruno Desthuilliers wrote:
danielx wrote:
At first I was going to post the following:
<!-- beginning of my original post -->
(snip)
<!-- end of my original post, with ending censored -->
but then I tried this:
>>>res = Foo.__dict__['func']
>>>res is dan
True
And it all started to make sense. The surprising thing turned out to be
not so surprising: When the expression Foo.func gets evaluated, we get
a method which is just a wrapper around dan. Therefore, f is not dan!
This is still a little bit of magic,
>
FWIW, the function class implements the descriptor protocol... Here's
the "magic".
>
which gets me thinking again about
the stuff I self-censored. Since the dot syntax does something special
and unexpected in my case,
>
"unexpected" ? Did you ever wondered how the instance or class was
passed as first arg when doing method calls ?
Not knowing what's going on during method calls is exactly what
motivated me to post.
>
why not use some more dot-magic to implement
privates?
>
What for ? What makes you think we need language-inforced access
restriction ?
I knew someone would bring this up. The motivation would not be to
provide restriction, but to help maintain clean api's. If you intended
for users to use only a subset of the methods in your class, why not
help them learn your api by presenting the stuff they can use not along
side the stuff they should not?
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turn to
interactive Python. This is exactly what it's there for. If nothing is
hidden, a user could be easily mislead to believe he can use a method
when he really shouldn't.
if you prefix with a single underscore, that tells the user, DON'T MESS
WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
and it gets ommited from all the doc generation
if you prefix with a double underscore, then they have to go even
FARTHER out of their way to shoot themselves in the foot.
Python takes the stance of "personal responsiblity" when it comes to
access control. Which in NO WAY dimishes its "robustness" or anything
else.
just read the DailyWTF.com, incompentent people will abuse any language
features in any language, and will figure out how to break programatic
access control no matter how it is implemented. Matter of fact, Java
which in another thread someone was ADAMANT that did not expose private
anything from reflection ( and was wrong ) specifically allows you to
access all the private members, functions, everything. You just need to
tell it to turn all the "safeties" off.
From the api:
public void setAccessible(boolean flag)
throws SecurityException
Set the accessible flag for this object to the indicated boolean value.
A value of true indicates that the reflected object should suppress
Java language access checking when it is used. A value of false
indicates that the reflected object should enforce Java language access
checks.
Setting the accessible flag in a reflected object permits sophisticated
applications with sufficient privilege, such as Java Object
Serialization or other persistence mechanisms, to manipulate objects in
a manner that would normally be prohibited.
so anything added to Python to enforce "access control" would
immediately be forced to provide some means to over-ride the checks for
pickle and the like. Not to even mention the argument that it would
break crap loads of existing code base.
Sigh. I TOTALLY realize that Python works by politeness and not
enforcement. I think you are misinterpreting why I think this would be
a good idea. My concern is not with control, but with convenience. My
suggestion was that privates would only be invisible if you use the dot
syntax (ie if you are an external user); they would not be invisible
altogether (they would still be in __dict__ with no name games).
One problem which was brought up about this was that self.meth and
outsider.meth would have to be interpretted differently. I suspect (but
I haven't finished my reading assignment :P) that you could find a good
way around this.
With respect to breaking stuff. I'm not sure why that would be
necessary. If current code does not say any member is private,
everything that was visible before (ie everything) would still be
visible after.
Last thing. You mentioned that auto doc generation omits
underscore-prefixed and name mangled members. dir on the other hand
does not. Maybe this suggests only a minor future improvement.
Bruno Desthuilliers wrote:
danielx a écrit :
Bruno Desthuilliers wrote:
>danielx wrote:
Bruno Desthuilliers wrote:
danielx wrote:
(snip)
Obviously, such things would be omitted from your docs, but users also
learn by interacting with Python, which is really one of Python's great
virtues. When supporting documents aren't sufficient to learn an api
(I'm sure this never happens, so just humor me), you can always turnto
interactive Python.
...and source code...
*shudders* What happened to all the goodness of abstraction?
Compared to machine language, Python source code is really abstration.
And machine language is an abstraction of pushing electrons around
circuits. I'm not sure I see your point, unless it is simply that
Python is easier than asm.
Python is very hi-level, and very often well-written Python code is it's
own better documentation.
Yes, Python is very easy to read, but who's supposed to be reading it?
Maintainers or users? I'm really against code acting as its own
documentation. Of course the code is authoritative, but should we
really EXPECT it to serve as a reference to users??
Appearantly, this view puts me in the minority...
danielx a écrit :
>
(snip)
Sigh. I TOTALLY realize that Python works by politeness and not
enforcement. I think you are misinterpreting why I think this would be
a good idea. My concern is not with control, but with convenience.
Having free access to implementation is convenient IMHO.
My
suggestion was that privates would only be invisible if you use the dot
syntax (ie if you are an external user); they would not be invisible
altogether (they would still be in __dict__ with no name games).
How would this work for class attributes ? (implementation methods,
implementation descriptors etc...)
Also, it would impact lookup perfs, which is already a somewhat weak
point in Python.
Bruno Desthuilliers wrote:
Antoon Pardon wrote:
On 2006-07-21, fuzzylollipop <ja*************@gmail.comwrote:
>danielx wrote:
(snip)
>
if you prefix with a single underscore, that tells the user, DON'T MESS
WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
Personnaly I don't like this convention.
To bad for you.
It isn't clear enough.
Oh yes ?
Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module.
So now I have
variables with an underscore which have two different meanings:
1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
2) This is an implemantation detail of the other module,
I should be extra carefull using it.
Either you imported with the "from othermodule import *" form (which you
shouldn't do), and you *don't* have the implementation of othermodule,
or your used the "import othermodule" form, in which case it's pretty
obvious which names belongs to othermodule.
Have any other, possibly valid, reason ?
And I find variable starting or ending with an underscore ugly. :-)
Too bad for you. Choose another language then... PHP, Perl, Ruby ?-)
"Too bad for you": While you have a valid point that this contention is
really just arbitrary (just like all conventions), could we be a little
gentler?
Personally, I don't think it looks very good either, but you just have
to deal with it if you're going to use the language properly.
danielx a écrit :
Bruno Desthuilliers wrote:
>>danielx a écrit :
>>>Bruno Desthuilliers wrote:
danielx wrote:
>Bruno Desthuilliers wrote:
>
>
>
>>danielx wrote:
>>
(snip)
>>>Obviously, such things would be omitted from your docs, but users also
>>>learn by interacting with Python, which is really one of Python's great
>>>virtues. When supporting documents aren't sufficient to learn an api
>>>(I'm sure this never happens, so just humor me), you can always turn to
>>>interactive Python.
>>
>>...and source code...
>
>
>*shudders* What happened to all the goodness of abstraction?
Compared to machine language, Python source code is really abstration.
And machine language is an abstraction of pushing electrons around
circuits. I'm not sure I see your point, unless it is simply that
Python is easier than asm.
Python is very hi-level, and very often well-written Python code is it's
own better documentation.
Yes, Python is very easy to read, but who's supposed to be reading it?
Maintainers or users?
In an ideal world, nobody !-)
I'm really against code acting as its own
documentation.
I'm really for it, because :
Of course the code is authoritative,
indeed.
but should we
really EXPECT it to serve as a reference to users??
Unless you're able to maintain a good, accurate and always up to date
documentation, you can be sure users (ie other programmers) will turn to
the code. Also, there are cases where even a pretty good doc is not
enough, and you really have to turn to the code to know for sure how to
best implement something.
FWIW, reading source code can be very instructive...
On 2006-07-21, Bruno Desthuilliers <on***@xiludom.growrote:
Antoon Pardon wrote:
>On 2006-07-21, fuzzylollipop <ja*************@gmail.comwrote:
>>>danielx wrote:
(snip)
>>>
if you prefix with a single underscore, that tells the user, DON'T MESS
WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
Personnaly I don't like this convention.
To bad for you.
I'll survive.
>It isn't clear enough.
Oh yes ?
>Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module.
So now I have
variables with an underscore which have two different meanings:
1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
2) This is an implemantation detail of the other module,
I should be extra carefull using it.
Either you imported with the "from othermodule import *" form (which you
shouldn't do), and you *don't* have the implementation of othermodule,
or your used the "import othermodule" form, in which case it's pretty
obvious which names belongs to othermodule.
As far as I understand the _name convention is often defended with the
argument that it stands out. Now if you have to go and look at the
import statements to make a disticntion, then it seems that the
way _names standout isn't that usefull.
>And I find variable starting or ending with an underscore ugly. :-)
Too bad for you. Choose another language then... PHP, Perl, Ruby ?-)
Not a very strong argument. Whether or not someone has a legitimat point
of criticism against Python or some of the conventions used. You can
always reply: Too bad, better choose another language then.
--
Antoon Pardon
On 2006-07-21, fuzzylollipop <ja*************@gmail.comwrote:
>
Antoon Pardon wrote:
>Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module. So now I have
variables with an underscore which have two different meanings:
you don't understand what "implementation detail" means, it means it is
NOT part of the public API and no client code should ever use it.
If you reference _vara in your code and it is in someone elses module
you don't understand YOU ARE NOT SUPPOSED TO DO THAT!
Why do you assume that in my example the other module is
not understood?
> 1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
Users of your module should NEVER KNOW any of the _ or __ stuff exists
to begin with.
> 2) This is an implemantation detail of the other module,
I should be extra carefull using it.
You should NEVER use it.
Well that may be your view, but AFAICS it is not the view of
the python community. Because each time some mechanism is
proposed for real private variable, people oppose it, they
want people to have access to what are supposed to be
private variables.
--
Antoon Pardon
On 2006-07-22 16:32:38, danielx wrote:
>>>...and source code...
*shudders* What happened to all the goodness of abstraction?
Abstraction as you seem to use it requires complete docs of the interface.
Which is what you said you don't have... So the original abstractor broke
the abstraction when publishing insufficient docs, not the one who looks
into the sources to find out what actually happens.
Absolutely. I didn't mean the user was breaking abstraction (let's not
blame the victim). I was saying that we should really have more
sympathy for him.
I have all the sympathy in the world for him... after all, he's me :)
But one reason why I try to write (and insist on as much as possible from
people writing for or with me) self-documenting code is that wherever you
have documentation and code separated (which is the case of API docs), you
can bet (without losing) that sooner or later code and doc will diverge.
This has a probability that approaches 1 :)
So, I agree with you that good API docs are a good thing, as they tell me
everything I need to know without having to wade through tons of
implementation details that may be interesting but don't serve my immediate
need (of having to use the API). But reality seems to be (and mine so far
definitely is) that these docs, even the good ones, are not completely in
alignment with the reality of the code. (We all know that code has bugs...
and the API always describes, at best, how the code /should/ work. It never
describes how it actually works, including the bugs <g(this
notwithstanding the bugs that have been elevated to features and henceforth
been described in the API docs).
So... the final authority /is/ the code. I don't see an alternative. For
me, good abstraction doesn't mean I don't have to read the sources; good
abstraction means (among other things) that I can read the sources easily.
Gerhard
Antoon Pardon wrote:
On 2006-07-21, Bruno Desthuilliers <on***@xiludom.growrote:
>>Antoon Pardon wrote:
>>>On 2006-07-21, fuzzylollipop <ja*************@gmail.comwrote:
danielx wrote:
(snip)
>>>>
if you prefix with a single underscore, that tells the user, DON'T MESS
WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
Personnaly I don't like this convention.
To bad for you.
I'll survive.
>>>It isn't clear enough.
Oh yes ?
>>>Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module.
So now I have
variables with an underscore which have two different meanings:
1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
2) This is an implemantation detail of the other module,
I should be extra carefull using it.
Either you imported with the "from othermodule import *" form (which you
shouldn't do), and you *don't* have the implementation of othermodule,
or your used the "import othermodule" form, in which case it's pretty
obvious which names belongs to othermodule.
As far as I understand the _name convention is often defended with the
argument that it stands out.
It does.
Now if you have to go and look at the
import statements to make a disticntion, then it seems that the
way _names standout isn't that usefull.
Please re-read the Fine Manual and try to understand what I wrote above.
You don't have to parse the import statements to know if you're dealing
with a local implementation detail or implementation of another module,
unless you do braindead renames of imported symbols.
Anyway, messing with another module's implementation should be *very* rare.
>
>>>And I find variable starting or ending with an underscore ugly. :-)
Too bad for you. Choose another language then... PHP, Perl, Ruby ?-)
Not a very strong argument. Whether or not someone has a legitimat point
of criticism against Python or some of the conventions used. You can
always reply: Too bad, better choose another language then.
There are very few chances this convention will change anytime soon. You
may not like it for any good or bad reason, the fact is that you have to
live with it.
FWIW, the choice of other languages I proposed as an alternative is not
totally innocent : they all are possible replacements for Python, and
they all have their share of ugly cryptic notations... I'm not myself a
big fan of the leading underscore, but it's certainly a lesser evil when
compared to $php_vars or others @myperlishstuff. Or with C++
m_myMemberVar FWIW.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Antoon Pardon wrote:
On 2006-07-21, fuzzylollipop <ja*************@gmail.comwrote:
>>Antoon Pardon wrote:
>>>Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module. So now I have
variables with an underscore which have two different meanings:
you don't understand what "implementation detail" means, it means it is
NOT part of the public API and no client code should ever use it.
If you reference _vara in your code and it is in someone elses module
you don't understand YOU ARE NOT SUPPOSED TO DO THAT!
Why do you assume that in my example the other module is
not understood?
He doesn't, but it's clear that *you* didn't understand what
fuzzylollipop meant !-)
Hint : add a comma at the right place so parsing is unambigous:
"""
If you reference _vara in your code and it is in someone elses module,
you don't understand YOU ARE NOT SUPPOSED TO DO THAT!
"""
>
>> 1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
Users of your module should NEVER KNOW any of the _ or __ stuff exists
to begin with.
>> 2) This is an implemantation detail of the other module,
I should be extra carefull using it.
You should NEVER use it.
Well that may be your view, but AFAICS it is not the view of
the python community. Because each time some mechanism is
proposed for real private variable, people oppose it, they
want people to have access to what are supposed to be
private variables.
I'd express it in a somewhat different way: the view of the Python
community is that language-inforced access restrictions are useless and
annoying, IOW an unnecessary pain. Which doesn't imply that messing with
implementation of other modules is actually *encouraged*. Having the
possibility to easily do so is quite handy when that's the only/less
worse solution, but is not a recommended approach in general.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Gerhard Fiedler wrote:
On 2006-07-22 16:32:38, danielx wrote:
>>...and source code...
*shudders* What happened to all the goodness of abstraction?
Abstraction as you seem to use it requires complete docs of the interface.
Which is what you said you don't have... So the original abstractor broke
the abstraction when publishing insufficient docs, not the one who looks
into the sources to find out what actually happens.
Absolutely. I didn't mean the user was breaking abstraction (let's not
blame the victim). I was saying that we should really have more
sympathy for him.
I have all the sympathy in the world for him... after all, he's me :)
But one reason why I try to write (and insist on as much as possible from
people writing for or with me) self-documenting code is that wherever you
have documentation and code separated (which is the case of API docs), you
can bet (without losing) that sooner or later code and doc will diverge.
This has a probability that approaches 1 :)
So, I agree with you that good API docs are a good thing, as they tell me
everything I need to know without having to wade through tons of
implementation details that may be interesting but don't serve my immediate
need (of having to use the API). But reality seems to be (and mine so far
definitely is) that these docs, even the good ones, are not completely in
alignment with the reality of the code. (We all know that code has bugs...
and the API always describes, at best, how the code /should/ work. It never
describes how it actually works, including the bugs <g(this
notwithstanding the bugs that have been elevated to features and henceforth
been described in the API docs).
So... the final authority /is/ the code. I don't see an alternative. For
me, good abstraction doesn't mean I don't have to read the sources; good
abstraction means (among other things) that I can read the sources easily.
Gerhard
having auto generated docs, which means the documentatin is in the code
as doc strings, javadoc, reflex, or whatever format is the BEST way of
doing API documentation, period.
Antoon Pardon wrote:
On 2006-07-21, fuzzylollipop <ja*************@gmail.comwrote:
Antoon Pardon wrote:
Suppose I am writing my own module, I use an underscore, to
mark variables which are an implementation detail for my
module.
Now I need to import an other module in my module and need access
to an implementation variable from that module. So now I have
variables with an underscore which have two different meanings:
you don't understand what "implementation detail" means, it means it is
NOT part of the public API and no client code should ever use it.
If you reference _vara in your code and it is in someone elses module
you don't understand YOU ARE NOT SUPPOSED TO DO THAT!
Why do you assume that in my example the other module is
not understood?
1) This is an implemantation detail of this module, It is the
users of my module who have to be extra carefull using it.
Users of your module should NEVER KNOW any of the _ or __ stuff exists
to begin with.
2) This is an implemantation detail of the other module,
I should be extra carefull using it.
You should NEVER use it.
Well that may be your view, but AFAICS it is not the view of
the python community. Because each time some mechanism is
proposed for real private variable, people oppose it, they
want people to have access to what are supposed to be
private variables.
--
Antoon Pardon
actually you are really way off base, the _ and __ convention IS the
INTENDED way of doing private and "really private" documentation of
members in Python.
I didn't make this up, it is in the official Python documentation.
You need to read my previous response for COMPREHENSION one more time.
There is LESS THAN ZERO value in having a runtime enforcement of member
access control.
Python does have ALREADY have an OFFICAL mechanism for private members,
prefix your names with _ or __. Both are ommited from autogenerated
docuementation and both are OFFICALLY not supposed to be used.
On 2006-07-24 13:25:14, fuzzylollipop wrote:
>So... the final authority /is/ the code. I don't see an alternative. For
me, good abstraction doesn't mean I don't have to read the sources; good
abstraction means (among other things) that I can read the sources easily.
having auto generated docs, which means the documentatin is in the code
as doc strings, javadoc, reflex, or whatever format is the BEST way of
doing API documentation, period.
It may be the best way, no contest to that. But it still is not the code.
(I actually think that possibly the current way of embedding javadoc-like
documentation into sources is only a stepping stone into the direction
generally pointed to by what Wirth called "literate programming". In any
case, I'd rather not call it the "best way, period"; calling it the "best
currently widely supported way" seems more appropriate to me.)
Even doc strings tend to get out of sync with the code. And even doc
strings document (at best) what the code should do, not what it actually
does. And even doc strings are not always complete in describing the
functionality.
So auto generated docs are also incomplete and out of sync with the code,
sometimes more, sometimes less, sometimes so little that it is not
relevant. But you can't know how much out of sync they are from reading the
docs alone. So when push comes to shove (or so the saying goes? :), the
code is the authority. Even with auto generated docs. Period... ?!? <g>
Gerhard
On 2006-07-24 14:41:02, Gerhard Fiedler wrote:
(I actually think that possibly the current way of embedding javadoc-like
documentation into sources is only a stepping stone into the direction
generally pointed to by what Wirth called "literate programming".
That was Knuth, not Wirth. But this is not really that relevant.
Gerhard
On 2006-07-25 05:16:04, Wesley Brooks wrote:
>prefix your names with _ or __. Both are ommited from autogenerated
docuementation and both are OFFICALLY not supposed to be used.
Could you elaborate on that a little or point me in the right direction to
read up on it? I'm currently re-writing a large lump of my coding and trying
to use best practice. I thought it was considered good practice to make
stuff private (in this case using __ ) that wasn't intened to be accessed
from outside the function/class?
I think fuzzylollipop meant that such members should not be used from the
outside of the class; that is, they should be considered implementation,
not API. (Which is why apparently autogenerated docs leave them out.)
Gerhard
Gerhard Fiedler <ge*****@gmail.comwrote:
On 2006-07-25 05:16:04, Wesley Brooks wrote:
prefix your names with _ or __. Both are ommited from autogenerated
docuementation and both are OFFICALLY not supposed to be used.
Could you elaborate on that a little or point me in the right direction to
read up on it? I'm currently re-writing a large lump of my coding and trying
to use best practice. I thought it was considered good practice to make
stuff private (in this case using __ ) that wasn't intened to be accessed
from outside the function/class?
I think fuzzylollipop meant that such members should not be used from the
outside of the class; that is, they should be considered implementation,
not API. (Which is why apparently autogenerated docs leave them out.)
Unfortunately, there is a slight ambiguity here. Consider for example
the wonderful Queue class. Its methods _put, _get are not documented in
help(Queue.Queue) nor on <http://docs.python.org/lib/QueueObjects.html>,
respecting the "private" convention.
But if you read Queue.py, you'll see...:
# Override these methods to implement other queue organizations
# (e.g. stack or priority queue).
# These will only be called with appropriate locks held
...
# Put a new item in the queue
def _put(self, item):
...
etc -- i.e., Queue.py itself strongly appears to consider these methods
*protected* (in C++ parlance), NOT *private*. Indeed, the only reason
these methods are factored out is exactly as "hook methods" (meant to be
overridden by subclasses), in a beautiful example of the "Template
Method" design pattern (in the specific variant in which the methods MAY
but DON'T HAVE TO be overridden, because the base class, Queue.Queue,
already provides them with useful functionality -- a LIFO queue).
Unfortunately Python does not have any specific naming convention to
indicate "methods that should never be CALLED by client code, but may be
usefully OVERRIDDEN in subclasses", so the leading-underscore one does
double duty -- and since the simpler interpretation "this is a private
implementation detail, ignore it completely" is so much more common than
the one about "this is a hook method which you should override in a
subclass if you want to tweak some detail of functionality", it's all
too easy to forget about the latter case (fortunately Queue.Queue is
there to remind us of it:-).
Alex This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Fernando Rodriguez |
last post by:
Hi,
I need to traverse the methods defined in a class and its superclasses. This
is the code I'm using:
# An instance of class B should be able to check all the methods defined in B
#and A,...
|
by: Robert |
last post by:
Python doesn't know the class of a method when container not direct
class attribute:
>>> class X:
.... def f():pass
.... g=f
.... l=
....
>>> X.g
<unbound method X.f>
|
by: Lenard Lindstrom |
last post by:
I was wondering if anyone has suggested having Python determine
a method's kind from its first parameter. 'self' is a de facto
reserved word; 'cls' is a good indicator of a class method
( __new__...
|
by: Gregory Bond |
last post by:
I'm building a class hierarchy that needs to keep as a class variable a
reference to a (non-member) function, so that different subclasses can
use different generator functions. But it seems...
|
by: laredotornado |
last post by:
Hello, I am looking for a cross-browser way (Firefox 1+, IE 5.5+) to
have my Javascript function execute from the BODY's "onload" method,
but if there is already an onload method defined, I would...
|
by: Martin Vorbrodt |
last post by:
Example code in one of my books intrigues me:
class B {
public:
B* Clone() const {
B* p = DoClone();
assert(typeid(*p) == typeid(*this));
return p;
}
|
by: Edward Diener |
last post by:
In C++ an overridden virtual function in a derived class must have the exact
same signature of the function which is overridden in the base class, except
for the return type which may return a...
|
by: Patient Guy |
last post by:
The code below shows the familiar way of restricting a function to be a
method of a constructed object:
function aConstructor(arg)
{
if (typeof(arg) == "undefined")
return (null);...
|
by: idoerg |
last post by:
Hi all,
I am running Python 2.5 on Feisty Ubuntu. I came across some code that
is substantially slower when in a method than in a function.
################# START SOURCE #############
# The...
|
by: Viktor |
last post by:
Can somebody give me an explanation what happened here (or point me to
some docs)?
Code:
HMMM = None
def w(fn):
print 'fn:', id(fn)
HMMM = fn
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
