[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Andrew Svetlov]

Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[miss-islington]

miss-islington  added the comment:


New changeset 606ac581e2451c420117c55632f0fe13d4cec2cd by Miss Islington (bot) 
in branch '3.8':
bpo-37150: Throw ValueError if FileType class object was passed in add_argument 
(GH-13805)
https://github.com/python/cpython/commit/606ac581e2451c420117c55632f0fe13d4cec2cd


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[miss-islington]

Change by miss-islington :


--
pull_requests: +13776
pull_request: https://github.com/python/cpython/pull/13901

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[miss-islington]

miss-islington  added the comment:


New changeset 03d5831a2d62c68654ec223168e574cd546efbf6 by Miss Islington (bot) 
(zygocephalus) in branch 'master':
bpo-37150: Throw ValueError if FileType class object was passed in add_argument 
(GH-13805)
https://github.com/python/cpython/commit/03d5831a2d62c68654ec223168e574cd546efbf6


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Michele Angrisano]

Change by Michele Angrisano :


--
nosy: +bethard

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Demid]

Demid  added the comment:

What if I will add mode check in FileType.__init__?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Ah, right. It doesn't actually validate the mode string (it just stores it for 
when open is called, assuming open will validate it). So yeah, it silently 
accepts any string, not just valid mode strings. Not a contractual guarantee or 
anything, just how FileType.__init__ is implemented.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Demid]

Demid  added the comment:

