Re: object().__dict__

[Ben Finney]

Pavel Volkov sai...@lists.xtsubasa.org writes:

 The attribute list is different now and there's no __dict__ and the
 object does not accept new attributes.
 Please explain what's going on.

It's a leaky abstraction, unfortunately.

By default, all user-defined types will provide their instances with a
‘__dict__’ attribute, whic is a mapping to store the instance's
attributes.

But some types don't have that, and ‘object’ is one of them. It
deliberately overrides the default behaviour, and has no ‘__dict__’ for
its instances.

 foo = object()

 foo.bar = spam
Traceback (most recent call last):
  File stdin, line 1, in module
AttributeError: 'object' object has no attribute 'bar'

 foo.__dict__
Traceback (most recent call last):
  File stdin, line 1, in module
AttributeError: 'object' object has no attribute '__dict__'

Your user-defined types, even though they inherit from ‘object’, will
get a ‘__dict__’ as normal::

 class Bag:
  A simple type to hold attributes. 

 Bag.__mro__
(class '__main__.Bag', class 'object')

 foo = Bag()
 foo.bar = spam
 foo.__dict__
{'bar': 'spam'}

See the discussion of ‘__slots__’, and note also that it's not
recommended to use this unless you know exactly why you need it
URL:https://docs.python.org/3/reference/datamodel.html#slots.

I consider it a wart of Python that its ‘object’ instances lack the
ability to gain arbitrary attributes in the way you expect.

