Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #75517 > unrolled thread

3 Suggestions to Make Python Easier For Children

Back to article view | Back to comp.lang.python

Contents

  3 Suggestions to Make Python Easier For Children Mark Summerfield <list@qtrac.plus.com> - 2014-08-01 23:45 -0700
    Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-02 10:14 +0300
      Re: 3 Suggestions to Make Python Easier For Children Mark Summerfield <list@qtrac.plus.com> - 2014-08-02 00:38 -0700
        Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-02 11:03 +0300
          Re: 3 Suggestions to Make Python Easier For Children Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-03 02:00 +1000
            Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-02 20:07 +0300
              Re: 3 Suggestions to Make Python Easier For Children Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-02 18:29 +0100
                Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-02 21:33 +0300
      Re: 3 Suggestions to Make Python Easier For Children Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-03 01:43 +1000
        Correct type for a simple “bag of attributes” namespace object (was: 3 Suggestions to Make Python Easier For Children) Ben Finney <ben+python@benfinney.id.au> - 2014-08-03 05:58 +1000
          Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Mark Summerfield <list@qtrac.plus.com> - 2014-08-02 13:46 -0700
            Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Chris Angelico <rosuav@gmail.com> - 2014-08-03 07:05 +1000
            Re: Correct type for a simple "bag of attributes" namespace object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-02 22:16 +0100
            Re: Correct type for a simple "bag of attributes" namespace object Chris Angelico <rosuav@gmail.com> - 2014-08-03 07:24 +1000
            Re: Correct type for a simple "bag of attributes" namespace object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-02 22:23 +0100
            Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-08-02 16:18 -0700
            Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Chris Angelico <rosuav@gmail.com> - 2014-08-03 09:27 +1000
            Re: Correct type for a simple "bag of attributes" namespace object (was: 3 Suggestions to Make Python Easier For Children) Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-02 18:59 -0600
            Re: Correct type for a simple "bag of attributes" namespace object Terry Reedy <tjreedy@udel.edu> - 2014-08-02 22:40 -0400
            Re: Correct type for a simple "bag of attributes" namespace object Terry Reedy <tjreedy@udel.edu> - 2014-08-02 22:43 -0400
            Re: Correct type for a simple "bag of attributes" namespace object Albert-Jan Roskam <fomcl@yahoo.com> - 2014-08-03 02:17 -0700
            Re: Correct type for a simple "bag of attributes" namespace object Peter Otten <__peter__@web.de> - 2014-08-03 11:37 +0200
            Re: Correct type for a simple "bag of attributes" namespace object Albert-Jan Roskam <fomcl@yahoo.com> - 2014-08-03 03:51 -0700
            Re: Correct type for a simple "bag of attributes" namespace object Albert-Jan Roskam <fomcl@yahoo.com> - 2014-08-03 04:14 -0700
            Re: Correct type for a simple "bag of attributes" namespace object Peter Otten <__peter__@web.de> - 2014-08-03 13:23 +0200
              Re: Correct type for a simple "bag of attributes" namespace object Marko Rauhamaa <marko@pacujo.net> - 2014-08-03 17:51 +0300
                Re: Correct type for a simple "bag of attributes" namespace object Roy Smith <roy@panix.com> - 2014-08-03 11:09 -0400
                  Re: Correct type for a simple "bag of attributes" namespace object Marko Rauhamaa <marko@pacujo.net> - 2014-08-03 18:52 +0300
                Re: Correct type for a simple "bag of attributes" namespace object Terry Reedy <tjreedy@udel.edu> - 2014-08-03 18:55 -0400
                  Re: Correct type for a simple "bag of attributes" namespace object Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-04 11:19 +1000
                    Re: Correct type for a simple "bag of attributes" namespace object Terry Reedy <tjreedy@udel.edu> - 2014-08-04 01:26 -0400
                Re: Correct type for a simple "bag of attributes" namespace object Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-04 10:13 +1000
                  Re: Correct type for a simple "bag of attributes" namespace object Roy Smith <roy@panix.com> - 2014-08-03 20:59 -0400
                  Re: Correct type for a simple "bag of attributes" namespace object Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-04 13:00 +1200
                  Re: Correct type for a simple "bag of attributes" namespace object Marko Rauhamaa <marko@pacujo.net> - 2014-08-04 08:41 +0300
                    Re: Correct type for a simple "bag of attributes" namespace object Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-04 00:41 -0600
                      Re: Correct type for a simple "bag of attributes" namespace object Marko Rauhamaa <marko@pacujo.net> - 2014-08-04 09:57 +0300
            Re: Correct type for a simple "bag of attributes" namespace object Akira Li <4kir4.1i@gmail.com> - 2014-08-03 18:22 +0400
        Re: Correct type for a simple “bag of attributes” namespace object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-03 13:28 +0100
          Re: Correct type for a simple “bag of attributes” namespace object Roy Smith <roy@panix.com> - 2014-08-03 08:40 -0400
            Re: Correct type for a simple “bag of attributes” namespace object Chris Angelico <rosuav@gmail.com> - 2014-08-03 22:56 +1000
              Re: Correct type for a simple “bag of attributes” namespace object Roy Smith <roy@panix.com> - 2014-08-03 09:25 -0400
                Re: Correct type for a simple “bag of attributes” namespace object Chris Angelico <rosuav@gmail.com> - 2014-08-03 23:35 +1000
                  Re: Correct type for a simple “bag of attributes” namespace object Roy Smith <roy@panix.com> - 2014-08-03 10:36 -0400
                    Re: Correct type for a simple “bag of attributes” namespace object Chris Angelico <rosuav@gmail.com> - 2014-08-04 01:00 +1000
        Re: Correct type for a simple “bag of attributes” namespace object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-03 18:38 +0100
          Re: Correct type for a simple “bag of attributes” namespace object Roy Smith <roy@panix.com> - 2014-08-03 13:44 -0400
    Re: 3 Suggestions to Make Python Easier For Children Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-02 08:46 +0100
      Re: 3 Suggestions to Make Python Easier For Children Mark Summerfield <list@qtrac.plus.com> - 2014-08-02 01:03 -0700
        Re: 3 Suggestions to Make Python Easier For Children Terry Reedy <tjreedy@udel.edu> - 2014-08-02 19:14 -0400
    Re: 3 Suggestions to Make Python Easier For Children Terry Reedy <tjreedy@udel.edu> - 2014-08-02 19:12 -0400
    Re: 3 Suggestions to Make Python Easier For Children Brian Blais <bblais@gmail.com> - 2014-08-05 07:36 -0400
      Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-05 15:04 +0300
        Re: 3 Suggestions to Make Python Easier For Children Skip Montanaro <skip@pobox.com> - 2014-08-05 07:31 -0500
          Re: 3 Suggestions to Make Python Easier For Children Marko Rauhamaa <marko@pacujo.net> - 2014-08-05 16:19 +0300
            Re: 3 Suggestions to Make Python Easier For Children MRAB <python@mrabarnett.plus.com> - 2014-08-05 15:11 +0100
            Re: 3 Suggestions to Make Python Easier For Children Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-06 02:14 +1000
        Re: 3 Suggestions to Make Python Easier For Children Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-05 22:43 +1000
          Re: 3 Suggestions to Make Python Easier For Children Chris Angelico <rosuav@gmail.com> - 2014-08-05 23:08 +1000
        Re: 3 Suggestions to Make Python Easier For Children Chris Angelico <rosuav@gmail.com> - 2014-08-05 23:00 +1000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#75583 — Re: Correct type for a simple "bag of attributes" namespace object