If you will run `python test.py hello.txt, where test.py is:

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('echo', type=argparse.FileType)
args = parser.parse_args()
print(args.echo)

You will receive:
FileType('hello.txt')

I think that can be confusing for someone who will forget to invoke FileType 
constructor.

‐‐‐ Original Message ‐‐‐
On Tuesday, June 4, 2019 10:27 PM, Michele Angrisano  
wrote:

>
>
> Michele angrisanomichele.angris...@gmail.com added the comment:
>
> Reading the examples in the doc, it's clear the behavior when FileType takes 
> an argument. What's the behavior of FileType when is called without any 
> argument?
>
> -
>
> nosy: +mangrisano
>
> Python tracker rep...@bugs.python.org
> https://bugs.python.org/issue37150

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Michele Angrisano]

Michele Angrisano  added the comment:

Yes, I meant that. Thanks! :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Josh Rosenberg]

Josh Rosenberg  added the comment:

The docs specify what argparse.FileType() does via the default parameters: 
https://docs.python.org/3/library/argparse.html#argparse.FileType

If you mean what does it do when you fail to call it at all (passing 
type=argparse.FileType), the answer is the same as any other class: It tries to 
construct a FileType using the user provided argument as the sole positional 
argument. So if the user passes a valid mode string, it works, and returns a 
FileType object with that mode string, otherwise it barfs and dumps an error 
message for passing an invalid argument for FileType.

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Michele Angrisano]

Michele Angrisano  added the comment:

Reading the examples in the doc, it's clear the behavior when FileType takes an 
argument. What's the behavior of FileType when is called without any argument?

--
nosy: +mangrisano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[paul j3]

paul j3  added the comment:

I don't see an easy way around this.  FileType is a class, and thus is a 
callable.  add_argument checks that the 'type' parameter is a callable (or a 
string in the registry).  Otherwise it gives the programmer a lot of freedom 
regarding this parameter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +paul.j3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[SilentGhost]

Change by SilentGhost :


--
versions:  -Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Demid]

Change by Demid :


--
keywords: +patch
pull_requests: +13690
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13805

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Demid]

New submission from Demid :

There is a possibility that someone (like me) accidentally will omit 
parentheses with FileType arguments after FileType, and parser will contain 
wrong file until someone will try to use it. 

Example:
parser = argparse.ArgumentParser()
parser.add_argument('-x', type=argparse.FileType)

--
components: Library (Lib)
messages: 344568
nosy: zygocephalus
priority: normal
severity: normal
status: open
title: Do not allow to pass FileType class object instead of instance in 
add_argument
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue37150>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: An object is an instance (or not)?

[Steven D'Aprano]

Gregory Ewing wrote:

 Steven D'Aprano wrote:
 Actually, if you look at my example, you will see that it is a method and
 it does get the self argument. Here is the critical code again:
 
 from types import MethodType
 polly.talk = MethodType(
 lambda self: print(Polly wants a spam sandwich!), polly)
 
 Doing it by hand is cheating.

Smile when you say that, pardner :-)

I don't see why you think I'm cheating. What rule do you think is being
broken? I want to add a method to the instance itself, so I create a method
object and put it on the instance. What should I have done?

The default metaclass (type) only applies the descriptor protocol to
attributes retrieved from the class itself, not those retrieved from the
instance. For instance, you can add a property object onto the instance,
but it won't behave as a property:

py class K(object):
... pass
...
py x = K()
py x.spam = property(lambda self: 23)
py x.spam
property object at 0xb7bbcb44


But if I add it to the class, the descriptor magic happens:

py K.eggs = x.spam
py x.eggs
23

Functions are descriptors, just like property objects! So an alternative to
manually making a method object would be to use a metaclass that extended
the descriptor protocol to instance attributes. I suppose you would call
that cheating too?

But all of this is a side-show that distracts from my point, which is that
the lookup rules for instances and classes are such that you can override
behaviour defined in the class on a per-instance basis. The mechanics of
such aren't really relevant.


 That's certainly not correct, because Python had classes and instances
 before it had descriptors!
 
 Before the descriptor protocol, a subset of its functionality
 was hard-wired into the interpreter. There has always been
 some magic going on across the instance-class boundary that
 doesn't occur across the class-baseclass boundary.

Yes, but that magic is effectively implementation, not interface. I put
that in scare quotes because in actual pedantic fact, the descriptor
protocol is an interface: we can write our own custom descriptors. I don't
dispute that's important.

But from a birds eye view, and looking at just method and regular attribute
access, the relationship between instance-class and class-baseclass is very
similar, as is that between class-metaclass, and descriptor magic is merely
part of the implementation to make things work.

I daresay you are right that there are a few places where the interpreter
treats classes as a distinct and different kind of thing than non-class
instances. One obvious place is that dunder methods are not looked up on
the instance, unlike pretty much everything else. But I did preface my
comments about attribute lookup order as being simplified, so you can
probably find a lot more to criticise if you wish :-)



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Gregory Ewing]

Steven D'Aprano wrote:
Actually, if you look at my example, you will see that it is a method and it 
does get the self argument. Here is the critical code again:


from types import MethodType
polly.talk = MethodType(
lambda self: print(Polly wants a spam sandwich!), polly)


Doing it by hand is cheating.

That's certainly not correct, because Python had classes and instances 
before it had descriptors!


Before the descriptor protocol, a subset of its functionality
was hard-wired into the interpreter. There has always been
some magic going on across the instance-class boundary that
doesn't occur across the class-baseclass boundary.

Ah wait, I 
think I've got it. If you want (say) your class object itself to support 
(say) the + operator, it isn't enough to write a __add__ method on the 
class, you have to write it on the metaclass.


That's right.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ian Kelly]

On Thu, Jan 29, 2015 at 12:16 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 Besides, descriptors are
 handled by the metaclass, so we could write a metaclass that doesn't handle
 them.

Maybe this doesn't affect your argument, but they're actually handled
by the class's __getattribute__, not by the metaclass.

 class MyMeta(type):
...   def __getattribute__(cls, attr):
... raise AttributeError(attr)
...
 class MyClass(metaclass=MyMeta):
...   @property
...   def spam(self):
... return 42
...
 MyClass().spam
42
 class MyClass:
...   def __getattribute__(self, attr):
... return type(self).__dict__[attr]
...   @property
...   def spam(self):
... return 42
...
 MyClass().spam
property object at 0x7f0603e70598
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rick Johnson]

On Wednesday, January 28, 2015 at 4:01:41 AM UTC-6, Chris Angelico wrote:
 On Wed, Jan 28, 2015 at 8:16 PM, Steven D'Aprano wrote:
  Or perhaps that should be a sad face smiley :-( How much
  time we would all save if academics and language
  designers would only stick to a single consistent
  terminology across all languages.

 That's like wishing that every human spoke the same
 language, instead of having English, French, Italian,
 Polish, Serbian, Korean, and a host of others. The problem
 isn't the languages; the variety of languages reflects a
 variety of concepts being communicated,

Yes guys, because everyone knows that selfish adolescent
accessorizing is the *KEY* to building a sane human
knowledge base! I mean, who needs a single word (or grunt)
to mean, say, cat-herding, when infinitely more selfish
incarnations can be invented on the fly!!!

##
# Untested Code:
##

 def pollute_the_database(concept):
 for region in world.regions:
 # XXX: Avoid buffer overflows!
 grunt = region.generate_grunt(concept)
 database.setdefault(concept, {aliases:[]})
 database[concept][aliases].append(str(grunt))

 if __game__ == __existentialism__:
 concepts = humans.collectiveConciseness
 database = humans.collectiveDatabase
 while len(concepts)  0:
 # XXX: Make thread safe!
 conceptN = concepts.pop()
 if is_selfishly_infantile(humans):
 pollute_the_database(conceptN)
 else:
 # Dead code follows :-'(
 word = world.generate_grunt(conceptN)
 database[concept] = word
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

Gregory Ewing wrote:

 Mario Figueiredo wrote:
 I couldn't think of a way to
 demonstrate that a class object does not participate in its own
 inheritance rules. Only instances of it can.
 
 I think I may see where your reasoning is going astray.
 You think that an instance inherits methods from its
 class in the same way that a subclass inherits methods
 from its base class.

In fairness, inherit is standard terminology for the way instances get
their behaviour from their class.

Also, you can override methods *on the instance*:


py class Parrot(object):
... def talk(self):
... print(Polly wants a cracker!)
...
py polly = Parrot()
py polly.talk()
Polly wants a cracker!
py from types import MethodType
py polly.talk = MethodType(
... lambda self: print(Polly wants a spam sandwich!), polly)
py polly.talk()
Polly wants a spam sandwich!



 But thinking of the instance-class relationship as
 an inheritance relationship is misleading. It's more
 accurate to say that a class *defines* the methods
 that its instances have. The class inherits methods
 from its base class, but those methods still apply to
 instances of the class, not the class itself.

I won't speak for other OOP models, but I don't think that is true in
Python. In Python, obj.talk performs the following (grossly simplified)
process:

* search the instance for an attribute talk
* search the class
* search all the base classes
* fail

(simplified because I have ignored the roles of __getattr__ and
__getattribute__, of metaclasses, and the descriptor protocol)


That's more or less the same as what happens whether obj is a class object
or a non-class object. I don't know what attribute lookup *literally* uses
the exact same code for looking up attributes on an instance or a class,
but it wouldn't surprise me if it does.


 That doesn't mean the class itself can't be given
 methods, though. The methods of the class are defined
 by its metaclass, and the metaclass inherits methods
 from *its* base class, etc.


The normal way of giving a class methods that are callable from the class is
to define them on the class with the classmethod or staticmethod
decorators. Using a metaclass is usually overkill :-)



 Here's a diagram:
 
 +--+  ++
 | type |  | base class |
 +--+  ++
 ^   ^
 | subclass of   | subclass of
 |   |
 +---+  +---+  +--+
 | metaclass |-| class |-| instance |
 +---+  instance of +---+  instance of +--+
 
 It should be clear from this that the relationship
 between an instance and its class is exactly the same
 as that between a class and its metaclass, including
 inheritance relationships.
 
 The diagram can be extended indefinitely far to the
 left -- the metaclass could be an instance of a
 meta-metaclass, etc. (Although there's an old standing
 joke in the Python world that metaclasses make your
 head explode, so I hate to think what a meta-metaclass
 would do -- probably take out a whole floor of the
 office building you work in. Meta-meta-metaclasses are
 right out.)

An early essay on Python metaclasses was subtitled The Killer-Joke. 




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

Ben Finney wrote:

 Ned Batchelder n...@nedbatchelder.com writes:
 
 On 1/27/15 3:12 PM, Mario Figueiredo wrote:
  This is a follow up from a previous discussion in which it is argued
  that the following code produces the correct error message terminology,
  considering that in Python an object is also an instance.

 I don't know what the difference is between object and instance.
 An object is an instance of a class.  The two words are
 interchangeable as far as I know.
 
 Not in English grammar, IMO. To say “foo is an instance” implies the
 sentence isn't finished; the term “instance” only makes sense in the
 context of a relationship to some class. To say “foo is an object”
 doesn't have that implication.

I'm sure that there is a grammatical term for this, but I don't know it. 
Regardless of the terminology though, foo is an instance is a complete 
sentence fragment:

foo is an instance (of some unspecified class)

is the same grammatical construct as:

George is a soldier (of some unspecified army)
Pluto is a cartoon animal (of some unspecified species)
Bearhugger's Old Peculiar is a drink (of some unspecified type)
Herbie is a car (of some unspecified make and model)

etc. In Java, the term object as a synonym for instance is unambiguous, 
because in Java all classes are subclasses of Object, and no classes are 
themselves instances of a class. But that's not the case with Python.


 A common mistake is to believe that OOP is a well-defined term.
 It's not it's a collection of ideas that are expressed slightly
 differently in each language.
 
 Right. The common meaning of “object” shared by all OOP systems is
 surprisingly small.

Agreed. There really is no widespread agreement on what OOP means 
*precisely*. Wikipedia states:

Attempts to find a consensus definition or theory behind objects have not 
proven very successful and there is little agreement of the fundamental 
features of OOP:

http://en.wikipedia.org/wiki/Object-
oriented_programming#Fundamental_features_and_concepts


[...] 
 In Python, every class is an object. Every class has the full range of
 behaviour that we expect of objects. A class just has the additional
 feature that it can be instantiated.

We can also define an is-a relationship between classes and their 
instances:

[1, 2, spam] is-a list;

but not list is-a [1, 2, spam]


However, in Python that breaks down at the very bottom of the inheritance 
hierarchy, thanks to the circular relationship between type and object:

py isinstance(type, object)
True
py isinstance(object, type)
True

type is-a object
object is-a type



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

random...@fastmail.us wrote:

 I think his objection is to the use of the phrase 'Sub' object to
 refer only to instances of the Sub type, when 'Sub' is the name of the
 type object itself and therefore (he thinks) 'Sub' object should refer
 to it instead. (I can only assume he wants 'x' object for x = Sub().)


Yes, that's exactly what Mario asked for in the original thread that started 
this. Sadly Python cannot do this.

But the docs could consistently use class or type to refer to classes 
and types (in Python 3, they are the same thing), and instance to refer to 
instances which are not classes, and object to refer to both.

And then I would be sooo happyy :-)


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

Ben Finney wrote:

 * In the distant past of Python, some objects were not instances of any
 class; the terminology in the documentation and messages shows some
 confusing legacies from that ancient time.


I presume you are referring to the type/class distinction?

That is, in Python 1.5 (for example), the *instance* 23 was an instance of 
the *type* int but not of any class, as classes (created with the class 
keyword) were distinct from types.

If you mean something else, can you explain please?


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

Ned Batchelder wrote:

 Do you have a reference that defines these terms?

*A* reference is not sufficient. It has to be a reference which all other 
references agree with.

I'll be kind, and lower the requirement to one where *the majority* of other 
references agree. The OP still won't find one :-)

Or perhaps that should be a sad face smiley :-( How much time we would all 
save if academics and language designers would only stick to a single 
consistent terminology across all languages.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

random...@fastmail.us wrote:

 On Tue, Jan 27, 2015, at 16:06, Mario Figueiredo wrote:
 That error message has me start that thread arguing that the error is
 misleading because the Sub object does have the __bases__ attribute.
 It's the Sub instance object that does not have it.
 
 What do you think Sub object means?

I think it means the Sub class, which is an object. And Python 3.3 agrees 
with me:

py class Sub(object):
... pass
... 
py isinstance(Sub, object)
True

Sub is also an instance of type. And object is an instance of type, type is 
an instance of object, and type is a subclass of object. But object is not a 
subclass of type. However it is an instance of type. Are we confused yet?

There is a sense, taken from Java in particular, that object is synonymous 
for instance. For example, Oracle's documentation for classes says:

A class contains constructors that are invoked to create objects from the 
class blueprint.

http://docs.oracle.com/javase/tutorial/java/javaOO/constructors.html

But you won't find any Java documentation referring to the class itself as 
an object. Java has no metaclasses, classes are not instances of a 
metaclass, and so classes are never instances. Classes are classes, objects 
are instances of a class, and that is all there is to it.

But in Python, object and instance are more ambiguous, thanks to 
metaclasses. Instances of a metaclass are classes, hence classes are 
instances as well as classes:

py isinstance(Sub, type)
True

Sub is an instance of the class type. And because classes themselves are 
first-class (ha ha!) values, like ints, strings, lists etc., classes are 
objects.

All classes (in Python 3) are instances of a class (the metaclass), but not 
all instances are classes.

Obviously this is rather confusing, but fortunately metaclasses (other than 
type itself) are rare, so *most of the time* we can get away with Java-like 
terminology, and pretend that classes are distinct from instances rather 
than being just another kind of instance (of the metaclass).

But what we cannot do is pretend that object means instance, because all 
classes are objects. Alas, habits from other languages leak in, and the 
Javaesque terminology Foo object meaning an instance of Foo sometimes gets 
used, even though Foo object should refer to the object called Foo, namely 
the class object itself.

The unfortunate ambiguity is that sometimes Foo object gets used to mean 
Foo, and other times it gets used to me some instance of Foo. We say:

the None object has no state

and

the function requires an int object as argument.



 Sub itself is not a Sub object,

Sub itself is not *a* Sub object, it is *the* Sub object, just as 42 is 
*the* object with type int and value forty-two.


 it is a type object. instance is
 implicit in the phrase foo object.

Alas, classes *are* instances, of their metaclass, so Sub object could 
refer to an instance of Sub (using the Javaesque terminology) or Sub itself 
(using more Pythonistic terminology).



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

random...@fastmail.us wrote:

 On Wed, Jan 28, 2015, at 00:43, Devin Jeanpierre wrote:
 On Tue, Jan 27, 2015 at 9:37 PM,  random...@fastmail.us wrote:
  Sub itself is not a Sub object, it is a type object. instance is
  implicit in the phrase foo object.
 
 Yes. Unfortunately, it's still not really completely clear. Sub
 instance would avoid this confusion for everyone.
 
 It really is completely clear. Nobody is confused but you.

Ironically, your denial of a pretty clear case of ambiguity demonstrates 
that if anyone is confused, it is you.

In an earlier thread, Mario demonstrated an obvious example of confusing 
error message due to the object/instance ambiguity, where the error message 
states that Sub doesn't have a method when it actually does. It is an 
*instance of Sub*, not the Sub object itself, which lacks the method.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

Mario Figueiredo wrote:

 In other words, the object know as Sub class is not an instance
 object. True, it is an instance of the object 'type'.


Can you not see the contradiction there?

The object known as 42 is not an instance object. True, it is an instance of 
the object int.

Er, then surely that means that 42 *is* an instance object?

I agree that in *common situations*, it is useful to pretend that Python is 
like Java, and draw a distinction between classes and instances. I don't 
think it is useful to deny that classes are instances.

The discussion depends on context, in the same way that depending on context 
sometimes it is useful to include Homo sapiens in the group Animals and 
sometimes not:

Sit up straight and stop eating like an animal!

Like all animals, human beings rely on the environment for their survival.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

Mario Figueiredo wrote:

 In article mailman.18191.1422400930.18130.python-l...@python.org,
 n...@nedbatchelder.com says...
 
 A common mistake is to believe that OOP is a well-defined term.  It's
 not it's a collection of ideas that are expressed slightly differently
 in each language.
 
 A common mistake is thinking just because OOP has different
 implementations, it doesn't have a cohesive set of well described rules
 and its own well defined terminology.

Alas, this is not a mistake. As I posted in a reply to Ben, OOP does not 
have a cohesive set of rules and well-defined terminology.


 I don't know what a not fully realized object is.
 
 A fully realized object, in an object oriented paradigm, is an object
 containing or pointing to data and the methods to act on that data. It's
 an instance of a class.

In Python, classes meet that definition too. A class in Python is a value 
which can contain data (or point to data), and it has methods which act on 
that data. Classes in Python themselves have a class, which we call the 
metaclass, and classes inherit behaviour from their class just as integer 
instances inherit behaviour from their class, int.


 A *not* fully realized object is possible in Python, since Classes are
 first-class objects, despite not being able to participate in OOP.
 
 
 What does participate in OOP mean?
 
 Means the object is capable of participating in inheritance and/or
 polymorphism. An instance of an object is capable of doing so, per its
 class definitions. Whereas a Python class object is not.

Class objects are capable of participating in inheritance. A class can have 
multiple metaclasses. They can even have multiple inheritance of 
metaclasses.

I'm not sure what relevance polymorphism has.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Chris Angelico]

On Wed, Jan 28, 2015 at 8:16 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 Or perhaps that should be a sad face smiley :-( How much time we would all
 save if academics and language designers would only stick to a single
 consistent terminology across all languages.

That's like wishing that every human spoke the same language, instead
of having English, French, Italian, Polish, Serbian, Korean, and a
host of others. The problem isn't the languages; the variety of
languages reflects a variety of concepts being communicated, and to
unify the languages spoken would entail dispensing with that variety.

The terminology isn't consistent because there are myriad variations
between the concepts. Is it useful to talk about multiple
inheritance as a concept? I believe I've yet to meet two distinct
languages that have identical MI semantics. Does each language need
its own word for that term so we don't have any sort of
inconsistencies? Or do all languages have to implement the exact same
functionality?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Gregory Ewing]

Mario Figueiredo wrote:
I couldn't think of a way to 
demonstrate that a class object does not participate in its own 
inheritance rules. Only instances of it can.


I think I may see where your reasoning is going astray.
You think that an instance inherits methods from its
class in the same way that a subclass inherits methods
from its base class.

But thinking of the instance-class relationship as
an inheritance relationship is misleading. It's more
accurate to say that a class *defines* the methods
that its instances have. The class inherits methods
from its base class, but those methods still apply to
instances of the class, not the class itself.

That doesn't mean the class itself can't be given
methods, though. The methods of the class are defined
by its metaclass, and the metaclass inherits methods
from *its* base class, etc.

Here's a diagram:

+--+  ++
| type |  | base class |
+--+  ++
   ^   ^
   | subclass of   | subclass of
   |   |
+---+  +---+  +--+
| metaclass |-| class |-| instance |
+---+  instance of +---+  instance of +--+

It should be clear from this that the relationship
between an instance and its class is exactly the same
as that between a class and its metaclass, including
inheritance relationships.

The diagram can be extended indefinitely far to the
left -- the metaclass could be an instance of a
meta-metaclass, etc. (Although there's an old standing
joke in the Python world that metaclasses make your
head explode, so I hate to think what a meta-metaclass
would do -- probably take out a whole floor of the
office building you work in. Meta-meta-metaclasses are
right out.)

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ben Finney]

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:

 Ben Finney wrote:

  * In the distant past of Python, some objects were not instances of any
  class; the terminology in the documentation and messages shows some
  confusing legacies from that ancient time.


 I presume you are referring to the type/class distinction?

 That is, in Python 1.5 (for example), the *instance* 23 was an
 instance of the *type* int but not of any class, as classes (created
 with the class keyword) were distinct from types.

That's what I was referring to, yes.

All ancient history now. In all current versions of Python, every type
is a class and every class is a type, and every type is an object and
every class is an object, and every object is an instance of a class and
is an instance of a type (and you are me and all are we together).

-- 
 \  “I like to reminisce with people I don't know. Granted, it |
  `\ takes longer.” —Steven Wright |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article mailman.18203.1422424695.18130.python-l...@python.org, 
