Read-only attribute in module

Discussion in 'Python' started by Mateusz Loskot, Feb 9, 2012.

  1. 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
     
    Mateusz Loskot, Feb 9, 2012
    #1
    1. Advertising

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

    > Mateusz Loskot <> 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
     
    Steven D'Aprano, Feb 10, 2012
    #2
    1. Advertising

  3. Mateusz Loskot

    Terry Reedy Guest

    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
     
    Terry Reedy, Feb 10, 2012
    #3
  4. On 10 February 2012 03:27, 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 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
     
    Arnaud Delobelle, Feb 10, 2012
    #4
  5. 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
     
    Steven D'Aprano, Feb 10, 2012
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ferro
    Replies:
    2
    Views:
    372
    Adam Maass
    Nov 1, 2003
  2. Brian Genisio

    Read Only Attribute?

    Brian Genisio, Jan 8, 2004, in forum: C++
    Replies:
    7
    Views:
    424
    Howard
    Jan 14, 2004
  3. keithb
    Replies:
    2
    Views:
    8,069
    keithb
    Jun 7, 2006
  4. johnny
    Replies:
    5
    Views:
    755
    johnny
    Dec 10, 2006
  5. Replies:
    3
    Views:
    1,607
    Brandon McCombs
    May 2, 2007
Loading...

Share This Page