--- Original Message -----
> From: Terry Reedy <tjreedy@udel.edu>
> To: python-list@python.org
> Cc: 
> Sent: Sunday, August 3, 2014 4:43 AM
> Subject: Re: Correct type for a simple "bag of attributes" namespace object
> 
> On 8/2/2014 8:59 PM, Ian Kelly wrote:
>>  On Sat, Aug 2, 2014 at 2:46 PM, Mark Summerfield 
> <list@qtrac.plus.com> wrote:
>>>  On Saturday, 2 August 2014 20:58:59 UTC+1, Ben Finney  wrote:
>>>>  Steven D'Aprano writes:
>>>> 
>>>>>  If you need instances which carry state, then object is the 
> wrong
>>>>>  class.
>>> 
>>>  Fair enough.
>>> 
>>>>  Right. The 'types' module provides a SimpleNamespace class 
> for the
>>>>  common "bag of attributes" use case::
>>>> 
>>>>       >>> import types
>>>>       >>> foo = types.SimpleNamespace()
>>>>       >>> foo.x = 3
>>>>       >>> foo
>>>>       namespace(x=3)
>>> 
>>>  This is too much for children (& beginners).
>>> 
>>>  But perhaps what I should be asking for is for a new built-in that does 
> what types.SimpleNamespace() does, so that without any import you can write, 
> say,
>>> 
>>>  foo = namespace(a=1, b=2)
>>>  # or
>>>  bar = namespace()
>>>  bar.a = 1