-- 
 \  “Every man would like to be God, if it were possible; some few |
  `\  find it difficult to admit the impossibility.” —Bertrand |
_o__)Russell, _Power: A New Social Analysis_, 1938 |
Ben Finney

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

Re: object().__dict__

[Cameron Simpson]

On 23Apr2014 09:39, Pavel Volkov sai...@lists.xtsubasa.org wrote:

There are some basics about Python objects I don't understand.
Consider this snippet:


class X: pass

...

x = X()
dir(x)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', 
'__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', 
'__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', 
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', 
'__sizeof__', '__str__', '__subclasshook__', '__weakref__']

x.foo = 11


And now I want to make a simple object in a shorter way, without 
declaring X class:



y = object()
dir(y)
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', 
'__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', 
'__subclasshook__']

y.foo = 12

Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'object' object has no attribute 'foo'

The attribute list is different now and there's no __dict__ and the 
object does not accept new attributes.

Please explain what's going on.


The base object class has a fixed set of attributes; you can't add more.

Almost every other class lets you add attributes, but the price for that is 
that it is slightly in memory footprint and slower to access.


Look up the __slots__ dunder var in the Python doco index:

  https://docs.python.org/3/glossary.html#term-slots

You'll see it as a (rarely used, mostly discouraged) way to force a fixed set 
of attributes onto a class. As with object, this brings a smaller memory 
footprint and faster attribute access, but the price is flexibility.


Cheers,
Cameron Simpson c...@zip.com.au

Try being nothing but bored for 4 hours straight, and then tell me that
there's no fear involved.   - d...@elxr.jpl.nasa.gov (Dave Hayes)
--
https://mail.python.org/mailman/listinfo/python-list

Re: object().__dict__

[Amirouche Boubekki]

2014-04-23 8:11 GMT+02:00 Cameron Simpson c...@zip.com.au:

 On 23Apr2014 09:39, Pavel Volkov sai...@lists.xtsubasa.org wrote:

 There are some basics about Python objects I don't understand.
 Consider this snippet:

  class X: pass

 ...

  x = X()
 dir(x)

 ['__class__', '__delattr__', '__dict__', '__dir__', '__doc__',
 '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
 '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__',
 '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
 '__str__', '__subclasshook__', '__weakref__']

  x.foo = 11


 And now I want to make a simple object in a shorter way, without
 declaring X class:


If you don't want to go through the usual syntax that defines classes you
can use the equivalent code using type to dynamically create a class:

MyClassObject = type('MyClassObject', (object,), dict())

Mind the fact that MyClassObject is a specific kind of object: a class, a
priori, not harmful in anyway



  y = object()
 dir(y)

 ['__class__', '__delattr__', '__dir__', '__doc__', '__eq__',
 '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
 '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
 '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
 '__subclasshook__']

  y.foo = 12

 Traceback (most recent call last):
 File stdin, line 1, in module
 AttributeError: 'object' object has no attribute 'foo'

 The attribute list is different now and there's no __dict__ and the
 object does not accept new attributes.
 Please explain what's going on.


 The base object class has a fixed set of attributes; you can't add more.


Just like any other builtin type: int, float etc... which also means you
can't add method to them dynamically.

Mind the fact that an instance of object is still useful to implement
efficient SENTINEL objects



 Almost every other class lets you add attributes, but the price for that
 is that it is slightly in memory footprint and slower to access.


class defined in Python except if you define a __slots__



 Look up the __slots__ dunder var in the Python doco index:

   https://docs.python.org/3/glossary.html#term-slots

 You'll see it as a (rarely used, mostly discouraged) way to force a fixed
 set of attributes onto a class. As with object, this brings a smaller
 memory footprint and faster attribute access, but the price is flexibility.


True, still can be the only way to save few MB or... GB without falling
back to C or PyPy.

Have a look at PyPy to how to save memory (and speed things up) without
slots:
http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html

In Python 3 there is a class that is equivalent to:

class foo(object):
pass

simple object with a __dict__, I can't find it anymore and also there is
SimpleNamespacehttps://docs.python.org/3/library/types.html#types.SimpleNamespaceclass.

To sum up:

- If you want to create a sentinel value, use object()
- If you want to create an object to hold values and access them as
attributes, use something like SimpleNamespace


 Cheers,
 Cameron Simpson c...@zip.com.au

 Try being nothing but bored for 4 hours straight, and then tell me that
 there's no fear involved.   - d...@elxr.jpl.nasa.gov (Dave Hayes)
 --
 https://mail.python.org/mailman/listinfo/python-list

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

Re: object().__dict__

[Phil Connell]

On Wed, Apr 23, 2014 at 03:48:32PM +0200, Amirouche Boubekki wrote:
 2014-04-23 8:11 GMT+02:00 Cameron Simpson c...@zip.com.au:
  Look up the __slots__ dunder var in the Python doco index:
 
https://docs.python.org/3/glossary.html#term-slots
 
  You'll see it as a (rarely used, mostly discouraged) way to force a fixed
  set of attributes onto a class. As with object, this brings a smaller
  memory footprint and faster attribute access, but the price is flexibility.
 
 
 True, still can be the only way to save few MB or... GB without falling
 back to C or PyPy.
 
 Have a look at PyPy to how to save memory (and speed things up) without
 slots:
 http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html

Is there any analysis of how this balances increased memory usage from the JIT
vs the CPython VM (with a reasonable amount of code)?

I'd thought that one of the main disadvantages of PyPy was drastically
increased memory usage for any decent-sized program. Would be interested to
know if this was not the case :)


Cheers,
Phil

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

Re: object().__dict__

[Amirouche Boubekki]

2014-04-23 15:59 GMT+02:00 Phil Connell pconn...@gmail.com:

 On Wed, Apr 23, 2014 at 03:48:32PM +0200, Amirouche Boubekki wrote:
  2014-04-23 8:11 GMT+02:00 Cameron Simpson c...@zip.com.au:
   Look up the __slots__ dunder var in the Python doco index:
  
 https://docs.python.org/3/glossary.html#term-slots
  
   You'll see it as a (rarely used, mostly discouraged) way to force a
 fixed
   set of attributes onto a class. As with object, this brings a smaller
   memory footprint and faster attribute access, but the price is
 flexibility.
  
 
  True, still can be the only way to save few MB or... GB without falling
  back to C or PyPy.
 
  Have a look at PyPy to how to save memory (and speed things up) without
  slots:
 
 http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html

 Is there any analysis of how this balances increased memory usage from the
 JIT
 vs the CPython VM (with a reasonable amount of code)?

 I'd thought that one of the main disadvantages of PyPy was drastically
 increased memory usage for any decent-sized program. Would be interested to
 know if this was not the case :)


I have a similar thought, I don't how that memory consumption increase (a
constant? a factor? probably both...)

but if the program use an absurd amount of memory even in CPython then PyPy
will be able to catchup based on comment #1 of a PyPy core dev in
http://tech.oyster.com/save-ram-with-python-slots/ see also
http://pypy.readthedocs.org/en/latest/interpreter-optimizations.html#dictionary-optimizations

Still it requires more analysis. When does PyPy trigger the optimization?




 Cheers,
 Phil

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

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

Re: object().__dict__

[Phil Connell]

On Wed, Apr 23, 2014 at 04:21:26PM +0200, Amirouche Boubekki wrote:
 2014-04-23 15:59 GMT+02:00 Phil Connell pconn...@gmail.com:
 
  On Wed, Apr 23, 2014 at 03:48:32PM +0200, Amirouche Boubekki wrote:
   2014-04-23 8:11 GMT+02:00 Cameron Simpson c...@zip.com.au:
Look up the __slots__ dunder var in the Python doco index:
   
  https://docs.python.org/3/glossary.html#term-slots
   
You'll see it as a (rarely used, mostly discouraged) way to force a
  fixed
set of attributes onto a class. As with object, this brings a smaller
memory footprint and faster attribute access, but the price is
  flexibility.
   
  
   True, still can be the only way to save few MB or... GB without falling
   back to C or PyPy.
  
   Have a look at PyPy to how to save memory (and speed things up) without
   slots:
  
  http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html
 
  Is there any analysis of how this balances increased memory usage from the
  JIT
  vs the CPython VM (with a reasonable amount of code)?
 
  I'd thought that one of the main disadvantages of PyPy was drastically
  increased memory usage for any decent-sized program. Would be interested to
  know if this was not the case :)
 
 
 I have a similar thought, I don't how that memory consumption increase (a
 constant? a factor? probably both...)
 
 but if the program use an absurd amount of memory even in CPython then PyPy
 will be able to catchup based on comment #1 of a PyPy core dev in
 http://tech.oyster.com/save-ram-with-python-slots/ see also
 http://pypy.readthedocs.org/en/latest/interpreter-optimizations.html#dictionary-optimizations

Absolutely. For long-running code manipulating large amounts of data I can
imagine the PyPy optimisations being a win.

On the other hand, if the code/data ratio is larger, CPython may well win in
terms of memory use.


 
 Still it requires more analysis. When does PyPy trigger the optimization?

Indeed. Without measuring this is all idle speculation ;)


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

Re: object().__dict__

[CHIN Dihedral]

On Wednesday, April 23, 2014 10:21:26 PM UTC+8, Amirouche Boubekki wrote:
 2014-04-23 15:59 GMT+02:00 Phil Connell pcon...@gmail.com:
 
 
 
 On Wed, Apr 23, 2014 at 03:48:32PM +0200, Amirouche Boubekki wrote:
 
  2014-04-23 8:11 GMT+02:00 Cameron Simpson c...@zip.com.au:
 
 
   Look up the __slots__ dunder var in the Python doco index:
 
  
 
     https://docs.python.org/3/glossary.html#term-slots
 
  
 
   You'll see it as a (rarely used, mostly discouraged) way to force a fixed
 
   set of attributes onto a class. As with object, this brings a smaller
 
   memory footprint and faster attribute access, but the price is 
   flexibility.
 
  
 
 
 
  True, still can be the only way to save few MB or... GB without falling
 
  back to C or PyPy.
 
 
 
  Have a look at PyPy to how to save memory (and speed things up) without
 
  slots:
 
  http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html
 
 
 
 Is there any analysis of how this balances increased memory usage from the JIT
 
 vs the CPython VM (with a reasonable amount of code)?
 
 
 
 I'd thought that one of the main disadvantages of PyPy was drastically
 
 increased memory usage for any decent-sized program. Would be interested to
 
 know if this was not the case :)
 
 
 
 I have a similar thought, I don't how that memory consumption increase (a 
 constant? a factor? probably both...)
 
 but if the program use an absurd amount of memory even in CPython then PyPy 
 will be able to catchup based on comment #1 of a PyPy core dev in 
 http://tech.oyster.com/save-ram-with-python-slots/ see also 
 http://pypy.readthedocs.org/en/latest/interpreter-optimizations.html#dictionary-optimizations
 
 
 
 
 Still it requires more analysis. When does PyPy trigger the optimization?
 
  
 
 
 
 
 
 
 Cheers,
 
 Phil
 
 
 
 --
 
 https://mail.python.org/mailman/listinfo/python-list

 The auto-code generation  of valid python codes in PyPy is helpful in CAD/CAM 
and non-idiot robot brains.
-- 
https://mail.python.org/mailman/listinfo/python-list

object().__dict__

[Pavel Volkov]

There are some basics about Python objects I don't understand.
Consider this snippet:


class X: pass
... 

x = X()
dir(x)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', 
'__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__']

x.foo = 11


And now I want to make a simple object in a shorter way, without declaring 
X class:



y = object()
dir(y)
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', 
'__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', 
'__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', 
'__setattr__', '__sizeof__', '__str__', '__subclasshook__']

y.foo = 12

Traceback (most recent call last):
 File stdin, line 1, in module
AttributeError: 'object' object has no attribute 'foo'

The attribute list is different now and there's no __dict__ and the object 
does not accept new attributes.

Please explain what's going on.

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