breamore...@yahoo.co.uk says...
 
 The thing that bothers me is that many people, some of them with maybe 
 20 years of Python experience, have repeatedly stated Python concepts 
 with respect to the terms class, instance and object.  Instead of 
 accepting their knowledge of the language and gracefully stepping back, 
 you've carried on until the twist of knots would make any boy scout proud.

Condescending much?

I'm not one to lower to arguments from authority. Sorry. Never have, 
never will. Neither I adopt such attitude on those programming languages 
in which I am myself an authoritative source. I respect knowledge as 
anyone else. But I also specifically asked for arguments that could show 
me the Python way. I have a desire to understand. It's not just a matter 
of accepting the word of someone who is more experienced than me. That 
does not do any good to anyone. I'm not trying to change anything, 
neither I'm a OOP fanatic like some tried to accuse me. I'm just trying 
to understand. Do *you* understand that?

I may have sounded ignorant to you. It's something I cannot avoid, 
because while I try to argue this issue, I do it from the position of 
someone who is still learning the Python language syntax and semantics. 
But I'm much more than what you may think. And I would like to be 
treated with a little more respect. Like you I'm a software developer 
and, probably like you, I have decades of software development as a 
profession on my back.

But some of the arguments in here (and yours too) have done very little 
to help me understand the language semantics on this particular issue. 
Purportedly, or perhaps innocently due to my clumsiness, some folks in 
here argue with little more than but a class object is an instance of 
'type'. They choose to ignore that class objects are clearly a special 
type of object unlike the instances they help define. Like in so many 
debates, there's unfortunately always a desire to ignore or avoid other 
side that is arguing with us.

Thankfully, I am now starting to understand the semantics. Folks like 
Ben, Steven or Ian (apologies to a couple others I am missing. Can't 
remember your names and having an hard time looking through past posts) 
have helped tremendously by leaving smugness aside, adopting an 
educational attitude towards a clearly confused person, and -- I would 
wager -- understanding that I'm asking questions, not trying to set new 
ways.

Don't feel so bothered by my person, sir. Just ignore me if that makes 
you feel better.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Gregory Ewing]

Mario Figueiredo wrote:
An instance of an object is capable of doing so, per its 
class definitions. Whereas a Python class object is not.


 class Master:
def func(self):
pass

 class Sub(Master):
pass

 Sub.func()
TypeError: func() missing 1 required positional argument: 'self'


But Sub is not an *instance* of Master here, it's
a *subclass* of Master, which is quite a different
thing:

 Sub.__class__
class 'type'

To make Sub be an *instance* of Master, you need to
do this. (NOTE: This is Python 3 syntax; the same
thing can be done in Python 2, but the syntax is
slightly different.)

 class Master(type):
...  def func(self):
...   print(func of, self, called)
...
 class Sub(metaclass = Master):
...  pass
...
 Sub.__class__
class '__main__.Master'
 Sub.func()
func of class '__main__.Sub' called

So, you see, Python classes *can* participate in OOP
just as fully as any other object. You just need to
know how to do it correctly.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[random832]

On Wed, Jan 28, 2015, at 01:59, Ben Finney wrote:
 You have no justification to claim that, and it's hostile and dismissive
 to claim it so assertively.

Sorry about that - I was tired and had just read through the whole
thread at once.

 I'll freely admit to finding “'Foo' object” ambiguous. It can reasonably
 be interpreted to mean either “a 'Foo' object” (⇒ “an object of class
 'Foo'”), or “the 'Foo' object” (⇒ “the object referred to by the name
 'Foo'”). The error message which inspired this thread needs improvement,
 as I've said already.

Most objects do not have an idea of their name, though. Assigning an
object to a new name doesn't change the object, either.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 10:39:34 PM UTC+5:30, rand...@fastmail.us 
wrote:
 On Wed, Jan 28, 2015, at 01:59, Ben Finney wrote:
  You have no justification to claim that, and it's hostile and dismissive
  to claim it so assertively.
 
 Sorry about that - I was tired and had just read through the whole
 thread at once.

Heh Sweet!
The lost art of gracefully saying sorry
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Gregory Ewing]

Steven D'Aprano wrote:


In fairness, inherit is standard terminology for the way instances get
their behaviour from their class.


I'm not sure that's true, but even if it is, it's
not the same kind of inheritance relationship as
exists between a class and a base class, which was
my point.


Also, you can override methods *on the instance*:


I wouldn't call that a method -- it's just an instance
attribute that happens to be a function. You can tell
it's not a method because it doesn't get a 'self' argument.


In Python, obj.talk performs the following (grossly simplified)
process:

* search the instance for an attribute talk
* search the class
* search all the base classes
* fail

(simplified because I have ignored the roles of __getattr__ and
__getattribute__, of metaclasses, and the descriptor protocol)


By ignoring the descriptor protocol, you're simplifying
away something very important. It's the main thing that
makes the instance-of relation different from the
subclass-of relation.


The normal way of giving a class methods that are callable from the class is
to define them on the class with the classmethod or staticmethod
decorators. Using a metaclass is usually overkill :-)


True, but I was trying to illustrate the symmetry
between classes and instances, how the classic OOP
ideas of Smalltalk et al are manifest in Python,
and to show that classes *can* participate fully
in OOP just like any other objects if you want them
to. Python's class methods are strange beasts that
don't have an equivalent in the classic OOP model,
so they would only have confused matters.

And there are cases where you *do* need a metaclass,
such as giving a __dunder__ method to a class, so it's
useful to know how to do it just in case.


An early essay on Python metaclasses was subtitled The Killer-Joke.


Quick, translate this post into German before anyone
sees too much of it!

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Steven D'Aprano]

Gregory Ewing wrote:

 Steven D'Aprano wrote:
 
 In fairness, inherit is standard terminology for the way instances get
 their behaviour from their class.
 
 I'm not sure that's true, but even if it is, it's
 not the same kind of inheritance relationship as
 exists between a class and a base class, which was
 my point.

I suspect that in Python it actually is, but I don't understand the 
implementation of attribute look-ups well enough to be sure.


 Also, you can override methods *on the instance*:
 
 I wouldn't call that a method -- it's just an instance
 attribute that happens to be a function. You can tell
 it's not a method because it doesn't get a 'self' argument.

Actually, if you look at my example, you will see that it is a method and it 
does get the self argument. Here is the critical code again:

from types import MethodType
polly.talk = MethodType(
lambda self: print(Polly wants a spam sandwich!), polly)


The MethodType constructor takes a function and an instance, and returns a 
method bound to that instance.


 In Python, obj.talk performs the following (grossly simplified)
 process:
 
 * search the instance for an attribute talk
 * search the class
 * search all the base classes
 * fail
 
 (simplified because I have ignored the roles of __getattr__ and
 __getattribute__, of metaclasses, and the descriptor protocol)
 
 By ignoring the descriptor protocol, you're simplifying
 away something very important. It's the main thing that
 makes the instance-of relation different from the
 subclass-of relation.

That's certainly not correct, because Python had classes and instances 
before it had descriptors! Classes and instances go back to pre-1.5 days, 
while descriptors were only introduced in 2.2. Besides, descriptors are 
handled by the metaclass, so we could write a metaclass that doesn't handle 
them.


 The normal way of giving a class methods that are callable from the class
 is to define them on the class with the classmethod or staticmethod
 decorators. Using a metaclass is usually overkill :-)
 
 True, but I was trying to illustrate the symmetry
 between classes and instances, how the classic OOP
 ideas of Smalltalk et al are manifest in Python,
 and to show that classes *can* participate fully
 in OOP just like any other objects if you want them
 to. Python's class methods are strange beasts that
 don't have an equivalent in the classic OOP model,
 so they would only have confused matters.

Fair point about classmethods.

I think you're actually underestimating how close the symmetry between new-
style classes and instances actually is in Python.


 And there are cases where you *do* need a metaclass,
 such as giving a __dunder__ method to a class, so it's
 useful to know how to do it just in case.

I don't understand this. I write dunder methods all the time. Ah wait, I 
think I've got it. If you want (say) your class object itself to support 
(say) the + operator, it isn't enough to write a __add__ method on the 
class, you have to write it on the metaclass.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