I find the following obscure (to me at least) use of type() useful exactly for this "bag of attributes" use case:
>>> employee = type("Employee", (object,), {})
>>> employee.name = "John Doe"
>>> employee.position = "Python programmer"
>>> employee.name, employee.position, employee
('John Doe', 'Python programmer', <class '__main__.Employee'>)

>>> details = dict(name="John Doe", position="Python programmer")
>>> employee = type("Employee", (object,), details)
>>> employee.name, employee.position, employee
('John Doe', 'Python programmer', <class '__main__.Employee'>)


regards,
Albert-Jan 

[toc] | [prev] | [next] | [standalone]

#75584 — Re: Correct type for a simple "bag of attributes" namespace object

Albert-Jan Roskam wrote:

> I find the following obscure (to me at least) use of type() useful exactly
> for this "bag of attributes" use case:
>>>> employee = type("Employee", (object,), {})
>>>> employee.name = "John Doe"
>>>> employee.position = "Python programmer"
>>>> employee.name, employee.position, employee
> ('John Doe', 'Python programmer', <class '__main__.Employee'>)
 
Are you sure you know what you are doing? The above is equivalent to

>>> class employee:
...     name = "John Doe"
...     position = "Python programmer"
... 
>>> employee.name, employee.position, employee
('John Doe', 'Python programmer', <class '__main__.employee'>)
>>> type(employee)
<class 'type'>

Basically you are using classes as instances. While there is no fundamental 
difference between classes and instances in Python you'll surprise readers 
of your code and waste some space:

>>> import sys
>>> sys.getsizeof(employee)
976
>>> class Employee: pass
... 
>>> employee = Employee()
>>> employee.name = "John Doe"
>>> employee.position = "Python programmer"
>>> sys.getsizeof(employee)
64

[toc] | [prev] | [next] | [standalone]

#75587 — Re: Correct type for a simple "bag of attributes" namespace object

----- Original Message -----

> From: Peter Otten <__peter__@web.de>
> To: python-list@python.org
> Cc: 
> Sent: Sunday, August 3, 2014 11:37 AM
> Subject: Re: Correct type for a simple "bag of attributes" namespace object
> 
> Albert-Jan Roskam wrote:
> 
>>  I find the following obscure (to me at least) use of type() useful exactly
>>  for this "bag of attributes" use case:
>>>>>  employee = type("Employee", (object,), {})
>>>>>  employee.name = "John Doe"
>>>>>  employee.position = "Python programmer"
>>>>>  employee.name, employee.position, employee
>>  ('John Doe', 'Python programmer', <class 
> '__main__.Employee'>)
> 
> Are you sure you know what you are doing? The above is equivalent to
> 
>>>>  class employee:
> ...     name = "John Doe"
> ...     position = "Python programmer"
> ... 
>>>>  employee.name, employee.position, employee
> ('John Doe', 'Python programmer', <class 
> '__main__.employee'>)
>>>>  type(employee)
> <class 'type'>
> 
> Basically you are using classes as instances. While there is no fundamental 
> difference between classes and instances in Python you'll surprise readers 
> of your code and waste some space:

Yes, I know that it is equivalent, but I have always found it kind of ugly to use class() just to bundle a number of items. Like you are 'announcing OOP' (not sure how to put this into words), and then it's merely a simple bundle. Or maybe it's just me being silly, because it's even in the Python tutorial: https://docs.python.org/2/tutorial/classes.html#odds-and-ends
 
>>>>  import sys
>>>>  sys.getsizeof(employee)
> 976
>>>>  class Employee: pass
> ... 
>>>>  employee = Employee()
>>>>  employee.name = "John Doe"
>>>>  employee.position = "Python programmer"
>>>>  sys.getsizeof(employee)
> 64
Wow, I was not aware of that at all. So they are not equivalent after all. 

