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

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

Read-only attribute in module

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

Contents

  Read-only attribute in module Mateusz Loskot <mateusz@loskot.net> - 2012-02-09 11:43 +0000
    Re: Read-only attribute in module Ben Finney <ben+python@benfinney.id.au> - 2012-02-09 23:32 +1100
      Re: Read-only attribute in module mloskot <mateusz@loskot.net> - 2012-02-09 08:44 -0800
      Re: Read-only attribute in module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-10 01:04 +0000
        Re: Read-only attribute in module Terry Reedy <tjreedy@udel.edu> - 2012-02-09 22:27 -0500
          Re: Read-only attribute in module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-10 22:23 +0000
        Re: Read-only attribute in module Arnaud Delobelle <arnodel@gmail.com> - 2012-02-10 10:09 +0000

#20069 — Read-only attribute in module

Hi,

I'm implementing Python 3 extension using the Python C API.
I am familiar with defining new types, implementing get/set for attributes, etc.

I'm wondering, is there any mean to implement attribute in module
scope which is read-only?

So, the following

import xyz
print(xyz.flag)  # OK
xyz.flag = 0    # error due to no write access

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

[toc] | [next] | [standalone]

#20070

Mateusz Loskot <mateusz@loskot.net> writes:

> I'm wondering, is there any mean to implement attribute in module
> scope which is read-only?

Python is designed by and for consenting adults. Rather than
restricting, instead use conventions to make your intent clear to the
user of your library.

> So, the following
>
> import xyz
> print(xyz.flag)  # OK
> xyz.flag = 0    # error due to no write access

PEP 8 <URL:http://www.python.org/dev/peps/pep-0008/> gives the style
guide for Python code (strictly for the standard library, but it is
recommended for all Python code).

If you want a module attribute that is intended to remain bound to the
same value, use PEP 8's recommendation and name the attribute in
‘ALL_UPPER_CASE’.

If you want an attribute that is intended only for internal use (an
implementation detail that should not be relied upon outside the
library), use PEP 8's recommendation and name the attribute with a
‘_single_leading_underscore’.

-- 
 \       “We jealously reserve the right to be mistaken in our view of |
  `\      what exists, given that theories often change under pressure |
_o__)              from further investigation.” —Thomas W. Clark, 2009 |
Ben Finney

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

#20087

Ben Finney-10 wrote
> 
> Mateusz Loskot <mateusz@> writes:
> 
>> So, the following
>>
>> import xyz
>> print(xyz.flag)  # OK
>> xyz.flag = 0    # error due to no write access
> 
> PEP 8 <URL:http://www.python.org/dev/peps/pep-0008/> gives the style
> guide for Python code (strictly for the standard library, but it is
> recommended for all Python code).
> 

Ben,

That's what I thought really.
Thank you for confirming the sanity of the style-powered conventions.

Best regards,

-----
-- 
Mateusz Loskot
http://mateusz.loskot.net
--
View this message in context: http://python.6.n6.nabble.com/Read-only-attribute-in-module-tp4378950p4380150.html
Sent from the Python - python-list mailing list archive at Nabble.com.

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

#20125

On Thu, 09 Feb 2012 23:32:59 +1100, Ben Finney wrote:

> Mateusz Loskot <mateusz@loskot.net> writes:
> 
>> I'm wondering, is there any mean to implement attribute in module scope
>> which is read-only?
> 
> Python is designed by and for consenting adults. Rather than
> restricting, instead use conventions to make your intent clear to the
> user of your library.

Oh I agree. The convention I want to use to make my intent clear is the 
same convention used for the rest of Python: a runtime exception.

I find this "consenting adults" argument less than convincing. We already 
have constants in Python -- every int and float and string is a constant. 
You can't modify the object 1 to have the value 42, and for very good 
reason, "consenting adults" be damned.

What we don't have is *named* constants.

Python has no shortage of read-only values and members, e.g.:

>>> class A(object):
...     pass
...
>>> A.__dict__ = {}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: attribute '__dict__' of 'type' objects is not writable


Consider this:

If you pass an int to len(), you get a runtime error telling you that you 
did something wrong. Does this violate "consenting adults"? No, if you 
want to, you can monkey-patch len to accept ints, but you have to work at 
it. The normal behaviour is to get an error, not some arbitrary but 
meaningless behaviour. You certainly don't get told to use a naming 
convention (Hungarian notation, perhaps) to avoid passing the wrong value 
to len().

If you assign to something which is intended to be constant, you don't 
get an exception telling you that you made a mistake. Instead, you get 
unspecified (but almost certainly incorrect) behaviour in the module, and 
told to use a naming convention to remind you not to screw up.

The excuse given is that Python is for "consenting adults", but I don't 
believe it. I believe that the real reason is that it is hard to 
introduce named constants to Python, and rather than solve that hard 
problem, people just whitewash the issue and pretend that it's a feature. 
It's not a feature, it's a wart. There is no conceivable use-case for 
allowing math.pi = 2.5 to succeed.

Python happily violates "consenting adults" all over the place. We have 
properties, which can easily create read-only and write-once attributes. 
We have descriptors which can be used for the same. We have immutable 
types, and constant values, but not constant names.

Python can enforce all common software contracts I can think of, except 
the contract that a name will be set to a specific value. And that is, in 
my opinion, a weakness in Python.


-- 
Steven

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

#20134

On 2/9/2012 8:04 PM, Steven D'Aprano wrote:

> Python happily violates "consenting adults" all over the place. We have
> properties, which can easily create read-only and write-once attributes.

So propose that propery() work at module level, for module attributes, 
as well as for class attributes.

-- 
Terry Jan Reedy

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

#20197

On Thu, 09 Feb 2012 22:27:50 -0500, Terry Reedy wrote:

> On 2/9/2012 8:04 PM, Steven D'Aprano wrote:
> 
>> Python happily violates "consenting adults" all over the place. We have
>> properties, which can easily create read-only and write-once
>> attributes.
> 
> So propose that propery() work at module level, for module attributes,
> as well as for class attributes.


I'm not wedded to a specific implementation.

Besides, it's not just a matter of saying "property should work in 
modules" -- that would require the entire descriptor protocol work for 
module lookups, and I don't know how big a can of worms that is. Constant 
names is a lot more constrained than computed name lookups.



-- 
Steven

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

#20152

On 10 February 2012 03:27, Terry Reedy <tjreedy@udel.edu> wrote:
> On 2/9/2012 8:04 PM, Steven D'Aprano wrote:
>
>> Python happily violates "consenting adults" all over the place. We have
>> properties, which can easily create read-only and write-once attributes.
>
>
> So propose that propery() work at module level, for module attributes, as
> well as for class attributes.

I think Steven would like something else: bare names that cannot be
rebound. E.g. something like:

>>> const a = 42
>>> a = 7

Would raise an exception.  Is that right?

-- 
Arnaud

[toc] | [prev] | [standalone]

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

csiph-web