An object is an instance (or not)?

[Mario Figueiredo]

This is a follow up from a previous discussion in which it is argued 
that the following code produces the correct error message terminology, 
considering that in Python an object is also an instance.

 class Sub:
 pass

 foo = Sub()
 foo.__bases__
[...]
AttributeError: 'Sub' object has no attribute '__bases__'

I'm making this into a new thread, because the particular discussion of 
whether an object is an instance in Python seems more interesting than 
discussing whether that error message should be changed or not.

Here's another example where the terminology keeps indicating that in 
Python an object is an instance:

 class Sub:
pass

 x = Sub()
 x
__main__.Sub object at 0x02631690

The problem is that I personally cannot agree with this terminology and 
I would like to hear arguments that could convince me to adopt the 
Python way. But before your replies, here's my argumentation:

An instance IS an object. On that we can agree. After all, everything in 
Python is an object. Even classes are. We can even pass them as function 
arguments:

 class Sub:
pass

 def show(aClass):
print(type(aClass))

 show(Sub)
class 'type'

The problem is that an object isn't always an instance. The word 
instance in OOP has a very formal meaning. In programming languages in 
which the classes aren't fully realized objects, it is ok to speak of 
'instance' and 'object' interchangeably. But even then, sometimes the 
term 'object instance' is preferred, as a way to separate these 
'instances' from other variable instances that may not be created from 
class definitions (e.g. C++ built-in types).

The fact that in Python classes are objects, should not just eliminate 
this distinction. The OOP terminology should exist beyond the language 
implementing it. It facilitates discourse and helps transmiting concepts 
when describing your ideas to another programmer. And because in python, 
classes are of the type 'type' and they exist as fully realized objects, 
is no excuse to make a distinction between them and their own fully 
realized instances. The language implementation details should not exist 
as a way for us to freely reformulate long standing terms.

Because, from my own study of Python, I've came to realize that the 
distinction between objects and instances of objects actually exists. In 
Python, class objects cannot participate in OOP, only their instances. 
This is why I say that even in Python, where a class is an object, an 
object is not always an instance. The language itself forces that 
distinction.

...

I don't think that any of this is reason enough to rewrite error 
messages in Python. Seems unnecessary. What I'm arguing thought is that 
error messages in Python cannot become the source of new terminology. 
The language itself implements a very clear distinction between class 
objects and their instances. And it is thus wrong of us to say that 
Object = Instance. At least from an OOP perspective.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article 9a2cf6ca-2eb8-4a87-9e83-e87d90d5f...@googlegroups.com, 
andre.robe...@gmail.com says...
 
 **This is a follow up from a previous discussion in which it is argued 
 that the following code produces the correct error message terminology **
 
 I pointed out to you that the word object WAS used correctly: hence, the 
 correct terminology was used in that error message.
 
 You are just wasting people's time.

That is just rude!

I'm still trying to understand what is the problem you are having with 
my post. Have you followed the previous thread? Is there anything you 
are not understanding?

People were saying to me that in Python object = instance. I'm trying to 
argue why I believe it isn't and asking for arguments to convince me 
otherwise.

And that's the best you can do?

Python does imply that an object is an instance, btw. It is why I got 
that answer from more than one person. Or so they say.

By referring to an instance of Sub as Sub object, there's an implicit 
affirmation that an object is an instance.

Bye.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article a771f6f2-9aa3-44ca-9f87-88a984c7c...@googlegroups.com, 
andre.robe...@gmail.com says...
 
 It is appropriate to refer to an instance as an object.  It might not 
 be appropriate to refer to an object as an instance ... but Python
 does not do so as your explicit examples demonstrate, and contrary to 
 your claim.

I'll try one more time: It - Is - Not - My - Claim.

It is the claim of a few users in here that replied to that thread.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[André Roberge]

On Tuesday, 27 January 2015 17:43:38 UTC-4, Mario Figueiredo  wrote:
 In article a771f6f2-9aa3-44ca-9f87-88a984c7c...@googlegroups.com, 
 andre.robe...@gmail.com says...
  
  It is appropriate to refer to an instance as an object.  It might not 
  be appropriate to refer to an object as an instance ... but Python
  does not do so as your explicit examples demonstrate, and contrary to 
  your claim.
 
 I'll try one more time: It - Is - Not - My - Claim.
 
 It is the claim of a few users in here that replied to that thread.

At the very beginning of the first message I replied to, you wrote:

**This is a follow up from a previous discussion in which it is argued 
that the following code produces the correct error message terminology **

I pointed out to you that the word object WAS used correctly: hence, the 
correct terminology was used in that error message.

You are just wasting people's time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article 80a9f882-6b13-45a7-b514-8c47b3a4c...@googlegroups.com, 
andre.robe...@gmail.com says...
 
 You keep writing an object is not an instance, making statements
 such as the terminology keeps indicating that in Python an object is 
 an instance and yet, none of the examples you show from Python
 (tracebacks or repr outputs) include the word instance.   

I think you misread my argument. Look at the first example on my post, 
or follow the discussion on __bases__ misleading error message here on 
the newsgroups.

That error message has me start that thread arguing that the error is 
misleading because the Sub object does have the __bases__ attribute. 
It's the Sub instance object that does not have it.

Some of the answers that were given argued that in Python object = 
instance.

 Yet
 **you** claim that Python states that objects are instances 

That is no my claim. I said that much. You should probably read my post 
more carefully.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[André Roberge]

On Tuesday, 27 January 2015 16:12:47 UTC-4, Mario Figueiredo  wrote:
 This is a follow up from a previous discussion in which it is argued 
 that the following code produces the correct error message terminology, 
 considering that in Python an object is also an instance.
 
  class Sub:
  pass
 
  foo = Sub()
  foo.__bases__
 [...]
 AttributeError: 'Sub' object has no attribute '__bases__'
 
 I'm making this into a new thread, because the particular discussion of 
 whether an object is an instance in Python seems more interesting than 
 discussing whether that error message should be changed or not.
 
 Here's another example where the terminology keeps indicating that in 
 Python an object is an instance:
 
  class Sub:
   pass
 
  x = Sub()
  x
 __main__.Sub object at 0x02631690
 
 The problem is that I personally cannot agree with this terminology and 
 I would like to hear arguments that could convince me to adopt the 
 Python way. But before your replies, here's my argumentation:
 
 An instance IS an object. On that we can agree. After all, everything in 
 Python is an object. Even classes are. We can even pass them as function 
 arguments:
 
  class Sub:
   pass
 
  def show(aClass):
   print(type(aClass))
   
  show(Sub)
 class 'type'
 
 The problem is that an object isn't always an instance. The word 
 instance in OOP has a very formal meaning. In programming languages in 
 which the classes aren't fully realized objects, it is ok to speak of 
 'instance' and 'object' interchangeably. But even then, sometimes the 
 term 'object instance' is preferred, as a way to separate these 
 'instances' from other variable instances that may not be created from 
 class definitions (e.g. C++ built-in types).
 
 The fact that in Python classes are objects, should not just eliminate 
 this distinction. The OOP terminology should exist beyond the language 
 implementing it. It facilitates discourse and helps transmiting concepts 
 when describing your ideas to another programmer. And because in python, 
 classes are of the type 'type' and they exist as fully realized objects, 
 is no excuse to make a distinction between them and their own fully 
 realized instances. The language implementation details should not exist 
 as a way for us to freely reformulate long standing terms.
 
 Because, from my own study of Python, I've came to realize that the 
 distinction between objects and instances of objects actually exists. In 
 Python, class objects cannot participate in OOP, only their instances. 
 This is why I say that even in Python, where a class is an object, an 
 object is not always an instance. The language itself forces that 
 distinction.
 
 ...
 
 I don't think that any of this is reason enough to rewrite error 
 messages in Python. Seems unnecessary. What I'm arguing thought is that 
 error messages in Python cannot become the source of new terminology. 
 The language itself implements a very clear distinction between class 
 objects and their instances. And it is thus wrong of us to say that 
 Object = Instance. At least from an OOP perspective.

You keep writing an object is not an instance, making statements such as the 
terminology keeps indicating that in Python an object is an instance and yet, 
none of the examples you show from Python (tracebacks or repr outputs) include 
the word instance.   

To phrase it differently: all the examples of output from Python that you show 
use the word object and not the word instance.  Yet **you** claim that 
Python states that objects are instances Can you point out at least 
one example where Python wrongly use the word instance instead of object?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[André Roberge]

On Tuesday, 27 January 2015 17:06:50 UTC-4, Mario Figueiredo  wrote:
 In article 80a9f882-6b13-45a7-b514-8c47b3a4c...@googlegroups.com, 
 andre.robe...@gmail.com says...
  
  You keep writing an object is not an instance, making statements
  such as the terminology keeps indicating that in Python an object is 
  an instance and yet, none of the examples you show from Python
  (tracebacks or repr outputs) include the word instance.   
 
 I think you misread my argument. Look at the first example on my post, 
 or follow the discussion on __bases__ misleading error message here on 
 the newsgroups.


 
 That error message has me start that thread arguing that the error is 
 misleading because the Sub object does have the __bases__ attribute. 
 It's the Sub instance object that does not have it.
 

To use the word object to describe an instance is perfectly appropriate. Your 
claims imply the the opposite is happening.

 Some of the answers that were given argued that in Python object = 
 instance.
 
  Yet
  **you** claim that Python states that objects are instances 
 
 That is no my claim. I said that much. You should probably read my post 
 more carefully.

I read your post carefully: not once did I see an output from Python using the 
word instance.


From your post:

 Python's output ==
AttributeError: 'Sub' object has no attribute '__bases__' 
=
Python uses the word object, not instance.



++ your words +++

Here's another example where the terminology keeps indicating that in 
Python an object is an instance: 
++

==Python's output ===
__main__.Sub object at 0x02631690 
===
Python uses the word object, not instance, contrary to what you wrote.



+++ your words ++

The problem is that an object isn't always an instance. 
+


 your words 

What I'm arguing thought is that 
error messages in Python cannot become the source of new terminology. 


Not a single output from Python uses the word instance.

It is appropriate to refer to an instance as an object.  It might not be 
appropriate to refer to an object as an instance ... but Python does not do so 
as your explicit examples demonstrate, and contrary to your claim.

A.R.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ethan Furman]

On 01/27/2015 12:12 PM, Mario Figueiredo wrote:

 Because, from my own study of Python, I've came to realize that the 
 distinction between objects and instances of objects actually exists. In 
 Python, class objects cannot participate in OOP, only their instances. 