[toc] | [prev] | [next] | [standalone]

#75589 — Re: Correct type for a simple "bag of attributes" namespace object

----- Original Message -----

> From: Albert-Jan Roskam <fomcl@yahoo.com.dmarc.invalid>
> To: Terry Reedy <tjreedy@udel.edu>; "python-list@python.org" <python-list@python.org>
> Cc: 
> Sent: Sunday, August 3, 2014 11:17 AM
> Subject: Re: Correct type for a simple "bag of attributes" namespace object

<snip>

>>>>>   Right. The 'types' module provides a SimpleNamespace 
> class 
>>  for the
>>>>>   common "bag of attributes" use case::
>>>>> 
>>>>>        >>> import types
>>>>>        >>> foo = types.SimpleNamespace()
>>>>>        >>> foo.x = 3
>>>>>        >>> foo
>>>>>        namespace(x=3)
>>>> 
>>>>   This is too much for children (& beginners).
>>>> 
>>>>   But perhaps what I should be asking for is for a new built-in that 
> does 
>>  what types.SimpleNamespace() does, so that without any import you can 
> write, 
>>  say,
>>>> 
>>>>   foo = namespace(a=1, b=2)
>>>>   # or
>>>>   bar = namespace()
>>>>   bar.a = 1
> 
> I find the following obscure (to me at least) use of type() useful exactly for 
> this "bag of attributes" use case:
>>>>  employee = type("Employee", (object,), {})
>>>>  employee.name = "John Doe"
>>>>  employee.position = "Python programmer"
>>>>  employee.name, employee.position, employee
> ('John Doe', 'Python programmer', <class 
> '__main__.Employee'>)
> 
>>>>  details = dict(name="John Doe", position="Python 
> programmer")
>>>>  employee = type("Employee", (object,), details)
>>>>  employee.name, employee.position, employee
> ('John Doe', 'Python programmer', <class 
> '__main__.Employee'>)


PS to my previous mail: class() can (should?) be used here to do the exact same thing but it feels a little like "Getting your car [OOP] just because you need an ashtray [bundled items]". :-)

[toc] | [prev] | [next] | [standalone]

#75590 — Re: Correct type for a simple "bag of attributes" namespace object

Albert-Jan Roskam wrote:

> 
> 
> ----- Original Message -----
> 
>> From: Peter Otten <__peter__@web.de>
>> To: python-list@python.org
>> Cc:
>> Sent: Sunday, August 3, 2014 11:37 AM
>> Subject: Re: Correct type for a simple "bag of attributes" namespace
>> object
>> 
>> Albert-Jan Roskam wrote:
>> 
>>>  I find the following obscure (to me at least) use of type() useful
>>>  exactly for this "bag of attributes" use case:
>>>>>>  employee = type("Employee", (object,), {})
>>>>>>  employee.name = "John Doe"
>>>>>>  employee.position = "Python programmer"
>>>>>>  employee.name, employee.position, employee
>>>  ('John Doe', 'Python programmer', <class
>> '__main__.Employee'>)
>> 
>> Are you sure you know what you are doing? The above is equivalent to
>> 
>>>>>  class employee:
>> ...     name = "John Doe"
>> ...     position = "Python programmer"
>> ...
>>>>>  employee.name, employee.position, employee
>> ('John Doe', 'Python programmer', <class
>> '__main__.employee'>)
>>>>>  type(employee)
>> <class 'type'>
>> 
>> Basically you are using classes as instances. While there is no
>> fundamental difference between classes and instances in Python you'll
>> surprise readers of your code and waste some space:
> 
> Yes, I know that it is equivalent, but I have always found it kind of ugly
> to use class() just to bundle a number of items. 

But that's what you are doing, you just spell it differently.

> Like you are 'announcing
> OOP' (not sure how to put this into words), and then it's merely a simple
> bundle. Or maybe it's just me being silly, because it's even in the Python
> tutorial: https://docs.python.org/2/tutorial/classes.html#odds-and-ends
> 
>>>>>  import sys
>>>>>  sys.getsizeof(employee)
>> 976
>>>>>  class Employee: pass
>> ...
>>>>>  employee = Employee()
>>>>>  employee.name = "John Doe"
>>>>>  employee.position = "Python programmer"
>>>>>  sys.getsizeof(employee)
>> 64
> Wow, I was not aware of that at all. So they are not equivalent after all.

