Accessors in Python (getters and setters)

Discussion in 'Python' started by mystilleef, Jul 10, 2006.

  1. mystilleef

    mystilleef Guest

    Hello,

    What is the Pythonic way of implementing getters and setters. I've
    heard
    people say the use of accessors is not Pythonic. But why? And what is
    the alternative? I refrain from using them because they smell
    "Javaish."
    But now my code base is expanding and I'm beginning to appreciate the
    wisdom behind them. I welcome example code and illustrations.

    Regards
     
    mystilleef, Jul 10, 2006
    #1
    1. Advertising

  2. mystilleef <> wrote:

    > What is the Pythonic way of implementing getters and setters.


    Using public members and turning them into properties when needed

    > I've
    > heard
    > people say the use of accessors is not Pythonic. But why?


    Because there's no need to have them everywhere

    > But now my code base is expanding and I'm beginning to appreciate the
    > wisdom behind them. I welcome example code and illustrations.


    Search for "python property"

    --
    Lawrence - http://www.oluyede.org/blog
    "Nothing is more dangerous than an idea
    if it's the only one you have" - E. A. Chartier
     
    Lawrence Oluyede, Jul 10, 2006
    #2
    1. Advertising

  3. mystilleef wrote:

    > Hello,
    >
    > What is the Pythonic way of implementing getters and setters. I've
    > heard
    > people say the use of accessors is not Pythonic. But why? And what is
    > the alternative? I refrain from using them because they smell
    > "Javaish."
    > But now my code base is expanding and I'm beginning to appreciate the
    > wisdom behind them. I welcome example code and illustrations.


    Which wisdom do you mean? The wisdom that a language that has no property
    mechanism and thus can't intercept setting and getting of instance members
    needs a bulky convention called JAVA Beans, so that _all_ uses of
    properties are tunneled through some code, even if only a few percent of
    these actually need that?

    Or the wisdom that strangling developers by putting access modifiers with
    approx. a dozen different rules in place is an annoyance to adult
    developers to say the least?

    These are the reasons they are not pythonic. We can intercept property
    access (see the property descriptor, http://pyref.infogami.com/property),
    and we trust in developers being able to judge form themselves if messing
    with internals of code is a good idea or not.

    Regards,

    Diez
     
    Diez B. Roggisch, Jul 10, 2006
    #3
  4. mystilleef

    mystilleef Guest

    I decided to change the name of an attribute. Problem is I've used the
    attribute in several places spanning thousands of lines of code. If I
    had encapsulated the attribute via an accessor, I wouldn't need to do
    an unreliable and tedious search and replace accross several source
    code files to achieve my goal. I could simply change the name of the
    attribute and move on. Well, I'm glad python has properties. It's a
    feature that should be advertised more, especially for large scale
    python development.

    Diez B. Roggisch wrote:
    > mystilleef wrote:
    >
    > > Hello,
    > >
    > > What is the Pythonic way of implementing getters and setters. I've
    > > heard
    > > people say the use of accessors is not Pythonic. But why? And what is
    > > the alternative? I refrain from using them because they smell
    > > "Javaish."
    > > But now my code base is expanding and I'm beginning to appreciate the
    > > wisdom behind them. I welcome example code and illustrations.

    >
    > Which wisdom do you mean? The wisdom that a language that has no property
    > mechanism and thus can't intercept setting and getting of instance members
    > needs a bulky convention called JAVA Beans, so that _all_ uses of
    > properties are tunneled through some code, even if only a few percent of
    > these actually need that?
    >
    > Or the wisdom that strangling developers by putting access modifiers with
    > approx. a dozen different rules in place is an annoyance to adult
    > developers to say the least?
    >
    > These are the reasons they are not pythonic. We can intercept property
    > access (see the property descriptor, http://pyref.infogami.com/property),
    > and we trust in developers being able to judge form themselves if messing
    > with internals of code is a good idea or not.
    >
    > Regards,
    >
    > Diez
     
    mystilleef, Jul 10, 2006
    #4
  5. mystilleef

    Ant Guest

    mystilleef wrote:
    > I decided to change the name of an attribute. Problem is I've used the
    > attribute in several places spanning thousands of lines of code. If I
    > had encapsulated the attribute via an accessor, I wouldn't need to do
    > an unreliable and tedious search and replace accross several source
    > code files to achieve my goal. I could simply change the name of the
    > attribute and move on.


    You could, but then you'd be left with crap names for your accessors!
    In your equivalent Java code, you'd typically have used the accessors
    in several places throughout the code (or else why bother using them?),
    so you wouldn't be any better off!

    The main benefit for having accessors in Java is not that you can
    change the *name* of an attribute, but that you can change the
    implementation of the attribute - i.e. change the what actually happens
    to when the accessor is called. Which you can do in Python with
    properties.
     
    Ant, Jul 10, 2006
    #5
  6. mystilleef wrote:

    > I decided to change the name of an attribute. Problem is I've used the
    > attribute in several places spanning thousands of lines of code. If I
    > had encapsulated the attribute via an accessor, I wouldn't need to do
    > an unreliable and tedious search and replace accross several source
    > code files to achieve my goal. I could simply change the name of the
    > attribute and move on. Well, I'm glad python has properties. It's a
    > feature that should be advertised more, especially for large scale
    > python development.


    Ergh, I don't see how the name-changing of an attribute makes any difference
    with respect to the application of getters/setters.

    Where is the difference in searching my_attribute vs. getMyAttribute
    throughout your code?

    Or do you mean that you changed

    def getFoo(self):
    return self.foo

    to something like

    def getFoo(self):
    return self.fooSomething

    ? I'd say that whatever reasoning which inspired you to change foo to
    fooSomething applies to getFoo as well.

    Regards,

    Diez
     
    Diez B. Roggisch, Jul 10, 2006
    #6
  7. mystilleef wrote:
    > I decided to change the name of an attribute. Problem is I've used the
    > attribute in several places spanning thousands of lines of code. If I
    > had encapsulated the attribute via an accessor, I wouldn't need to do
    > an unreliable and tedious search and replace


    find and grep are usually mostly reliable for this kind of tasks.

    > accross several source
    > code files to achieve my goal. I could simply change the name of the
    > attribute and move on.


    Why did you change the name of the attribute ? If it was to better
    reflect the semantic, then it's a change in the API and getters/setters
    wouldn't have help (you'd have to do the same "tedious and unreliable"
    search/replace dance). If it's about implementation, then it was time to
    use a property - that's what they are for.

    --
    bruno desthuilliers
    python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    p in ''.split('@')])"
     
    Bruno Desthuilliers, Jul 10, 2006
    #7
  8. mystilleef

    Jason Guest

    mystilleef wrote:
    > I decided to change the name of an attribute. Problem is I've used the
    > attribute in several places spanning thousands of lines of code. If I
    > had encapsulated the attribute via an accessor, I wouldn't need to do
    > an unreliable and tedious search and replace accross several source
    > code files to achieve my goal. I could simply change the name of the
    > attribute and move on. Well, I'm glad python has properties. It's a
    > feature that should be advertised more, especially for large scale
    > python development.
    >
    > Diez B. Roggisch wrote:
    > > mystilleef wrote:
    > >
    > > > Hello,
    > > >
    > > > What is the Pythonic way of implementing getters and setters. I've
    > > > heard
    > > > people say the use of accessors is not Pythonic. But why? And what is
    > > > the alternative? I refrain from using them because they smell
    > > > "Javaish."
    > > > But now my code base is expanding and I'm beginning to appreciate the
    > > > wisdom behind them. I welcome example code and illustrations.

    > >
    > > Which wisdom do you mean? The wisdom that a language that has no property
    > > mechanism and thus can't intercept setting and getting of instance members
    > > needs a bulky convention called JAVA Beans, so that _all_ uses of
    > > properties are tunneled through some code, even if only a few percent of
    > > these actually need that?
    > >
    > > Or the wisdom that strangling developers by putting access modifiers with
    > > approx. a dozen different rules in place is an annoyance to adult
    > > developers to say the least?
    > >
    > > These are the reasons they are not pythonic. We can intercept property
    > > access (see the property descriptor, http://pyref.infogami.com/property),
    > > and we trust in developers being able to judge form themselves if messing
    > > with internals of code is a good idea or not.
    > >
    > > Regards,
    > >
    > > Diez


    The property() mechanism gets rid of the need for getters and setters,
    as you can invisibly change a member variable into a getter/setter as
    needed. Nothing else needs to know that its using a property and not a
    getter/setter.

    Nothing like being forced to write getters and setters in C++/Java
    before you feel like shooting your source code. Please don't bring
    this code-rage into Python.

    To refactor a name in your code, take a look at Bicycle Repair Man
    [http://bicyclerepair.sourceforge.net/]. It integrates into Eclipse
    via PyDev, and allows you to refactor variable names, class names, and
    method names fairly easily.

    Good luck!

    --Jason
     
    Jason, Jul 10, 2006
    #8
  9. mystilleef

    ZeD Guest

    Bruno Desthuilliers wrote:

    >> I decided to change the name of an attribute. Problem is I've used the
    >> attribute in several places spanning thousands of lines of code. If I
    >> had encapsulated the attribute via an accessor, I wouldn't need to do
    >> an unreliable and tedious search and replace

    > find and grep are usually mostly reliable for this kind of tasks.


    you mean sed :)

    sed 's/oldName/newName/g' oldFile > newFile

    --
    Under construction
     
    ZeD, Jul 11, 2006
    #9
  10. ZeD wrote:
    > Bruno Desthuilliers wrote:
    >
    >
    >>>I decided to change the name of an attribute. Problem is I've used the
    >>>attribute in several places spanning thousands of lines of code. If I
    >>>had encapsulated the attribute via an accessor, I wouldn't need to do
    >>>an unreliable and tedious search and replace

    >>
    >>find and grep are usually mostly reliable for this kind of tasks.

    >
    >
    > you mean sed :)


    No, I meant find and grep.

    > sed 's/oldName/newName/g' oldFile > newFile
    >

    Yeah, fine - as long as your pretty sure the same name is not used in
    other contexts in any of the source files...

    --
    bruno desthuilliers
    python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    p in ''.split('@')])"
     
    Bruno Desthuilliers, Jul 11, 2006
    #10
  11. mystilleef

    mystilleef Guest

    Hello,

    Thanks for the responses. The reason I want to change the name of the
    attribute is because it doesn't reflect the purpose of the attribute,
    anymore. The attribute was originally a string object, but not anymore.
    It is primarily a readability issue. There are also a few key
    attributes I don't want developers, including myself, fiddling with.
    Properties /accessors are good because they allow you to encapsulate
    attributes so you can change implementations at will. Some of you have
    argued I would have needed to change accessor names too if I had
    misnamed them earlier. It's hard to say. I find myself changing the
    names of attributes a lot more frequently than I do functions or
    methods. Choosing a crappy attribute name is effortless for me,
    especially during intense coding sessions. I usually realize I've
    choosing a crappy attribute name the next day, sometimes even later.
    However, I put a lot more effort into choosing method and function
    names, especially when I know it may likely be a public API. Plus it's
    really hard to choose crappy accessor name.

    Regards
     
    mystilleef, Jul 11, 2006
    #11
  12. mystilleef wrote:
    > Hello,
    >
    > Thanks for the responses. The reason I want to change the name of the
    > attribute is because it doesn't reflect the purpose of the attribute,
    > anymore. The attribute was originally a string object, but not anymore.
    > It is primarily a readability issue. There are also a few key
    > attributes I don't want developers, including myself, fiddling with.
    > Properties /accessors are good because they allow you to encapsulate
    > attributes so you can change implementations at will. Some of you have
    > argued I would have needed to change accessor names too if I had
    > misnamed them earlier. It's hard to say. I find myself changing the
    > names of attributes a lot more frequently than I do functions or
    > methods. Choosing a crappy attribute name is effortless for me,
    > especially during intense coding sessions. I usually realize I've
    > choosing a crappy attribute name the next day, sometimes even later.
    > However, I put a lot more effort into choosing method and function
    > names, especially when I know it may likely be a public API.


    What you need to understand here is that in Python,
    1/ methods *are* attributes
    2/ every attribute whose name is not prefixed by a leading underscore is
    considered part of the api ('__magic__' names being a special case).

    So it has nothing to do with "data vs method" dichotomy (which makes no
    sens in a languages where functions and methods are objects), only with
    "API vs implementation". You choosed a crappy name for an attribute
    that's part of the API, so it's *exactly* the same case as if you had
    chosen a crappy name for a public method in Java. Think of public "data"
    attributes as magical getter/setters with the most straightforward
    behaviour, and of properties as the way to override this default behaviour.

    > Plus it's
    > really hard to choose crappy accessor name.


    What about getMyCrappyAttributeName/setMyCrappyAttributeName ?-)



    --
    bruno desthuilliers
    python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    p in ''.split('@')])"
     
    Bruno Desthuilliers, Jul 11, 2006
    #12
  13. mystilleef

    mystilleef Guest

    Lousy Attribute Name:
    self.tmp

    Accessors:
    set_temporary_buffer
    get_temporary_buffer

    The attribute name I chose, "tmp" sucks. I have used that name in
    dozens of places spanning over 27000 LOC. There's a chance that other
    develops might misinterpret exactly what "tmp" does. Plus I don't want
    emails from other developers querying me about what "tmp" is/does.
    "tmp" is obvious to me, but not necessarily to others. Now compare that
    to the accessors. Not only do they improve readability at the expense
    of more code, they actually allow me to change the lousily named
    attribute "tmp" to "temporary_buffer" without grepping, seding,
    searching, replacing and praying. Sure, if you are dealing with less
    than a 1000LOC you can get away with using "tmp" or renaming it easily.
    But if you are dealing with a much larger code base and more
    developers, issues like this rapidly become a nuisance.

    Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
    But developers tend to pay more attention to given methods/functions
    less crappy names, at least when compared to data attributes. This
    stems from the fact that in many languages data attributes aren't
    usually part of the API, as well as the whole OO(Encapsulation) blah
    blah. I know I would not name the accessors set_tmp/get_tmp, because my
    philosophy is that methods/functions need to have meaningful names and
    state their intended purpose. I don't hold data attributes to such
    standards and I imagine many developers don't either and least based on
    other people's code I've read. Plus there are many occassions when
    attributes are not intended to be APIs, but eventually become one.
    After all most data attributes are created with the purpose of serving
    methods.

    Bruno Desthuilliers wrote:
    > mystilleef wrote:
    > > Hello,
    > >
    > > Thanks for the responses. The reason I want to change the name of the
    > > attribute is because it doesn't reflect the purpose of the attribute,
    > > anymore. The attribute was originally a string object, but not anymore.
    > > It is primarily a readability issue. There are also a few key
    > > attributes I don't want developers, including myself, fiddling with.
    > > Properties /accessors are good because they allow you to encapsulate
    > > attributes so you can change implementations at will. Some of you have
    > > argued I would have needed to change accessor names too if I had
    > > misnamed them earlier. It's hard to say. I find myself changing the
    > > names of attributes a lot more frequently than I do functions or
    > > methods. Choosing a crappy attribute name is effortless for me,
    > > especially during intense coding sessions. I usually realize I've
    > > choosing a crappy attribute name the next day, sometimes even later.
    > > However, I put a lot more effort into choosing method and function
    > > names, especially when I know it may likely be a public API.

    >
    > What you need to understand here is that in Python,
    > 1/ methods *are* attributes
    > 2/ every attribute whose name is not prefixed by a leading underscore is
    > considered part of the api ('__magic__' names being a special case).
    >
    > So it has nothing to do with "data vs method" dichotomy (which makes no
    > sens in a languages where functions and methods are objects), only with
    > "API vs implementation". You choosed a crappy name for an attribute
    > that's part of the API, so it's *exactly* the same case as if you had
    > chosen a crappy name for a public method in Java. Think of public "data"
    > attributes as magical getter/setters with the most straightforward
    > behaviour, and of properties as the way to override this default behaviour.
    >
    > > Plus it's
    > > really hard to choose crappy accessor name.

    >
    > What about getMyCrappyAttributeName/setMyCrappyAttributeName ?-)
    >
    >
    >
    > --
    > bruno desthuilliers
    > python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    > p in ''.split('@')])"
     
    mystilleef, Jul 12, 2006
    #13
  14. Le mercredi 12 juillet 2006 11:17, mystilleef a écrit :
    > Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
    > But developers tend to pay more attention to given methods/functions
    > less crappy names, at least when compared to data attributes.

    Not python developers.

    > This
    > stems from the fact that in many languages data attributes aren't
    > usually part of the API, as well as the whole OO(Encapsulation) blah
    > blah. I know I would not name the accessors set_tmp/get_tmp, because my
    > philosophy is that methods/functions need to have meaningful names and
    > state their intended purpose.

    But that's not python philosophy.

    > I don't hold data attributes to such
    > standards and I imagine many developers don't either and least based on
    > other people's code I've read. Plus there are many occassions when
    > attributes are not intended to be APIs, but eventually become one.

    But they are in Python and that is the python's philosophy. All attribute or
    method not beginning with an '_' *is* API.

    > After all most data attributes are created with the purpose of serving
    > methods.

    And in python the reverse can be true :

    class a(object) :
    def __init__(self, ro_attr) : self.__attr = ro_attr
    def _getAttr(self) :
    """A method which serves an attribute"""
    return self.__attr
    attr = property(_getAttr)




    --
    _____________

    Maric Michaud
    _____________

    Aristote - www.aristote.info
    3 place des tapis
    69004 Lyon
    Tel: +33 426 880 097
     
    Maric Michaud, Jul 12, 2006
    #14
  15. mystilleef wrote:
    > Lousy Attribute Name:
    > self.tmp
    >
    > Accessors:
    > set_temporary_buffer
    > get_temporary_buffer
    >
    > The attribute name I chose, "tmp" sucks.


    Well, it's surely not as descriptive as 'temporary_buffer'

    > I have used that name in
    > dozens of places spanning over 27000 LOC.


    Too bad for you.

    > There's a chance that other
    > develops might misinterpret exactly what "tmp" does. Plus I don't want
    > emails from other developers querying me about what "tmp" is/does.
    > "tmp" is obvious to me, but not necessarily to others.


    So why did you name it that way at first ?

    > Now compare that
    > to the accessors.


    But 'tmp' actually *is* an accessor.

    > Not only do they improve readability


    Err... do you find:

    obj.set_temporary_buffer(val)
    val = obj.get_temporary_buffer()

    really more readable than:

    obj.temporary_buffer = val
    val = obj.temporary_buffer


    > at the expense
    > of more code,


    Indeed. In both the class and client code.

    > they actually allow me to change the lousily named
    > attribute "tmp" to "temporary_buffer" without grepping, seding,
    > searching, replacing and praying.


    You still fail to get the point. You actually choose a crappy name for a
    *public* property. It's *exactly* as if, in Java, you had named your
    getter/setter 'get_tmp' and 'set_tmp'.

    > Sure, if you are dealing with less
    > than a 1000LOC you can get away with using "tmp" or renaming it easily.
    > But if you are dealing with a much larger code base and more
    > developers, issues like this rapidly become a nuisance.


    Indeed. But it's *your* responsability to choose good names for the API.

    > Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).

    or 'tmp'.

    > But developers tend to pay more attention to given methods/functions
    > less crappy names, at least when compared to data attributes.


    s/developpers/you/

    > This
    > stems from the fact that in many languages data attributes aren't
    > usually part of the API,


    Once again, in Python, there is *no* such thing as 'data attributes'.
    *All* attributes are *objects* - some of them callable.

    > as well as the whole OO(Encapsulation) blah
    > blah.


    Don't confuse encapsulation with data-hiding.

    > I know I would not name the accessors set_tmp/get_tmp, because my
    > philosophy is that methods/functions need to have meaningful names and
    > state their intended purpose.


    That's true for each and every name in a program.

    > I don't hold data attributes to such
    > standards


    Too bad for you.

    > and I imagine many developers don't either and least based on
    > other people's code I've read. Plus there are many occassions when
    > attributes are not intended to be APIs,


    Then mark them as being implementation (ie : prefix them with a single
    underscore).

    > but eventually become one.
    > After all most data attributes are created with the purpose of serving
    > methods.


    Nope. You have the class API, and the class implementation. Both made of
    both callable and non-callable attributes.

    Mystilleef, I do share your pain (really - been here, done that,
    etc...), and I understand that grasping Python requires some mental
    adjustments when coming from Java and friends (been here, done that,
    etc...). But you seriously can't blame the language for your own mistakes.

    If you intented 'tmp' to be part of the API, then you're responsible for
    the bad naming. If you didn't, then you're responsible for breaking the
    encapsulation - FWIW, following the convention (single leading
    underscore) could have make it clearer to you. In both cases, you
    happily used a bad name in 27 KLOC - so you really had a lot of time and
    occasions to notice something wrong with this.

    --
    bruno desthuilliers
    python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    p in ''.split('@')])"
     
    Bruno Desthuilliers, Jul 12, 2006
    #15
  16. On 2006-07-12 06:17:27, mystilleef wrote:

    > But developers tend to pay more attention to given methods/functions
    > less crappy names, at least when compared to data attributes. This
    > stems from the fact that in many languages data attributes aren't
    > usually part of the API, as well as the whole OO(Encapsulation) blah
    > blah.


    I'm not sure about which languages you are talking (pretty much all that
    allow public methods also allow public attributes), but in general I think
    you should get away from the distinction attribute vs method (which doesn't
    make much sense in any language) and start looking at the distinction
    public vs private (which is what you really are talking about) -- and start
    giving the appropriate care to naming public entities, no matter /what/
    they are. (Besides, I don't know many coding rules that say that creating
    an accessor get/setTemporaryBuffer that acts on the private member tmp is
    good style.)

    I'm just starting to get started with Python, but it seems that the leading
    underscore marks private entities. So why don't you precede everything with
    an underscore that doesn't have a name that fulfills your criteria for a
    decent public name -- no matter what kind of entity it is?

    It seems you are basically complaining that you used a crappy name in a
    public API. Well... you shouldn't, not in Python, and not in any other
    language :) And there's no way around it, not in Python, and not in any
    other language, than to rename that entity in the public API. Which can be
    a major hassle, close to impossible. There are all kinds of public APIs
    with crappy names (using accessors and all :) that got created early on and
    never changed. Stuff happens.

    Maybe you didn't know about the underscore way to mark private entities.
    Maybe this doesn't work as I think it does (from reading this thread). But
    maybe it does, and maybe that's then just part of the learning curve for
    you. (And I'm sure you're not alone... :)

    Gerhard
     
    Gerhard Fiedler, Jul 12, 2006
    #16
  17. mystilleef

    Ant Guest


    > Yes, it is possible to name crappy accessors too (e.g set_tmp/get_tmp).
    > But developers tend to pay more attention to given methods/functions
    > less crappy names, at least when compared to data attributes. This


    In my experience of getters and setters in Java, most developers choose
    attribute names first, and then use the IDE (Java without an IDE
    *really* sucks) to auto-generate the getters and setters. So most Java
    developers I have worked with pay more attention to attributes than
    accessor names as these are derived anyway. So I guess it depends on
    who the developers are ;-)
     
    Ant, Jul 12, 2006
    #17
  18. On Wed, 12 Jul 2006 08:58:17 -0300, Gerhard Fiedler <>
    declaimed the following in comp.lang.python:

    > I'm just starting to get started with Python, but it seems that the leading
    > underscore marks private entities. So why don't you precede everything with


    It is a convention that signals the intent of the attribute is to be
    private. Nothing in Python enforces a distinction. Double underscores
    invoke name-mangling to allow for access to parent class members that
    might otherwise be shadowed.


    --
    Wulfraed Dennis Lee Bieber KD6MOG

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
     
    Dennis Lee Bieber, Jul 13, 2006
    #18
  19. Gerhard Fiedler <> wrote:
    ...
    > I'm not sure about which languages you are talking (pretty much all that
    > allow public methods also allow public attributes), but in general I think


    Smalltalk is a very well known object-oriented language that behaves
    otherwise, just as one example.


    Alex
     
    Alex Martelli, Jul 13, 2006
    #19
  20. mystilleef

    mystilleef Guest

    Maric Michaud wrote:
    > Not python developers.

    Nonsense!
    > But that's not python philosophy.

    Python doesn't have any philosophy with regards to naming identifiers.

    > But they are in Python and that is the python's philosophy. All attribute or
    > method not beginning with an '_' *is* API.

    Right, and what if I want to change a private API to a public one. How
    does that solve my naming issues.
    > And in python the reverse can be true :

    The reverse is hardly ever true. 90% of public APIs in almost all
    languages are methods or functions.
     
    mystilleef, Jul 13, 2006
    #20
    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. =?ISO-8859-1?Q?Petter_Holmstr=F6m?=

    Getters and setters in python, common practise

    =?ISO-8859-1?Q?Petter_Holmstr=F6m?=, Apr 15, 2004, in forum: Python
    Replies:
    8
    Views:
    500
  2. Daniel Fetchinson

    setters and getters in python 2.6 and 3.0

    Daniel Fetchinson, Nov 29, 2007, in forum: Python
    Replies:
    2
    Views:
    595
    Daniel Fetchinson
    Nov 29, 2007
  3. TechieInsights
    Replies:
    5
    Views:
    370
    josh logan
    Feb 12, 2009
  4. Lachlan Hunt
    Replies:
    2
    Views:
    172
    Lachlan Hunt
    Mar 28, 2005
  5. Fernando Saldanha

    Python getters and setters

    Fernando Saldanha, Aug 17, 2013, in forum: Python
    Replies:
    7
    Views:
    127
    Fernando Saldanha
    Aug 18, 2013
Loading...

Share This Page