I haven't followed the other thread.  Can you give an example of this?  Because 
I have a counter-example ready:  the new
Enum data type, which uses a metaclass to treat the class just like any other 
instance of a normal class:

  list(MyEnum)  # fails on a regular class

  for enum in MyEnum: # fails on a regular class

  MyEnum['EnumName']  # fails on a regular class

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mark Lawrence]

On 27/01/2015 21:58, Mario Figueiredo wrote:

In article 9a2cf6ca-2eb8-4a87-9e83-e87d90d5f...@googlegroups.com,
andre.robe...@gmail.com says...


**This is a follow up from a previous discussion in which it is argued
that the following code produces the correct error message terminology **

I pointed out to you that the word object WAS used correctly: hence, the 
correct terminology was used in that error message.

You are just wasting people's time.


That is just rude!

I'm still trying to understand what is the problem you are having with
my post. Have you followed the previous thread? Is there anything you
are not understanding?

People were saying to me that in Python object = instance. I'm trying to
argue why I believe it isn't and asking for arguments to convince me
otherwise.

And that's the best you can do?

Python does imply that an object is an instance, btw. It is why I got
that answer from more than one person. Or so they say.

By referring to an instance of Sub as Sub object, there's an implicit
affirmation that an object is an instance.

Bye.



Mario and Andre, when you have to write code to meet the deadline to get 
the stage payment, does either of your bosses really care whether or not 
you are dealing with an object, an instance, or a piece of dead meat 
dropped by the neighbour's cat?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article mailman.18193.1422402146.18130.python-l...@python.org, 
ros...@gmail.com says...
 
 On Wed, Jan 28, 2015 at 10:22 AM, Ned Batchelder n...@nedbatchelder.com 
 wrote:
  I don't know what the difference is between object and instance.  An
  object is an instance of a class.  The two words are interchangeable as far
  as I know.
 
 My understanding is that instance is meaningless unless followed by
 of. That is to say, 123.45 is an object, and it is an instance *of*
 the 'float' class. Everything in Python is an instance *of something*,
 so in a sense, you can say that everything is an instance, but that's
 like saying that everything has a color. Sure it does, but you need to
 be more specific.
 

In programming languages in which class definitions aren't first-class 
objects, the terms are in fact used interchangeably. And rightly so, 
because an object is in fact always an instance of some class.

Python and a few other languages implement class definitions as first-
class objects. In this case, the distinction between an object and an 
instance is actually an implementation detail and comes with its own 
semantics. This is why I object to the notion that in Python object = 
instance.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article mailman.18190.1422400358.18130.python-l...@python.org, 
breamore...@yahoo.co.uk says...
 
 Mario and Andre, when you have to write code to meet the deadline to get 
 the stage payment, does either of your bosses really care whether or not 
 you are dealing with an object, an instance, or a piece of dead meat 
 dropped by the neighbour's cat?

That is valuable input. You don't care how a type or an instance of a 
type differ. Should be intersting to ask you to make a Cat object. I 
wonder if you are not going to ask if they mean a class or an instance 
of that class.

Anyways, more to the point, this is simply a debate on language and how 
to express Python concepts. If that bothers you, I'll take note.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Chris Angelico]

On Wed, Jan 28, 2015 at 11:17 AM, Mario Figueiredo mar...@gmail.com wrote:
 Means the object is capable of participating in inheritance and/or
 polymorphism. An instance of an object is capable of doing so, per its
 class definitions. Whereas a Python class object is not.

  class Master:
 def func(self):
 pass

  class Sub(Master):
 pass

  Sub.func()
 TypeError: func() missing 1 required positional argument: 'self'

 But somehow I think you knew the answer to all these questions and were
 instead being snarky.

I have no idea what you're proving here. You just showed that the
class has a function attached to it, and you didn't provide enough
arguments to it. And types have their own set of attributes and
methods:

 dir(type)
['__abstractmethods__', '__base__', '__bases__', '__basicsize__',
'__call__', '__class__', '__delattr__', '__dict__', '__dictoffset__',
'__dir__', '__doc__', '__eq__', '__flags__', '__format__', '__ge__',
'__getattribute__', '__gt__', '__hash__', '__init__',
'__instancecheck__', '__itemsize__', '__le__', '__lt__', '__module__',
'__mro__', '__name__', '__ne__', '__new__', '__prepare__',
'__qualname__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__sizeof__', '__str__', '__subclasscheck__',
'__subclasses__', '__subclasshook__', '__text_signature__',
'__weakrefoffset__', 'mro']

Most of those are inherited from object, but some aren't.

What are you demonstrating?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article mailman.18191.1422400930.18130.python-l...@python.org, 
n...@nedbatchelder.com says...
 
 A common mistake is to believe that OOP is a well-defined term.  It's 
 not it's a collection of ideas that are expressed slightly differently 
 in each language.

A common mistake is thinking just because OOP has different 
implementations, it doesn't have a cohesive set of well described rules 
and its own well defined terminology.

 I don't know what a not fully realized object is.

A fully realized object, in an object oriented paradigm, is an object 
containing or pointing to data and the methods to act on that data. It's 
an instance of a class.

A *not* fully realized object is possible in Python, since Classes are 
first-class objects, despite not being able to participate in OOP.

 
 What does participate in OOP mean?

Means the object is capable of participating in inheritance and/or 
polymorphism. An instance of an object is capable of doing so, per its 
class definitions. Whereas a Python class object is not.

 class Master:
def func(self):
pass

 class Sub(Master):
pass

 Sub.func()
TypeError: func() missing 1 required positional argument: 'self'

But somehow I think you knew the answer to all these questions and were 
instead being snarky.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article mailman.18192.1422401989.18130.python-l...@python.org, 
ben+pyt...@benfinney.id.au says...
   This is why I say that even in Python, where a class is an object,
   an object is not always an instance. The language itself forces that
   distinction.
 
 You have not, to my knowledge, shown any object (in Python 2.2 or later)
 which is not an instance of some class. Python objects are always an
 instance of some specific class.

It is true that a class object is an instance of 'type'. But this is a 
special type (can't avoid the pun). A class object is not an instance of 
the type it implements. That is what I mean by an object that isn't an 
instance.

In other words, the object know as Sub class is not an instance 
object. True, it is an instance of the object 'type'.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Grant Edwards]

On 2015-01-27, Ned Batchelder n...@nedbatchelder.com wrote:
 On 1/27/15 3:12 PM, Mario Figueiredo wrote:
 This is a follow up from a previous discussion in which it is argued
 that the following code produces the correct error message terminology,
 considering that in Python an object is also an instance.

 I don't know what the difference is between object and instance.  An 
 object is an instance of a class.  The two words are interchangeable as 
 far as I know.

They are interchangable in recent versions of Python.

--
Grant
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ben Finney]

Mario Figueiredo mar...@gmail.com writes:

 It is true that a class object is an instance of 'type'. But this is a
 special type (can't avoid the pun).

Nevertheless it is a class, and can do everything that classes do.

And every class is an object, and can do everything that objects do.

You seem to agree with those, so please stop claiming that classes are
not objects. Python classes are always objects, and always have been.

 A class object is not an instance of the type it implements.

You keep introducing hurdles that are irrelevant. Yes, a class is not an
instance of itself. That doesn't impact the fact a class is an object.

 That is what I mean by an object that isn't an instance.

That's incoherent. It's an instance of a class, and simultaneously is
not an instance?

 In other words, the object know as Sub class is not an instance 
 object. True, it is an instance of the object 'type'.

You've tied yourself in knots with concepts that are not coherent, and
even if they were do not appear to be relevant to Python.

-- 
 \  “Very few things happen at the right time, and the rest do not |
  `\ happen at all. The conscientious historian will correct these |
_o__)  defects.” —Mark Twain, _A Horse's Tale_ |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article mailman.18196.1422406856.18130.python-l...@python.org, 
ben+pyt...@benfinney.id.au says...
 
 Mario Figueiredo mar...@gmail.com writes:
 
  It is true that a class object is an instance of 'type'. But this is a
  special type (can't avoid the pun).
 
 Nevertheless it is a class, and can do everything that classes do.
 
 And every class is an object, and can do everything that objects do.
 
 You seem to agree with those, so please stop claiming that classes are
 not objects. Python classes are always objects, and always have been.
 
  A class object is not an instance of the type it implements.
 
 You keep introducing hurdles that are irrelevant. Yes, a class is not an
 instance of itself. That doesn't impact the fact a class is an object.
 
  That is what I mean by an object that isn't an instance.
 
 That's incoherent. It's an instance of a class, and simultaneously is
 not an instance?
 
  In other words, the object know as Sub class is not an instance 
  object. True, it is an instance of the object 'type'.
 
 You've tied yourself in knots with concepts that are not coherent, and
 even if they were do not appear to be relevant to Python.

Very well. I'm failing at putting my point across. I will not discuss 
this further.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mario Figueiredo]

In article mailman.18195.1422405040.18130.python-l...@python.org, 
ros...@gmail.com says...
 
 On Wed, Jan 28, 2015 at 11:17 AM, Mario Figueiredo mar...@gmail.com wrote:
  Means the object is capable of participating in inheritance and/or
  polymorphism. An instance of an object is capable of doing so, per its
  class definitions. Whereas a Python class object is not.
 
   class Master:
  def func(self):
  pass
 
   class Sub(Master):
  pass
 
   Sub.func()
  TypeError: func() missing 1 required positional argument: 'self'
 
 I have no idea what you're proving here. You just showed that the
 class has a function attached to it, and you didn't provide enough
 arguments to it. And types have their own set of attributes and
 methods:
 

I admit it was a contrived example. I couldn't think of a way to 
demonstrate that a class object does not participate in its own 
inheritance rules. Only instances of it can.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Chris Angelico]

On Wed, Jan 28, 2015 at 10:22 AM, Ned Batchelder n...@nedbatchelder.com wrote:
 I don't know what the difference is between object and instance.  An
 object is an instance of a class.  The two words are interchangeable as far
 as I know.

My understanding is that instance is meaningless unless followed by
of. That is to say, 123.45 is an object, and it is an instance *of*
the 'float' class. Everything in Python is an instance *of something*,
so in a sense, you can say that everything is an instance, but that's
like saying that everything has a color. Sure it does, but you need to
be more specific.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ben Finney]

Mario Figueiredo mar...@gmail.com writes:

 People were saying to me that in Python object = instance. I'm trying
 to argue why I believe it isn't and asking for arguments to convince
 me otherwise.

In Python:

* Every value is an object.

* Every object is an instance of some class.

* To say “object” is uproblematic for values in Python, because the
  programming term “object” doesn't imply anything about classes.

* To say “instance” implies a specific relationship to some particular
  class; in programming terminology (because in English generally) an
  instance is so called only because it is an instance of some specific
  class.

 By referring to an instance of Sub as Sub object, there's an
 implicit affirmation that an object is an instance.

Correct. That raises a fourth point:

* In the distant past of Python, some objects were not instances of any
  class; the terminology in the documentation and messages shows some
  confusing legacies from that ancient time.

The phrasing “'Foo' object” is ambiguous in a way that “'Foo' instance”
would not be. I agree with others that changing the message to refer to
“'Foo' instance” would be an improvement.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\Brain, but I find scratching just makes it worse.” —_Pinky and |
_o__)   The Brain_ |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ben Finney]

Ned Batchelder n...@nedbatchelder.com writes:

 On 1/27/15 3:12 PM, Mario Figueiredo wrote:
  This is a follow up from a previous discussion in which it is argued
  that the following code produces the correct error message terminology,
  considering that in Python an object is also an instance.

 I don't know what the difference is between object and instance.
 An object is an instance of a class.  The two words are
 interchangeable as far as I know.

Not in English grammar, IMO. To say “foo is an instance” implies the
sentence isn't finished; the term “instance” only makes sense in the
context of a relationship to some class. To say “foo is an object”
doesn't have that implication.

 A common mistake is to believe that OOP is a well-defined term.
 It's not it's a collection of ideas that are expressed slightly
 differently in each language.

Right. The common meaning of “object” shared by all OOP systems is
surprisingly small.

Many OOP systems do not use classes (e.g. JavaScript) and are no less
object-oriented for that. In such a system it would be true to say “foo
is an object, but is not an instance of anything”.

  Because, from my own study of Python, I've came to realize that the
  distinction between objects and instances of objects actually
  exists. In Python, class objects cannot participate in OOP, only
  their instances.

 What does participate in OOP mean?

To the extent I understand (and I'm confused on what that might mean as
you are), I think it's plainly false.

In Python, every class is an object. Every class has the full range of
behaviour that we expect of objects. A class just has the additional
feature that it can be instantiated.

  This is why I say that even in Python, where a class is an object,
  an object is not always an instance. The language itself forces that
  distinction.

You have not, to my knowledge, shown any object (in Python 2.2 or later)
which is not an instance of some class. Python objects are always an
instance of some specific class.

-- 
 \ “Books and opinions, no matter from whom they came, if they are |
  `\ in opposition to human rights, are nothing but dead letters.” |
_o__)  —Ernestine Rose |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ned Batchelder]