I think you are misunderstanding what I was trying to say; so to be 
explicit:

>>> class Employee: pass
... 
>>> sys.getsizeof(Employee)
976

i. e. you have a per-class and per-instance memory consumption. The latter 
is smaller, so with regards to memory consumption instantiating only pays 
off when there is more than one employee.

[toc] | [prev] | [next] | [standalone]

#75603 — Re: Correct type for a simple "bag of attributes" namespace object

Peter Otten <__peter__@web.de>:

> i. e. you have a per-class and per-instance memory consumption. The
> latter is smaller, so with regards to memory consumption instantiating
> only pays off when there is more than one employee.

I've reached a point where I think classes are a superfluous OO concept.
You only need objects.

Python is close to that reality. The "class" keyword really creates a
function that creates objects, and the objects' class membership is
ignored in ducktyping.

Classes may or may not save RAM, but that is rather a low-brow point of
view toward OO.


Marko

[toc] | [prev] | [next] | [standalone]

#75606 — Re: Correct type for a simple "bag of attributes" namespace object

In article <87wqaplj8h.fsf@elektro.pacujo.net>,
 Marko Rauhamaa <marko@pacujo.net> wrote:

> I've reached a point where I think classes are a superfluous OO concept.
> You only need objects.

comp.lang.javascript is over that way -->

[toc] | [prev] | [next] | [standalone]

#75608 — Re: Correct type for a simple "bag of attributes" namespace object

Roy Smith <roy@panix.com>:

>  Marko Rauhamaa <marko@pacujo.net> wrote:
>
>> I've reached a point where I think classes are a superfluous OO
>> concept. You only need objects.
>
> comp.lang.javascript is over that way -->

Thanks for the insight. I'm currently more absorbed by comp.lang.scheme,
though.

Now, Python is ducktyped. It is (rightly) considered bad taste to
consult the datatype (class) of an object. Compare these two
definitions:

   class Point:
       def __init__(self, x, y):
           self.x = x
           self.y = y

       def x(self):
           return self.x

       def y(self):
           return self.y

and:

   class Object: pass

   def Point(x, y):
       self = Object()
       self.__dict__ = dict(x=lambda: x, y=lambda: y)
       return self

For all practical purposes, the two definitions are identical even
though the latter doesn't specify any class. Inheritance needs to be
addressed, but that can be taken care of without classes as well.

Obviously, Python's syntax makes it convenient to deal with classes, and
there's no practical downside to it. However, conceptually, classes are
unnecessary baggage and at odds with ducktyping.


Marko

[toc] | [prev] | [next] | [standalone]

#75626 — Re: Correct type for a simple "bag of attributes" namespace object

On 8/3/2014 10:51 AM, Marko Rauhamaa wrote:
> Peter Otten <__peter__@web.de>:
>
>> i. e. you have a per-class and per-instance memory consumption. The
>> latter is smaller, so with regards to memory consumption instantiating
>> only pays off when there is more than one employee.
>
> I've reached a point where I think classes are a superfluous OO concept.
> You only need objects.
>
> Python is close to that reality. The "class" keyword really creates a
> function that creates objects, and the objects' class membership is
> ignored in ducktyping.

The object class is used to implement duck typing.  It is the delegation 
of operations to class instance methods that makes extensible duck 
typing possible.

'a + b' is equivalent to type(a).__add__(a, b)

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#75640 — Re: Correct type for a simple "bag of attributes" namespace object

Terry Reedy wrote:

> The object class is used to implement duck typing.  It is the delegation
> of operations to class instance methods that makes extensible duck
> typing possible.

That cannot possibly be true, because Python had duck typing before it had
object. object and new-style classes were introduced in Python 2.2, which
means that there were a good half-dozen versions of Python, including the
very popular 1.5, where people couldn't use object.

(Also, I'm not sure what you mean by "class instance methods" -- methods can
be class methods, or they can be instance methods, but not both at the same
time.)

> 'a + b' is equivalent to type(a).__add__(a, b)

It's actually more complicated than that, because type(b).__radd__ also gets
considered, but either way, I don't think that the *implementation* of + is
relevant here.

Duck-typing isn't really a mechanism, in the sense that static/dynamic or
strong/weak typing are mechanisms:

- static typing means that the compiler can tell at compile-time what type
  a variable will have, and prohibit code which may violate that constraint;

- dynamic typing means that types are associated with values, not with 
  variables;

- strong typing means that the compiler will do nothing (or very little) 
  to automatically convert values from one type to another;

- weak typing means that the compiler will do a lot to automatically
  convert values from one type to another, including possibly some
  conversions which are considered by many to be unsafe or silly.


Duck-typing is more of a programming philosophy than a mechanism, at least
in Python:

- you shouldn't care whether a value has a specific type or not, but 
  whether it exposes the interface you care about.

Some languages (like Java) try to formalise this, providing a mechanism by
which you can implement a particular interface in a way known to the
compiler:

https://en.wikipedia.org/wiki/Interface_%28Java%29

Python's ABCs (abstract base classes, introduced in version 2.6) are
similar. In both cases, they use the type system (in Java's case, at
compile-time, in Python's case, at run-time) to check for an interface
up-front, i.e. a form of "Look Before You Leap".

In Python, duck-typing can also be more ad hoc and informal: if you want to
know whether an object provides a certain interface, you typically just try
it and see if it breaks, hoping that it will raise an exception sooner
rather than later (i.e. "Easier to Ask for Forgiveness than Permission").
That's why I call it more of a philosophy than a mechanism.

Duck-typing, of course, is not infallible. Suppose you're expecting an
Artist, and call the artist.draw() method, but somebody gives you a
Gunfighter instead. There's also the problem of what to do when an object
provides only *part* of an interface: sometimes, by the time you have to
ask forgiveness, you've already made irreversible changes to something (a
file, a database, or launched the missiles).



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#75660 — Re: Correct type for a simple "bag of attributes" namespace object

On 8/3/2014 9:19 PM, Steven D'Aprano wrote:

stuff based on an understandable misunderstanding of what I wrote.

> Terry Reedy wrote:
>
>> The object class is used to implement duck typing.  It is the delegation
>> of operations to class instance methods that makes extensible duck
>> typing possible.

I left off "'s". The object's class ...

'class instance methods' = class attributes that are instance methods. I 
was alluding to the fact that magic methods are looked up directly on 
the class and not the instance.

Sorry for the confusion.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#75632 — Re: Correct type for a simple "bag of attributes" namespace object

Marko Rauhamaa wrote:

> I've reached a point where I think classes are a superfluous OO concept.
> You only need objects.

I don't know whether "superfluous" is correct, but they certainly are
*optional*. There are at least two types of object oriented programming:
class-bases, and prototype-based. Java, Python, Ruby, etc. are all
class-based. The only example of a prototype-based OOP language I know of
is Javascript, and even that has recently gained the ability to define
classes.