On 1/27/15 3:12 PM, Mario Figueiredo wrote:

This is a follow up from a previous discussion in which it is argued
that the following code produces the correct error message terminology,
considering that in Python an object is also an instance.


I don't know what the difference is between object and instance.  An 
object is an instance of a class.  The two words are interchangeable as 
far as I know.



An instance IS an object. On that we can agree. After all, everything in
Python is an object. Even classes are. We can even pass them as function
arguments:

  class Sub:
pass

  def show(aClass):
print(type(aClass))

  show(Sub)
 class 'type'

The problem is that an object isn't always an instance. The word
instance in OOP has a very formal meaning.


A common mistake is to believe that OOP is a well-defined term.  It's 
not it's a collection of ideas that are expressed slightly differently 
in each language.



In programming languages in
which the classes aren't fully realized objects, it is ok to speak of
'instance' and 'object' interchangeably.


I don't know what a not fully realized object is.


But even then, sometimes the
term 'object instance' is preferred, as a way to separate these
'instances' from other variable instances that may not be created from
class definitions (e.g. C++ built-in types).

The fact that in Python classes are objects, should not just eliminate
this distinction. The OOP terminology should exist beyond the language
implementing it. It facilitates discourse and helps transmiting concepts
when describing your ideas to another programmer. And because in python,
classes are of the type 'type' and they exist as fully realized objects,
is no excuse to make a distinction between them and their own fully
realized instances. The language implementation details should not exist
as a way for us to freely reformulate long standing terms.

Because, from my own study of Python, I've came to realize that the
distinction between objects and instances of objects actually exists. In
Python, class objects cannot participate in OOP, only their instances.


What does participate in OOP mean?


This is why I say that even in Python, where a class is an object, an
object is not always an instance. The language itself forces that
distinction.


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 7:55:12 AM UTC+5:30, Ned Batchelder wrote:
 On 1/27/15 7:17 PM, Mario Figueiredo wrote:
  Ned Batchelder says...
 
  A common mistake is to believe that OOP is a well-defined term.  It's
  not it's a collection of ideas that are expressed slightly differently
  in each language.
 
  A common mistake is thinking just because OOP has different
  implementations, it doesn't have a cohesive set of well described rules
  and its own well defined terminology.
 
 I know you think that it has well described rules and terminology.  But 
 take a look at this discussion, and maybe realize that the terms are not 
 as well-defined, or certainly not as widely accepted as you think.

I'd go a step or two further than that.

Here's a discussion almost isomorphic [including Ned's futile attempts at
inducing sanity] to this one from a few years ago
https://groups.google.com/d/msg/comp.lang.python/y6mnzDeEsRU/Wvpo4mJ-a2gJ
[And others by that same OP - Mark Janssen - zipher]¹

And there's the recent one (2 because of thread breaking) on
Comparisons and sorting of a numeric class

To me all these suggest that OOP as a philosophy pickles the brain.
And violently passionate adherence to the philosophy conduces to madness.

[Reminded of a quote I saw on the scheme mailing list:
OOP is the phlogiston theory of CS
]


¹ To those who suffer violent allergic reactions on seeing ...groups.google... 
the numbering of the official archive is so fluid that even
google (search engine!) is getting confused and pointing to broken links
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[alex23]

On 28/01/2015 10:35 AM, Mario Figueiredo wrote:

I admit it was a contrived example. I couldn't think of a way to
demonstrate that a class object does not participate in its own
inheritance rules. Only instances of it can.


A class object isn't an instance of itself, it's an instance of the 
Class (to be extact, 'type') class. Method dispatching will also 
traverse the base classes when refering to the class object, too:


 class Master:
... @classmethod
... def func(cls):
... return cls
...
 class Sub(Master):
... pass
...
 type(Sub)
class 'type'
 Sub.func()
class '__main__.Sub'



--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[alex23]

On 28/01/2015 10:24 AM, Mario Figueiredo wrote:

In other words, the object know as Sub class is not an instance
object. True, it is an instance of the object 'type'.


 class Foo:
... pass
...
 isinstance(Foo, type)
True
 isinstance(Foo, object)
True

A class is an object that is an instance of the class type. I'm still 
failing to see what distinction you're trying to make here.

--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Gregory Ewing]

Mario Figueiredo wrote:
That error message has me start that thread arguing that the error is 
misleading because the Sub object does have the __bases__ attribute. 
It's the Sub instance object that does not have it.


Some of the answers that were given argued that in Python object = 
instance.


No, they pointed out that *in that particular sentence* the
word object was being used in a way that's more or less
synonymous with instance.

But that doesn't mean the two words are perfectly
interchangeable in all English sentences. Sometimes one
is better than the other.

I prefer to use the word instance when I'm talking about
an instance *of* something, e.g. an instance of Foo or
a Foo instance. If I'm not mentioning a class, I just
use the word object.

So I would argue that Sub instance has no attribute...
is a marginally clearer way to word that message.

Which means, I think, that I'm more or less agreeing with
you, but *not* because of objects not always being instances
in Python. On the contrary, it's precisely because all
objects *are* instances that using the word instance
on its own in place of object is pointless -- it
doesn't convey any extra information.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ben Finney]

random...@fastmail.us writes:

 On Wed, Jan 28, 2015, at 00:43, Devin Jeanpierre wrote:
  On Tue, Jan 27, 2015 at 9:37 PM,  random...@fastmail.us wrote:
   Sub itself is not a Sub object, it is a type object. instance is
   implicit in the phrase foo object.
  
  Yes. Unfortunately, it's still not really completely clear. Sub
  instance would avoid this confusion for everyone.

 It really is completely clear. Nobody is confused but you.

You have no justification to claim that, and it's hostile and dismissive
to claim it so assertively.

I'll freely admit to finding “'Foo' object” ambiguous. It can reasonably
be interpreted to mean either “a 'Foo' object” (⇒ “an object of class
'Foo'”), or “the 'Foo' object” (⇒ “the object referred to by the name
'Foo'”). The error message which inspired this thread needs improvement,
as I've said already.

Let's not dismiss anyone's experience without good reason.

-- 
 \ “When people believe that they have absolute knowledge, with no |
  `\ test in reality, this [the Auschwitz crematorium] is how they |
_o__) behave.” —Jacob Bronowski, _The Ascent of Man_, 1973 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ben Finney]

Rustom Mody rustompm...@gmail.com writes:

 Me(Rusi): Prefer a not so cavalier adjective-noun equivalencing

I can sympathise with that preference. It really is a lost cause,
though; the English language just works that way.

We use nouns as verbs, nouns as modifiers, adjectives as nouns; and
rather than wish it were not so, we must to take care to express
ourselves to avoid unintended ambiguity — especially in writing. And
*especially* in writing terse formal error messages.

The English language is imperfect, but it's what we have. Live with it.

-- 
 \  “The manager has personally passed all the water served here.” |
  `\  —hotel, Acapulco |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 11:31:46 AM UTC+5:30, random wrote:
 On Wed, Jan 28, 2015, at 00:43, Devin Jeanpierre wrote:
  On Tue, Jan 27, 2015 at 9:37 PM,  random832 wrote:
   Sub itself is not a Sub object, it is a type object. instance is
   implicit in the phrase foo object.
  
  Yes. Unfortunately, it's still not really completely clear. Sub
  instance would avoid this confusion for everyone.
 
 It really is completely clear. Nobody is confused but you.

I think I can count 4 people
OP trying to show the confusion (maybe confusedly)
Ben agreeing that some terminology could be straightened out
Devin agreeing with Ben
Me(Rusi): Prefer a not so cavalier adjective-noun equivalencing
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ben Finney]

Devin Jeanpierre jeanpierr...@gmail.com writes:

 […] as Ben Finney pointed out. (BTW I agree with literally every
 single thing he said in this thread, it's really amazing.)

Hmm, writing that doesn't annoy somebody is not worth writing [0].

It shouldn't annoy *everyone* though, so I'm glad to know you can agree
with me this time :-)


[0] often attributed to Kingley Amis, as “If you can't annoy somebody,
there's little point in writing.” though I can't find the source for
that aphorism.