I don't know enough about prototyped OOP to really give a definitive answer,
but I believe that the popularity of class-based OOP is because there is a
huge body of theory on types, which makes it easier for compiler designers
to reason about classes than prototypes. For example, if Haskell introduces
OOP (and it may already have, I don't know) I would expect it to be
class-based. Also, the first OOP languages (Simula and, especially,
Smalltalk) are class-based, and people tend to copy what's been done before
and what they're familiar with.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#75637 — Re: Correct type for a simple "bag of attributes" namespace object

In article <53ded02e$0$29980$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Marko Rauhamaa wrote:
> 
> > I've reached a point where I think classes are a superfluous OO concept.
> > You only need objects.
> 
> I don't know whether "superfluous" is correct, but they certainly are
> *optional*. There are at least two types of object oriented programming:
> class-bases, and prototype-based. Java, Python, Ruby, etc. are all
> class-based. The only example of a prototype-based OOP language I know of
> is Javascript, and even that has recently gained the ability to define
> classes.
> 
> I don't know enough about prototyped OOP to really give a definitive answer,
> but I believe that the popularity of class-based OOP is because there is a
> huge body of theory on types, which makes it easier for compiler designers
> to reason about classes than prototypes. For example, if Haskell introduces
> OOP (and it may already have, I don't know) I would expect it to be
> class-based. Also, the first OOP languages (Simula and, especially,
> Smalltalk) are class-based, and people tend to copy what's been done before
> and what they're familiar with.

The first code I ever saw which had any OO concepts was the Unix kernel 
I/O drivers.  The whole thing was written in C.  It essentially 
implemented something we would recognize today as static class 
inheritance with polymorphic method dispatch.

Each driver was required to implement a number of functions (read, 
write, open, etc), with specified signatures and contracts.  
Effectively, the all subclassed a (mythical) BaseIODriver.  There was a 
big table where the rows were the different drivers (indexed by major 
device number), and the columns were the different methods.  That was in 
the early 70s.

[toc] | [prev] | [next] | [standalone]

#75638 — Re: Correct type for a simple "bag of attributes" namespace object

Steven D'Aprano wrote:
> I don't know enough about prototyped OOP to really give a definitive answer,
> but I believe that the popularity of class-based OOP is because there is a
> huge body of theory on types,

I think it's more than that. I thought about prototype-based
OO systems in some depth a while ago, and I came to the
conclusion that the supposed simplification that comes
from not having classes is an illusion.

It *seems* simpler to have only one kind of object and
allow any object to inherit from any other. But actually
using it in such an undisciplined way would lead to chaos.

In practice, you end up with two groups of objects, with
one being used in a class-like way, and the other in an
instance-like way. So you effectively have classes anyway,
whether you call them that or not.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#75661 — Re: Correct type for a simple "bag of attributes" namespace object

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> Marko Rauhamaa wrote:
>
>> I've reached a point where I think classes are a superfluous OO concept.
>> You only need objects.
>
> I don't know whether "superfluous" is correct, but they certainly are
> *optional*. There are at least two types of object oriented programming:
> class-bases, and prototype-based.

And I'm talking about a third kind: object-based. It is in active
(albeit limited) use in scheme: <URL: http://irreal.org/blog/?p=40>. I'm
currently using the principle in a project of mine.

In Java, you use anonymous classes for the same thing. In Python, you
can think of the principle as one-time classes. So instead of writing:

    class A:
        def __init__(self, x, y, z):
            self.x = x
            self.d = y * y + z * z

        def f(self):
            return self.x - self.d

you write:

    def A(x, y, z):
        d = y * y + z * z

        class Anonymous:
            def f(self):
                return x - d

        return Anonymous()

Now, if you always did this, you would notice that classes are
unnecessary clutter and would call for syntax like this:

    def A(x, y, z):
        d = y * y + z * z
        return object:
            def f():
                return x - d


Marko

[toc] | [prev] | [next] | [standalone]

#75665 — Re: Correct type for a simple "bag of attributes" namespace object

On Sun, Aug 3, 2014 at 11:41 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> And I'm talking about a third kind: object-based. It is in active
> (albeit limited) use in scheme: <URL: http://irreal.org/blog/?p=40>. I'm
> currently using the principle in a project of mine.
>
> In Java, you use anonymous classes for the same thing. In Python, you
> can think of the principle as one-time classes. So instead of writing:

In my experience, 99% of the time when anonymous classes are used,
they only contain one method. That's because they're not really being
used to implement some interface abstractly; they mostly exist to
provide a means of specifying a callback function in a language where
functions aren't first-class.

>
>     class A:
>         def __init__(self, x, y, z):
>             self.x = x
>             self.d = y * y + z * z
>
>         def f(self):
>             return self.x - self.d
>
> you write:
>
>     def A(x, y, z):
>         d = y * y + z * z
>
>         class Anonymous:
>             def f(self):
>                 return x - d
>
>         return Anonymous()

And it's the same thing here.  This isn't an interface.  It's a
function, so just return a function and be done with it. And in the
rare event that you actually mean to implement more than one method,
then you have enough functionality localized that it's probably
worthwhile to just name it and make it an actual class.

> Now, if you always did this, you would notice that classes are
> unnecessary clutter and would call for syntax like this:
>
>     def A(x, y, z):
>         d = y * y + z * z
>         return object:
>             def f():
>                 return x - d

The presence of "object" here feels totally unnecessary to me.  If the
point is to avoid having a class, then why create a class?  In this
case you could easily just return a function. To take a more complex
case, say the Scheme make-queue constructor that you linked to, you
could still just return a function; the same could be implemented in
Python 3 as:


def make_queue():
  front = []
  back = []
  def queue_command(command, data=None):
    def exchange():
      nonlocal front, back
      front = back; front.reverse()
      back = []
    if command == 'push':
      back.append(data)
    elif command == 'pop':
      if not front: exchange()
      return front.pop()
    elif command == 'peek':
      if not front: exchange()
      return front[-1]
    elif command == 'show':
      return str(list(reversed(front)) + back)
    else:
      raise ValueError('Illegal command to queue object ' + command)
  queue_command.push = lambda data: queue_command('push', data)
  queue_command.pop = lambda: queue_command('pop')
  queue_command.peek = lambda: queue_command('peek')
  return queue_command


>>> queue = make_queue()
>>> queue.push(1)
>>> queue.push(2)
>>> queue.pop()
1
>>> queue.push(3)
>>> queue.push(4)
>>> queue.pop()
2
>>> queue.peek()
3
>>> queue.pop()
3
>>> queue.pop()
4

[toc] | [prev] | [next] | [standalone]

#75666 — Re: Correct type for a simple "bag of attributes" namespace object

Ian Kelly <ian.g.kelly@gmail.com>:

> In my experience, 99% of the time when anonymous classes are used,
> they only contain one method. [...]
>
>>     def A(x, y, z):
>>         d = y * y + z * z
>>
>>         class Anonymous:
>>             def f(self):
>>                 return x - d
>>
>>         return Anonymous()
>
> And it's the same thing here.  This isn't an interface.  It's a
> function, so just return a function and be done with it.

My one-time classes usually have more than one method:

    def query(self, domain_name, record_type, listener, xid = None):
        ...
        client = self
        class Operation:
            def cancel(self):
                if key in client.opmap and client.opmap[key] is self:
                    del client.opmap[key]
                def callback():
                    client.log('CANCELED')
                    listener(client.CANCELED, None)
                client.mux.schedule(callback)
            def notify(self, verdict, records):
                client.log('verdict = {}'.format(verdict))
                listener(verdict, records)
        operation = Operation()
        self.opmap[key] = operation
        ...


Marko

[toc] | [prev] | [next] | [standalone]

#75599 — Re: Correct type for a simple "bag of attributes" namespace object

Albert-Jan Roskam <fomcl@yahoo.com.dmarc.invalid> writes:

> I find the following obscure (to me at least) use of type() useful
> exactly for this "bag of attributes" use case:
>>>> employee = type("Employee", (object,), {})
>>>> employee.name = "John Doe"
>>>> employee.position = "Python programmer"

You  could write it as:

  class Employee:
      name = "Johh Doe"
      position = "Python programmer"

It also makes it clear that `type()` returns a *class Employee*, not its
instance (Employee()) and therefore name, position are class attributes.


--
Akira

[toc] | [prev] | [next] | [standalone]

#75592 — Re: Correct type for a simple “bag of attributes” namespace object

On 02/08/2014 20:58, Ben Finney wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>
>> If you need instances which carry state, then object is the wrong
>> class.
>
> Right. The ‘types’ module provides a SimpleNamespace class for the
> common “bag of attributes” use case::
>
>      >>> import types
>      >>> foo = types.SimpleNamespace()
>      >>> foo.x = 3
>      >>> foo
>      namespace(x=3)
>
> <URL:https://docs.python.org/3/library/types.html#types.SimpleNamespace>
>

What Alex Martelli called a bunch?

http://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named/

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

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#75593 — Re: Correct type for a simple “bag of attributes” namespace object

In article <mailman.12580.1407068955.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

> On 02/08/2014 20:58, Ben Finney wrote:
> > Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> >
> >> If you need instances which carry state, then object is the wrong
> >> class.
> >
> > Right. The ‘types’ module provides a SimpleNamespace class for the
> > common “bag of attributes” use case::
> >
> >      >>> import types
> >      >>> foo = types.SimpleNamespace()
> >      >>> foo.x = 3
> >      >>> foo
> >      namespace(x=3)
> >
> > <URL:https://docs.python.org/3/library/types.html#types.SimpleNamespace>
> >
> 
> What Alex Martelli called a bunch?
> 
> http://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-
> bunch-of-named/

Still overkill :-)  I usually just do:

class Data:
   pass
my_obj = Data()

That's all you really need.  It's annoying that you can't just do:

my_obj = object()

which would be even simpler, because (for reasons I don't understand), 
you can't create new attributes on my_obj.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web