-- 
 \ “Facts are stubborn things; and whatever may be our wishes, our |
  `\   inclinations, or the dictates of our passion, they cannot alter |
_o__)the state of facts and evidence.” —John Adams, 1770-12-04 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 10:18:07 AM UTC+5:30, alex23 wrote:
 On 28/01/2015 10:24 AM, Mario Figueiredo wrote:
  In other words, the object know as Sub class is not an instance
  object. True, it is an instance of the object 'type'.
 
   class Foo:
  ... pass
  ...
   isinstance(Foo, type)
  True
   isinstance(Foo, object)
  True
 
 A class is an object that is an instance of the class type. I'm still 
 failing to see what distinction you're trying to make here.

Confusion is not disallowed is it ;-)
Maybe some diagrams will help. Something like
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.631rep=rep1type=pdf
pic on page 7 particularly the distinction between the arrows and the dotted 
arrows
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Marko Rauhamaa]

Mario Figueiredo mar...@gmail.com:

 That is valuable input. You don't care how a type or an instance of a
 type differ. Should be intersting to ask you to make a Cat object. I
 wonder if you are not going to ask if they mean a class or an instance
 of that class.

 Anyways, more to the point, this is simply a debate on language and how 
 to express Python concepts. If that bothers you, I'll take note.

Python itself has answers to your questions:

isinstance(3, int)
   True
isinstance(3, int)
   False
isinstance(int, type)
   True
isinstance(type, int)
   False
isinstance(type, type)
   True
isinstance(3, type)
   False
isinstance(int, 3)
   Traceback (most recent call last):
 File stdin, line 1, in module
   TypeError: isinstance() arg 2 must be a type or tuple of types
isinstance(3, object)
   True
isinstance(3, object)
   True
isinstance(int, object)
   True
isinstance(type, object)
   True
isinstance(object, object)
   True


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[random832]

On Tue, Jan 27, 2015, at 16:06, Mario Figueiredo wrote:
 That error message has me start that thread arguing that the error is 
 misleading because the Sub object does have the __bases__ attribute. 
 It's the Sub instance object that does not have it.

What do you think Sub object means?

Sub itself is not a Sub object, it is a type object. instance is
implicit in the phrase foo object.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Devin Jeanpierre]

On Tue, Jan 27, 2015 at 9:37 PM,  random...@fastmail.us wrote:
 On Tue, Jan 27, 2015, at 16:06, Mario Figueiredo wrote:
 That error message has me start that thread arguing that the error is
 misleading because the Sub object does have the __bases__ attribute.
 It's the Sub instance object that does not have it.

 What do you think Sub object means?

 Sub itself is not a Sub object, it is a type object. instance is
 implicit in the phrase foo object.

Yes. Unfortunately, it's still not really completely clear. Sub
instance would avoid this confusion for everyone.

I think the only reason to avoid instance in the past would have
been the old-style object confusion, as Ben Finney pointed out. (BTW I
agree with literally every single thing he said in this thread, it's
really amazing.)

-- Devin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[random832]

On Tue, Jan 27, 2015, at 23:47, alex23 wrote:
 On 28/01/2015 10:24 AM, Mario Figueiredo wrote:
  In other words, the object know as Sub class is not an instance
  object. True, it is an instance of the object 'type'.
 
   class Foo:
  ... pass
  ...
   isinstance(Foo, type)
  True
   isinstance(Foo, object)
  True
 
 A class is an object that is an instance of the class type. I'm still 
 failing to see what distinction you're trying to make here.

I think his objection is to the use of the phrase 'Sub' object to
refer only to instances of the Sub type, when 'Sub' is the name of the
type object itself and therefore (he thinks) 'Sub' object should refer
to it instead. (I can only assume he wants 'x' object for x = Sub().)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 10:55:32 AM UTC+5:30, Marko Rauhamaa wrote:
 Python itself has answers to your questions:
 
 isinstance(3, int)
True
 isinstance(3, int)
False
 isinstance(int, type)
True
 isinstance(type, int)
False
 isinstance(type, type)
True
 isinstance(3, type)
False
 isinstance(int, 3)
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: isinstance() arg 2 must be a type or tuple of types
 isinstance(3, object)
True
 isinstance(3, object)
True
 isinstance(int, object)
True
 isinstance(type, object)
True
 isinstance(object, object)
True
 
 
 Marko


neat
Maybe add also

 isinstance(type,object)
True
 isinstance(object,object)
True
 issubclass(object,type)
False
 issubclass(type,object)
True
 isinstance(object,type)
True
 issubclass(int,object)
True
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Mark Lawrence]

On 28/01/2015 00:52, Mario Figueiredo wrote:

In article mailman.18190.1422400358.18130.python-l...@python.org,
breamore...@yahoo.co.uk says...


Mario and Andre, when you have to write code to meet the deadline to get
the stage payment, does either of your bosses really care whether or not
you are dealing with an object, an instance, or a piece of dead meat
dropped by the neighbour's cat?


That is valuable input. You don't care how a type or an instance of a
type differ. Should be intersting to ask you to make a Cat object. I
wonder if you are not going to ask if they mean a class or an instance
of that class.

Anyways, more to the point, this is simply a debate on language and how
to express Python concepts. If that bothers you, I'll take note.



The thing that bothers me is that many people, some of them with maybe 
20 years of Python experience, have repeatedly stated Python concepts 
with respect to the terms class, instance and object.  Instead of 
accepting their knowledge of the language and gracefully stepping back, 
you've carried on until the twist of knots would make any boy scout proud.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[random832]

On Wed, Jan 28, 2015, at 00:43, Devin Jeanpierre wrote:
 On Tue, Jan 27, 2015 at 9:37 PM,  random...@fastmail.us wrote:
  Sub itself is not a Sub object, it is a type object. instance is
  implicit in the phrase foo object.
 
 Yes. Unfortunately, it's still not really completely clear. Sub
 instance would avoid this confusion for everyone.

It really is completely clear. Nobody is confused but you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ned Batchelder]

On 1/27/15 7:17 PM, Mario Figueiredo wrote:

In article mailman.18191.1422400930.18130.python-l...@python.org,
n...@nedbatchelder.com says...


A common mistake is to believe that OOP is a well-defined term.  It's
not it's a collection of ideas that are expressed slightly differently
in each language.


A common mistake is thinking just because OOP has different
implementations, it doesn't have a cohesive set of well described rules
and its own well defined terminology.


I know you think that it has well described rules and terminology.  But 
take a look at this discussion, and maybe realize that the terms are not 
as well-defined, or certainly not as widely accepted as you think.


Do you have a reference that defines these terms?




I don't know what a not fully realized object is.


A fully realized object, in an object oriented paradigm, is an object
containing or pointing to data and the methods to act on that data. It's
an instance of a class.

A *not* fully realized object is possible in Python, since Classes are
first-class objects, despite not being able to participate in OOP.


What does participate in OOP mean?


Means the object is capable of participating in inheritance and/or
polymorphism. An instance of an object is capable of doing so, per its
class definitions. Whereas a Python class object is not.

  class Master:
 def func(self):
 pass

  class Sub(Master):
 pass

  Sub.func()
 TypeError: func() missing 1 required positional argument: 'self'




But somehow I think you knew the answer to all these questions and were
instead being snarky.


I am not being snarky, I'm trying to understand where our mutual 
incomprehension lies.



--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Ian Kelly]

On Tue, Jan 27, 2015 at 5:17 PM, Mario Figueiredo mar...@gmail.com wrote:
 In article mailman.18191.1422400930.18130.python-l...@python.org,
 n...@nedbatchelder.com says...
 What does participate in OOP mean?

 Means the object is capable of participating in inheritance and/or
 polymorphism. An instance of an object is capable of doing so, per its
 class definitions. Whereas a Python class object is not.

Python class objects are capable of doing both these things.

  class Master:
 def func(self):
 pass

  class Sub(Master):
 pass

  Sub.func()
 TypeError: func() missing 1 required positional argument: 'self'

You get the same result by calling Master.func(), so I don't see how
this is a counter-example. Anyway, here is how class objects
participate in inheritance:

class BaseMetaClass(type):
def func(cls):
return 42

class DerivedMetaClass(BaseMetaClass):
pass

class DerivedClass(metaclass=DerivedMetaClass):
pass

 isinstance(DerivedClass, BaseMetaClass)
True
 print(DerivedClass.func())
42

Note that this is exactly the same way that non-class objects
participate in inheritance. Instances don't simply inherit from other
instances. Rather, the class of the instance inherits from other
classes and provides methods to the instances. And that's what happens
here: the class's meta class inherits from another, and the method it
defines is callable on the instance.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 1:42:47 AM UTC+5:30, Mario Figueiredo wrote:
 This is a follow up from a previous discussion in which it is argued 
 that the following code produces the correct error message terminology, 
 considering that in Python an object is also an instance.
 
  class Sub:
  pass
 
  foo = Sub()
  foo.__bases__
 [...]
 AttributeError: 'Sub' object has no attribute '__bases__'
 
 I'm making this into a new thread, because the particular discussion of 
 whether an object is an instance in Python seems more interesting than 
 discussing whether that error message should be changed or not.
 
 Here's another example where the terminology keeps indicating that in 
 Python an object is an instance:
 
  class Sub:
   pass
 
  x = Sub()
  x
 __main__.Sub object at 0x02631690
 
 The problem is that I personally cannot agree with this terminology and 
 I would like to hear arguments that could convince me to adopt the 
 Python way. But before your replies, here's my argumentation:
 
 An instance IS an object. On that we can agree. After all, everything in 
 Python is an object. Even classes are. We can even pass them as function 
 arguments:
 
  class Sub:
   pass
 
  def show(aClass):
   print(type(aClass))
   
  show(Sub)
 class 'type'
 
 The problem is that an object isn't always an instance. The word 
 instance in OOP has a very formal meaning. In programming languages in 
 which the classes aren't fully realized objects, it is ok to speak of 
 'instance' and 'object' interchangeably. But even then, sometimes the 
 term 'object instance' is preferred, as a way to separate these 
 'instances' from other variable instances that may not be created from 
 class definitions (e.g. C++ built-in types).
 
 The fact that in Python classes are objects, should not just eliminate 
 this distinction. The OOP terminology should exist beyond the language 
 implementing it. It facilitates discourse and helps transmiting concepts 
 when describing your ideas to another programmer. And because in python, 
 classes are of the type 'type' and they exist as fully realized objects, 
 is no excuse to make a distinction between them and their own fully 
 realized instances. The language implementation details should not exist 
 as a way for us to freely reformulate long standing terms.
 
 Because, from my own study of Python, I've came to realize that the 
 distinction between objects and instances of objects actually exists. In 
 Python, class objects cannot participate in OOP, only their instances. 
 This is why I say that even in Python, where a class is an object, an 
 object is not always an instance. The language itself forces that 
 distinction.
 
 ...
 
 I don't think that any of this is reason enough to rewrite error 
 messages in Python. Seems unnecessary. What I'm arguing thought is that 
 error messages in Python cannot become the source of new terminology. 
 The language itself implements a very clear distinction between class 
 objects and their instances. And it is thus wrong of us to say that 
 Object = Instance. At least from an OOP perspective.

The issue (as I see it) is primarily with English - in particular the word 
'is', technically called copula:
https://en.wikipedia.org/wiki/Copula_%28linguistics%29

Is is(!) used in 3 ways that can get mutually incompatible:
Predication: The sky is blue
Identity: Two plus three is five [Notice how you've used '=' above]
Belonging: (OOP isa relation): Cat is a mammal

Some people have found this (mis|over)use of 'is' so problematic that they have 
suggested to doctor English to not use is as far as possible:
https://en.wikipedia.org/wiki/E-Prime
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue7796] No way to find out if an object is an instance of a namedtuple

[Andrew Barnert]

Andrew Barnert added the comment:

I believe the structseq issues are a lot easier to solve than the appear. See 
#20230, which adds a _fields member to every structseq type. Having done that, 
a NamedTuple ABC works on them just fine. And of course duck typing them 
without an ABC does too.

--
nosy: +abarnert

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Eric Snow]

Eric Snow added the comment:

A NamedTuple ABC doesn't have to define any API (so that part could wait?)[1].  
I see it as most useful for isinstance checks.  Here's a solution along those 
lines:


class NamedTuple(Sequence):
@classmethod
def __subclasshook__(cls, C):
if cls is NamedTuple:
if any(_fields in B.__dict__ for B in C.__mro__):
return True
return NotImplemented

def namedtuple(...):
...
NamedTuple.register(result)
return result

(or include NamedTuple in the bases in the template)

For structseq support:

class NamedTuple(Sequence):
@classmethod
def __subclasshook__(cls, C):
if cls is NamedTuple:
if any(_fields in B.__dict__ or  # for namedtuple
   n_fields in B.__dict__  # for structseq
   for B in C.__mro__):
return True
return NotImplemented


[1] I agree there is still a problem if we define an ABC here with no API and 
then add some later.  Then classes that inherit from NamedTuple would break 
later when we add an API (just `_fields`?).  Not sure how much that is a 
concern though.  Then again we could just close out issue1820 and actually 
establish the API.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


--
nosy: +eric.snow

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Eric Snow]

Eric Snow added the comment:

It may not enough, but the use of namedtuples (vs. plain tuples) with 
functools.singledispatch() would be messier without a NamedTuple ABC (or other 
base type).  Of course, when would you want to dispatch specifically on 
namedtuple?  I can think of a few relatively weak uses, but not enough to 
justify the cost of establishing a common base class for namedtuple.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Raymond Hettinger]

Raymond Hettinger raymond.hettin...@gmail.com added the comment:

Detecting _fields is the simplest thing we can do right now.  There are too 
many structseq API differences to warrant bringing them under a single ABC 
umbrella.

--
dependencies:  -Enhance Object/structseq.c to match namedtuple and tuple
api
resolution: later - rejected
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Jan Kaliszewski]

Jan Kaliszewski z...@chopin.edu.pl added the comment:

PS. For the record: the final recipe is here: 
http://code.activestate.com/recipes/577629-namedtupleabc-abstract-base-class-mix-in-for-named/

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Roundup Robot]

Roundup Robot devnull@devnull added the comment:

New changeset 7aa3f1f7ac94 by Raymond Hettinger in branch '3.2':
Issue #7796: Add link to Jan Kaliszewski's alternate constructor and ABC for 
named tuples.
http://hg.python.org/cpython/rev/7aa3f1f7ac94

New changeset 330d3482cad8 by Raymond Hettinger in branch 'default':
Issue #7796: Add link to Jan Kaliszewski's alternate constructor and ABC for 
named tuples.
http://hg.python.org/cpython/rev/330d3482cad8

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Jan Kaliszewski]

Jan Kaliszewski z...@chopin.edu.pl added the comment:

Thank you. Raymond is against the idea so I don't know if it makes sense to 
create the real patch for now (it would patch the collections module and, I 
suppose, addming tests, docs etc.). Anyway, if somebody would be interested in 
the idea, the newest version of the draft is here: http://dpaste.org/qyKv/.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Santoso Wijaya]

Changes by Santoso Wijaya santoso.wij...@gmail.com:


--
nosy: +santa4nt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Sridhar Ratnakumar]

Changes by Sridhar Ratnakumar sridh...@activestate.com:


--
nosy:  -srid

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Daniel Urban]

Changes by Daniel Urban urban.dani...@gmail.com:


--
nosy: +durban

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Jan Kaliszewski]

Jan Kaliszewski z...@chopin.edu.pl added the comment:

On python-ideas I have proposed an ABC being also a kind of a mix-in, 
potentially making namedtuple subclassing (with custom methods etc.) more 
convenient, e.g.:

class MyRecord(namedtuple.abc):
_fields = 'x y z'
def _my_custom_method(self):
return list(self._asdict().items())

or

class MyAbstractRecord(namedtuple.abc):
def _my_custom_method(self):
return list(self._asdict().items())

class AnotherAbstractRecord(MyAbstractRecord):
def __str__(self):
return '{}'.format(super().__str__())
 
class MyRecord2(MyAbstractRecord):
_fields = 'a, b'
 
class MyRecord3(AnotherAbstractRecord):
_fields = 'p', 'q', 'r'

Here is an experimental monkey-patcher adding the 'abc' attribute to namedtuple:

http://dpaste.org/T9w6/

I am not sure if it is worth preparing an actual patch based on it. If you 
think it is I could prepare one.

--
nosy: +zuo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Jan Kaliszewski]

Jan Kaliszewski z...@chopin.edu.pl added the comment:

PS. Newer, shorter version: http://dpaste.org/2aiQ/

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

Thanks for working on this.  I have some remarks:

1) Please post diff files here instead of using external sites.  See 
http://docs.python.org/devguide/patch#preparation

2) The license you chose doesn’t allow the PSF to include it into Python, see 
http://www.python.org/psf/contrib/contrib-form/

3) abc looks like a module name, here something like NamedTupleABC or simply 
NamedTuple would be better.  Note that this bug is only about type checking, 
the alternate form of defining named tuples thanks to this ABC is an additional 
feature; Raymond may reject it.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


--
dependencies: +Enhance Object/structseq.c to match namedtuple and tuple api

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

To make sure I understand: StructSeq is the C-pendent of named tuples, and a 
NamedTuple ABC would have to work with StructSeqs too?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Raymond Hettinger]

Raymond Hettinger rhettin...@users.sourceforge.net added the comment:

Am deferring this to Py3.3.  There is a workaround available just using 
duck-typing and I would like to wait until more more has been done on StructSeq 
before setting committing to an new namedtuple Abstract Base Class (one 
released, it would be very hard to change).  Also, I would like to see how 
pprint() evolves (because it may also want to have special handling for named 
tuples).

--
priority: high - low
resolution:  - later
versions: +Python 3.3 -Python 2.7, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7796] No way to find out if an object is an instance of a namedtuple

[Raymond Hettinger]

Changes by Raymond Hettinger rhettin...@users.sourceforge.net:


--
priority: normal - high

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7796
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: constructing an object from another instance of the same class

[Jean-Michel Pichavant]

Christoph Groth wrote:

Dear all,

sometimes it is handy to have a function which can take as argument
anything which can be converted into something, e.g.

def foo(arg):
arg = float(arg)
# ...

I would like to mimic this behavior of float for a user-defined type,
e.g. 


def bar(arg):
arg = My_type(arg)
# ...

Now I wonder what is the most pythonic way to write the __init__ method
of My_type?  The following comes to my mind:

class My_type:
def __init__(self, other):
if isinstance(other, type(self)):
self.a = other.a
self.b = other.b
return
# initialize self in some other way

It seems to me that in this way I might get problems when I pass an
instance of Derived_from_my_type to bar, as it will become an instance
of My_type.

What is a good way to express this?  In C++ (which I know better than
python) I would make bar accept a const reference to My_type.  Then I
could use it directly with instances of My_type, Derived_from_my_type
and other types which can be converted into My_type.

thanks
Christoph

  
There is no need to do such thing in python most of the time. Python is 
strongly typed and won't change the type of an object for you (unlike 
perl for instance). That means no matter where you are in your code, you 
should know the exact type of your objects.


If you don't, that means you are assigning to the *same name*, object of 
different types. You don't want to that.


One possible solution is to make your class also a factory class:
python 2.5

class My_type(object):
   @classmethod
   def fromInt(cls, anInteger):
  Return a My_type instance given an integer
  pass

   @classmethod
   def fromString(cls, aString):
  Return a My_type instance given an integer
  pass


Try to resist the temptation of making one constructor that would handle 
any type of parameter, it may look stylish,  but from the I don't care 
about the parameter type you will soon experience the I don't know 
about the parameter type which is problematic when debugging / 
maintaining the code.


JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: constructing an object from another instance of the same class

[Carl Banks]

On Jun 18, 3:55 pm, Christoph Groth c...@falma.de wrote:
 Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid writes:
  Anyway: the simplest solution here is to replace the call to your Base
  class with a call to a factory function. I'd probably go for something
  like (QD untested code and other usual warnings) :

  (...)

 Yeah, that will do what I want.

 My confusion arose from the expectation that there had to be some
 mechanism to do the conversion automatically.  But actually a simple

 def bar(arg):
     if not isinstance(arg, Base):
         arg = Base(arg)
         # Do something with arg.

 is a simple and explicit solution of the problem.

What if someone wants to call bar with an argument that mimics a Base
but isn't a subclass?  Your function would try to convert it to an
actual Base.

Something to think about before you make a habit of this.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

constructing an object from another instance of the same class

[Christoph Groth]

Dear all,

sometimes it is handy to have a function which can take as argument
anything which can be converted into something, e.g.

def foo(arg):
arg = float(arg)
# ...

I would like to mimic this behavior of float for a user-defined type,
e.g. 

def bar(arg):
arg = My_type(arg)
# ...

Now I wonder what is the most pythonic way to write the __init__ method
of My_type?  The following comes to my mind:

class My_type:
def __init__(self, other):
if isinstance(other, type(self)):
self.a = other.a
self.b = other.b
return
# initialize self in some other way

It seems to me that in this way I might get problems when I pass an
instance of Derived_from_my_type to bar, as it will become an instance
of My_type.

What is a good way to express this?  In C++ (which I know better than
python) I would make bar accept a const reference to My_type.  Then I
could use it directly with instances of My_type, Derived_from_my_type
and other types which can be converted into My_type.

thanks
Christoph

-- 
http://mail.python.org/mailman/listinfo/python-list