Steven Miales extensions
sbr...@ibm.net
Hi,
I found the paper from Steven Miale (thesis-miale.ps, 1993) on the python ftp-server.
He made some interesting extensions to the object model of python. One of this
extensions makes it possible to have protected class members (methods and attributes).
I understood that his extensions made their way into the official python release, but
his examples don't work with my python interpreter (version 1.3 for OS/2).
It would be nice to have private methods and attributes. Is there perhaps another
way to get protected members?
Stefan
Peter Munnings
Stefan (sbr...@ibm.net) wrote:
> Hi,
> I found the paper from Steven Miale (thesis-miale.ps, 1993) on the python
> ftp-server.
> He made some interesting extensions to the object model of python. One of
> this extensions makes it possible to have protected class members (methods
> and attributes).
The 'access' keyword has been officially declared defunct.
> I understood that his extensions made their way into the official python
> release, but his examples don't work with my python interpreter (version
> 1.3 for OS/2).
>
> It would be nice to have private methods and attributes. Is there perhaps
> another way to get protected members?
>
I posted a set of patches a few days ago (look for 'Private scopes in Python')
which provides private member functions and member variables in Python.
This differs from Steven's mod in the following ways:
In Steven's version, you use the access keyword to declare access rights,
wheareas in mine, the variable name is prefixed with a '.', e.g.
class Shape:
def move(self):
self.flag = 42
return self..doit() # calling the private member fn
def .doit(self): # private member fn
self..priv_flag = 99 # private member var
In my version, private data has it's own scope, so that name clashes will not
occur if a private with the same name is used in a subclass. For example:
class Square(Shape):
def .doit(self): # not the same as Shape's .doit
self..priv_flag = 99 # not the same as Shape's .priv_flag
These patches are experimental (i.e. unofficial) but won't adversely affect
existing code.
The downside is that (so far) I have had no success evoking any interest in
supporting private scopes in Python (based on the response to the patches and
follow-ups).
I encourage anyone who would like to see some form of 'privacy' added to
Python to post on the subject- maybe we can get some kind of debate started...
Regards,
Peter Munnings
Guido van Rossum
Peter Munnings wrote:
> The downside is that (so far) I have had no success evoking any interest in
> supporting private scopes in Python (based on the response to the patches and
> follow-ups).
OK, I'll bite. I was in serious deadline mode last week to get Python
1.4b2 out, so I skimmed your patches, didn't immediately see what they
did, and archived the article. However, after a few days of building
sandcastles and surfing the waves, I felt more inclided to study your
code, so I dug them up again.
Now, I'm impressed with their elegance.
The genius of your approach is that it is pure name mangling: ".spam"
translates to "<classname>.spam", and that's it. This can all be done
at compile time, and without adding new instructions to the virtual
machine -- the only run-time change is to from M import *.
I see some problems with your implementation (global variables!) and
there is the slight problem of giving the debugger accessw to private
variables (possibly solved by giving "exec" control over contexts), but
my biggest problem with it right now is the overloading of "." -- this
is becoming a lexical hotspot, with its use for attribute selection, in
floating point literals, for ellipses in indexing (new in 1.4b2, in
support of Numerical Python), and now to indicate private names...
This probably requires more thinking, as I don't immediately see a less
intrusive syntactical variant. I may just have to get used to it.
(Any addition to Python's syntax will be faced with a clamoring from
those -- including myself -- who prefer to keep it simple, and don't
want it to turn into Perl. On the other hand, consolidation shouldn't
have to mean total immobility.)
It would be nice if it could be extended for "protected" variables
(only usable by subclasses). I wonder if perhaps the name mangling
could be changed so that ".spam" translated to "_<classname>_spam" so
that there would always be a long form to access private instance
variables, without giving up the protection against accidental re-use
of variable names.
Enough for now... I'm not saying that I'll hack this into 1.4b3,
but it's an interesting approach.
--Guido van Rossum
Skip Montanaro
Greg.Mc...@nms.otc.com.au (Greg McFarlane) wrote:
....
The four modifications to python's object-oriented subsystem mentioned
in Stephen's paper are:
....
4. Allowing python classes to be written in C.
.... The last is also a very good idea and should be seriously looked at.
Don Beaudry's Meta-Extension System Set (MESS) does this. It's at
http://maigret.cog.brown.edu/Python/MESS/)
Documentation is still scanty, though there is an example of a point class
written in C on the Web page.
For interested folks there is a (sometimes quiet) mailing list about the
MESS as well. Subscription information is on the Web page as well.
Skip Montanaro | Check out:
sk...@calendar.com | Musi-Cal: http://concerts.calendar.com/
(518)372-5583 | Conference Calendar: http://conferences.calendar.com/
Guido van Rossum
> If you get into private and protected, may I suggest the EIffel
> approcach of visiblity instead of the C++ one. The notion of Point of
> View defined in EIffel allows you to specify which classes (and
> subclasses) are allowed to call these members of yous class. For
> instance, if two classes take part in a pattern, it's highly possible
> that they will call method on each other and you would like to keep
> this interface dedicated to the pattern use.
>
> Sure, it will make things more difficult, but if you fall into the
> protected approach, you can be sure that soon, someone will ask for
> friends, and the whole system information hiding system will collapse,
> as in C++.
>
> So, how far to go ?
>
> As there's no universal language, may be we have to consider what is
> the proper use of python and not turn it into a scary monster.
Good point! Where to stop? I say, private variables are somewhat
useful (though they really just save some keystrokes); for protected
and friends, well, you can do that with naming conventions.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
> > ... I say, private variables are somewhat
> > useful (though they really just save some keystrokes) ...
>
> Private variables do more than just save keystrokes. They allow me to
> use someone else's class hierarchy without having to know any internal
> details of the classes. They also allow the implementation of those
> classes to change without having any effect on my use of them.
>
> How can extra keystrokes give me this protection?
If the class implementor consistently used self._ClassName_varname for
private variables, neither of you would have to worry. As with any
kind of protection, this isn't 100% safe, but I say it's close enough.
The posted implementation of private variables translates ".spam"
into "ClassName.spam"; it could just as well translate it into
_ClassName_spam without serious loss of protection.
Guido van Rossum
> This is a very good idea (since it requires minimal changes to the
> language definition and interpreter), but I have to wonder if the
> multiple dots would make the code less readable. Perhaps some variant
> of Hungarian notation?
Now there's something that *really* makes your code impenetrable (for
those who aren't familiar with Hungarian notation) :-)
I agree though that this is my main gripe with the proposal as it
stands -- self..spam doesn't read very nicely, but I can't think of a
better way to do this.
Perhaps ``self.__spam'' would be acceptable?
For backwards compatibility reasons, private variables would start
with 2 underscores but *not* end in 2 underscores -- since the
__spam__ convention is already in use for names that have a special
meaning to the Python virtual machine (e.g. __add__) and it's too much
work to explicitly check for a specific set of names.
Ken Manheimer
> I agree though that this is my main gripe with the proposal as it
> stands -- self..spam doesn't read very nicely, but I can't think of a
> better way to do this.
it looks distinctive enough to stand out, but also minimal enough to be
elegant... (I'm quite fond of elipses, though, so maybe i have a perverse
bias!-) I'd *certainly* vote for it in favor of the 'self.__spam' -
that's too similar to references to special method names, eg
'self.__spam__'.
Ken
Guido van Rossum
> Question: why does the arrow point at "2" in "1..2" but at the second
> "." in "a..b"?
>
> "1..2" is tokenized as ['1.', '.2'] while "a..b" is tokenized as ['a', '.',
> '.', 'b']. The parser is probably pointing at the rightmost extent of the
> first invalid token.
Yes.
sbr...@ibm.net
In <1996080600...@baldric.pad.otc.com.au>, Peter Munnings <Peter.M...@nms.otc.com.au> writes:
>
>> It would be nice to have private methods and attributes. Is there perhaps
>> another way to get protected members?
>>
>I posted a set of patches a few days ago (look for 'Private scopes in Python')
>which provides private member functions and member variables in Python.
>
I missed your posting, but Greg McFarlane sent it to me. Thank you for the
description of your concept. It looks fine for me.
Would be nice to see it in the next Python release.
Stefan
Skip Montanaro
Guido wrote:
> I agree though that this is my main gripe with the proposal as it
> stands -- self..spam doesn't read very nicely, but I can't think of a
> better way to do this.
Ken wrote:
In case it makes a difference, i *like* the 'self..spam' notation. To me
it looks distinctive enough to stand out, but also minimal enough to be
elegant...
I don't want to puff the Perl folks up too much ;-) but there are other
characters that could be used besides '.' and '_' to introduce private
attributes. Just about any character that can't syntactically follow a '.'
would be okay. How about something from the set ['%', '~', ':']?
Skip Montanaro | Musi-Cal: http://concerts.calendar.com/
sk...@calendar.com | Conference Calendar: http://conferences.calendar.com/
(518)372-5583 | Python: http://www.python.org/
Guido van Rossum
> I don't want to puff the Perl folks up too much ;-) but there are other
> characters that could be used besides '.' and '_' to introduce private
> attributes. Just about any character that can't syntactically follow a '.'
> would be okay. How about something from the set ['%', '~', ':']?
I think neither of these will work very well. ~ can't be used at all,
because it can be a unary operator (at least the original proposal
supported "global .spam", which means that you can write
".spam=.spam+1" -- ). self.%spam and self.:spam do raise the question
"what does it mean?" and also aren't very robust in the light of a
single token being omitted, e.g. self.%spam -> self%spam,
x[self.:spam] -> x[self:spam].
Skip Montanaro
Quiz: "1..2" and "a..b" are both syntax errors, when entered as an
expression:
>>> 1..2
File "<stdin>", line 1
1..2
^
SyntaxError: invalid syntax
>>> a..b
File "<stdin>", line 1
a..b
^
SyntaxError: invalid syntax
Question: why does the arrow point at "2" in "1..2" but at the second
"." in "a..b"?
"1..2" is tokenized as ['1.', '.2'] while "a..b" is tokenized as ['a', '.',
'.', 'b']. The parser is probably pointing at the rightmost extent of the
first invalid token.
Skip Montanaro | Musi-Cal: http://concerts.calendar.com/
Guido van Rossum
> > I agree though that this is my main gripe with the proposal as it
> > stands -- self..spam doesn't read very nicely, but I can't think of a
> > better way to do this.
>
> it looks distinctive enough to stand out, but also minimal enough to be
> bias!-) I'd *certainly* vote for it in favor of the 'self.__spam' -
> that's too similar to references to special method names, eg
> 'self.__spam__'.
Well... ``self..spam'' may stand out, but could anyone guess what it
meant when confronted with a few examples? I doubt it -- it looks too
much like ".." is a new token (maybe meaning ellipses, though those
are spelled "..." in the new extensions for numerics).
On the other hand, ``self.__spam'' also stands out, and clearly is
some kind of special attribute -- what kind, the manual will tell you,
but until you need to know the details, you can continue reading
without feeling that there might be some great magic happening.
I thought about the similarity to __spam__, and decided that that's
okay: __spam__ has a special meaning for Python (hypothetically
speaking) while __spam has a special meaning for the user's class.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Quiz: "1..2" and "a..b" are both syntax errors, when entered as an
Peter Munnings
Steven Miale (smi...@cs.indiana.edu) wrote:
> From python-li...@cwi.nl Thu Aug 8 17:35 EST 1996
>
> In article <1996080600...@baldric.pad.otc.com.au>,
> Peter Munnings <Peter.M...@nms.otc.com.au> wrote:
> >In Steven's version, you use the access keyword to declare access rights,
> >wheareas in mine, the variable name is prefixed with a '.', e.g.
> >
> >class Shape:
> > def move(self):
> > self.flag = 42
> > return self..doit() # calling the private member fn
> >
> > def .doit(self): # private member fn
> > self..priv_flag = 99 # private member var
>
> language definition and interpreter), but I have to wonder if the
> multiple dots would make the code less readable.
>
Seriously, these user-visible aspects are probably those warranting the
deepest scrutiny i.e. the actual mechanics of the patch are less important
than:
- what it purports to do
- the changes to Python's 'interface' i.e. the syntax and semantics of the
language
After all, you can always fix a bug in the implementation later...but it's
hard to reverse an extension to the grammar.
I think that the major options are:
1. A declarative scheme e.g. a declaration 'private a, b, c' before use
within a scope. This has the advantage that there is nothing special
about the variable name at all.
2. A variable naming scheme based on a grammar extension. This is easy to
implement and can guarantee not to break existing code, but changes the
look (and possibly the philosophy) of the language.
3. A variable naming scheme _not_ based on a grammar extension (e.g. _fred
is private because of a leading '_'). This has less impact on the look of
the language but a big impact on existing code.
My first preference is actually for the first option (i.e. _not_ the way my
patch works)...but Python currently needs declarations only for globals
(which are rare in most peoples code), so this could actually be a bigger
upheaval than the second option.
> Perhaps some variant of Hungarian notation?
>
On my soapbox: :-)
Personally I am strongly opposed to Hungarian notation in all programming
languages supporting reasonable strong dynamic or static type systems (i.e.
Python, SmallTalk, C++, ANSI C, Eiffel, Modula-2, Ada, Java etc etc etc).
I think it's a great help when programming in assembler or K&R C (quite a
short list, isn't it?) :-)
Microsoft are great proponents of Hungarian (surprise, surprise), however
their header files are packed full of typedefs which provide no type safety
in ANSI C (i.e. typedef int HWND instead of typedef struct HWND_cookie *HWND).
Hungarian is a system for programmers to do their own type checking by hand.
It's not really designed for a compiler.
Peter Munnings
...anti-Hungarian activist extraordinaire
Donald Beaudry
Peter Munnings <Peter.M...@nms.otc.com.au> wrote,
> I think that the major options are:
> 1. A declarative scheme e.g. a declaration 'private a, b, c' before use
> within a scope. This has the advantage that there is nothing special
> about the variable name at all.
This reminds me of somthing that I have been wishing for for a long
time. However, I really dont like the use of the keyword 'private'
for the purpose. I would rather have something much more generic in
the way of an optional variable declaration syntax. The keyword 'var'
seems well suited to the task. All it says is "here comes a
variable".
The idea I would like to see implemented is to provide Python with a
generic variable declaration syntax. It should allow the programmer
to associate arbitrary "properties" with a variable. This could
include, but not be limited to, things like scoping, access, or even
data type restrictions. The grammar could look somthing like this:
var_stmt: 'var' var_decl (';' var_decl)*
var_decl: NAME ':' var_property (',' var_property)*
var_property: NAME ('.' NAME)*
(I suppose that simply allowing a var_property to be an expression
would work fine too, assuming that someone wants to think about when
it gets evaluated.) By allowing such a generic declaration as this,
all kinds of information could easily be passed from the source to the
compiler. The list of valid properties could be extended as the need
arises and, in many cases, without the need to change the language.
How and for what purpose the property information gets used would be
entirely up to the implementation or any extension that cares to look
for it.
If such a mechanism was available, I could get rid of the ugly
__members__ list used by the MESS to declare structure members. Thus
class eggs(ctype.struct):
__members__ = (('a', ctype.int), ('b', ctype.double))
could become
class eggs(ctype.struct):
var a : ctype.int
var b : ctype.double
or even
class eggs(ctype.struct):
var a : ctype.int, access.private
var b : ctype.double, access.protected
--
Donald Beaudry Silicon Graphics
Digital Publishing/DMS 1 Cabot Road
do...@sgi.com Hudson, MA 01749
...So much code, so little time...
Conrad Minshall
In article <1996080900...@baldric.pad.otc.com.au>, Peter Munnings
<Peter.M...@nms.otc.com.au> wrote:
> I think that the major options are:
> 1. A declarative scheme e.g. a declaration 'private a, b, c' before use
> within a scope. This has the advantage that there is nothing special
> about the variable name at all.
But it has the disadvantage that when I'm looking at code I can't easily
tell what is private and what isn't. Instead of jumping out at me right
there where I'm looking I have to, for each variable, check "up above"
somewhere to see if it has been declared private. For this reason I
dislike data declarations in general.
> 2. A variable naming scheme based on a grammar extension. This is easy to
> implement and can guarantee not to break existing code, but changes the
> look (and possibly the philosophy) of the language.
> 3. A variable naming scheme _not_ based on a grammar extension (e.g. _fred
> is private because of a leading '_'). This has less impact on the look of
> the language but a big impact on existing code.
Right. For instance I've started using two leading underscores as a
personal convention meaning private to *this* class while I use one leading
underscore to mean the attribute is only intended to be private to the
module. Which brings up the question also of what exactly does "private"
mean? I've found the class/module distinction to be valuable - I wonder if
there are other useful variations(?)
signoff
--
Conrad Minshall con...@apple.com (408)974-2749
Fredrik Lundh
> I missed your posting /.../
Always keep in mind that everything on c.l.py is archived on dejanews;
you can quickly locate expired articles like this via the Search page
on www.python.org.
Regards /F
jeffrey P. Shell
Guido van Rossum wrote:
> I agree though that this is my main gripe with the proposal as it
> stands -- self..spam doesn't read very nicely, but I can't think of a
> better way to do this.
>
personally, my vote is for the "self..spam"..
maybe i need to dig back through the Docs again, but what do the _spam
variables mean? (single leading underscore).. i've seen them used in a
few modules, but didn't understand their meaning any more than i first
understood the __spam__() ones either. self._spam has a nice 'feel' to
it, self.__spam comes dangerously close to the __spam__ thing, plus to
me is aesthetically displeasing.
Barry A. Warsaw
>>>>> "CM" == Conrad Minshall <con...@apple.com> writes:
CM> Right. For instance I've started using two leading
CM> underscores as a personal convention meaning private to *this*
CM> class while I use one leading underscore to mean the attribute
CM> is only intended to be private to the module. Which brings up
CM> the question also of what exactly does "private" mean? I've
CM> found the class/module distinction to be valuable - I wonder
CM> if there are other useful variations(?)
Very interesting. I've long used a single leading underscore in my
Python code to denote `privateness' of a name (and long before that, a
different character in my C++ code served the same function, but for a
different reason). I liked the double leading underscore proposal as
soon as I saw it; I agree with Guido that __spam makes me think it's
special (to user code) in a complimentary way that __spam__ makes me
think it's special (to the `system'). With out the eye-parsing
confusion that double dots introduce. I've now started using to
double leading underscores in anticipation... :-)
The question of `private to what' hasn't come up for me. I never
found much value in distinguishing between private-to-the-class and
private-to-the-module, maybe because module-private names are already
segregated into their own namespace. If you could inherit modules, or
if from...import weren't (rightly) discouraged as much as it is, it
might be a bigger problem. So I personally used the same convention
when naming module-private and class-private variables, and haven't
ever been confused.
To recap: my vote would be for __spam as private variables. I like
this much better than any other weird character, and definitely much
better than double dots.
-Barry
Donald Beaudry
Guido van Rossum <gu...@CNRI.Reston.VA.US> wrote,
> On the other hand, I expect that you want 'var' to apply to an
> entire module, or at least to an entire class (so you need to
> declare your privates only once, at the top of the class).
Pretty much... For each of module, class, and function, I would like
to have access to a list (order is important) of variable names and
their associated properties. From there, I (the extension writer)
could make use of the information.
> This makes the required searching much harder, since the top of the
> class is generally much farther back than the top of the function.
Yes, searching is much harder, but I don't really like the
alternatives either. What we are talking about here is a mechanism
for "tagging" variables with some extra information. A couple of
methods have been proposed to solve a specific form of the problem.
Now, assuming that there is a problem (arguing that there isn't should
be the easiest way to shoot down this proposal), I would much prefer a
generic declaration syntax that is extensible to many different
problems where "tagging" is needed. Playing with the variable name
(the other alternative) is just not as useful. Clearly it can't be
used to pass type hints to an efficient code generator.
Of course, it's possible that I'm overestimating the number of
problems that could easily be solved by tagging variables. After all,
I am just a bit biased here ;)
Guido van Rossum
Conrad Minshall:
> Right. For instance I've started using two leading underscores as a
> personal convention meaning private to *this* class while I use one leading
> underscore to mean the attribute is only intended to be private to the
> module. Which brings up the question also of what exactly does "private"
> mean? I've found the class/module distinction to be valuable - I wonder if
> there are other useful variations(?)
Yes. There's already a tiny bit of support for using leading
underscore to mean module-private: "from M import *" won't import
such variables (you can still get at them with "from M import _spam"
or by using "M._spam"). Your use of double leading underscore to mean
class-private is exactly what I'd hoped to convey with my proposal.
(I also agree with Conrad's objection against variables -- sorry, Don!)
Barry A. Warsaw
>>>>> "jPS" == jeffrey P Shell <je...@cynapses.com> writes:
jPS> maybe i need to dig back through the Docs again, but what do
jPS> the _spam variables mean? (single leading underscore)..
_spam has no special meaning. I've personally used it as a convention
for `private' because I like the visual separation. I think in
Bastion.py there is a default that names beginning with underscore
(any number of 'em) are not exported into the bastion.
-Barry
Guido van Rossum
> Of course, it's possible that I'm overestimating the number of
> problems that could easily be solved by tagging variables. After all,
> I am just a bit biased here ;)
Actually, you're probably underestimating -- which is why such a
proposal should not be taken lightly. I have other plans for Python
2.0, so unless a working group (SIG?) gets formed that creates a solid
proposal, based on a clear set of requirements, I'm not going to spend
time on this.
Sounds like Don might volunteer to run such a SIG?
Skip Montanaro
Alan Jaffray writes:
".." looks natural, and I think in context it'd be pretty apparent
that "..spam" is just another kind of member, akin to ".parrot".
I'm not sure the way Alan is modelling foo..spam is the way it would be
implemented token-wise. There's not a new '..' token is there? I thought
"foo..spam" would tokenize as ['foo', '.', '.', 'spam'] or ['foo', '.',
'.spam'].
Guido van Rossum
> > (I also agree with Conrad's objection against variables -- sorry, Don!)
>
> variable declarations either, but in many cases I see them as a
> necessary (or at least nice to have) evil (structure layout, code
> generation hints, etc). Someday (perhaps not in your lifetime :) they
> just might happen... you've already gotten pretty close with 'global'
> and 'access'. I just hope that when and if it does happen it goes in
> the direction of my 'var' proposal. Note that 'var' could have been
> used to support both 'global' and 'access'. If it had been used for
> 'access' you would not have that bit of syntax hanging around today.
>
> So, I suppose then that slowly getting rid of 'global' in favor of
> 'var spam : global' is out of the question too ;)
Well, 'global' has per-function scope. This is sometimes annoying
(you have to repeat its global-ness in each function that assigns to
it) but requires no more effort than locating the first assignment to
a variable in a particular scope. On the other hand, I expect that
you want 'var' to apply to an entire module, or at least to an entire
class (so you need to declare your privates only once, at the top of
the class). This makes the required searching much harder, since the
top of the class is generally much farther back than the top of the
function.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Donald Beaudry
> (I also agree with Conrad's objection against variables -- sorry, Don!)
Well, it was worth a try... I don't really like the idea of using
variable declarations either, but in many cases I see them as a
necessary (or at least nice to have) evil (structure layout, code
generation hints, etc). Someday (perhaps not in your lifetime :) they
just might happen... you've already gotten pretty close with 'global'
and 'access'. I just hope that when and if it does happen it goes in
the direction of my 'var' proposal. Note that 'var' could have been
used to support both 'global' and 'access'. If it had been used for
'access' you would not have that bit of syntax hanging around today.
So, I suppose then that slowly getting rid of 'global' in favor of
'var spam : global' is out of the question too ;)
--
Greg Ewing
Conrad Minshall wrote:
>
> For instance I've started using two leading underscores as a
> personal convention meaning private to *this* class while I use one leading
> underscore to mean the attribute is only intended to be private to the
> module.
I'd be really disappointed if the language started to
force a convention like this on me. Identifiers with
leading or trailing underscores look very ugly to me,
and if I had to use them for anything as common as
private variables, it would make me feel quite ill!
The same goes for any other punctuation marks such
as @, $, !, etc. To my eyes they just don't belong as
part of an identifier.
There is one kind of naming convention I would be
willing to accept, namely:
* If it starts with an upper case letter, it is public.
* If it starts with a lower case letter, it is private.
(Underscores would probably have to count as upper
case letters for compatibility with existing __xxx__
identifiers.)
I know this convention would go against the current
Python style of naming everything in lower case, and
I make no apology. I've never liked that style much -
I like to use Upper Case for Major Important Things
and lower case for other things. Entirely lower
case code I find bland and hard to find my way
around in.
Greg
David Ascher
Greg Ewing wrote:
> There is one kind of naming convention I would be
> willing to accept, namely:
>
> * If it starts with an upper case letter, it is public.
> * If it starts with a lower case letter, it is private.
>
> I know this convention would go against the current
> Python style of naming everything in lower case, and
> I make no apology. I've never liked that style much -
> I like to use Upper Case for Major Important Things
> and lower case for other things. Entirely lower
> case code I find bland and hard to find my way
> around in.
You don't have to apologize for going against style, but you do have to
apologize because your requested mod would break a *lot* of existing
code. As they say in the TV business, ``Bzzzt!'' =)
I vote for Don's proposal. It leaves everything which currently works
as is, and allows a lot of flexibility for people who know what they're
doing (either in terms of privacy, compilation or execution hints,
efficient implementations, etc.).
--da
Jim Fulton
In article <Pine.SUN.3.91.960808130540.1541h-100000@glyph> Ken
Manheimer <k...@glyph.uucp> writes:
> I agree though that this is my main gripe with the proposal as it
> stands -- self..spam doesn't read very nicely, but I can't think of a
> better way to do this.
In case it makes a difference, i *like* the 'self..spam' notation. To me
it looks distinctive enough to stand out, but also minimal enough to be
elegant... (I'm quite fond of elipses, though, so maybe i have a perverse
bias!-) I'd *certainly* vote for it in favor of the 'self.__spam' -
that's too similar to references to special method names, eg
'self.__spam__'.
To me, foo..bar reads as some sort of range from foo to bar.
Or it reads like a syntax error. It all depends on my .mood.
--
Jim Fulton Digital Creations
j...@digicool.com 540.371.6909
Janne Sinkkonen
Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
> I'd be really disappointed if the language started to
> force a convention like this on me.
Well, it forces you to indent... why not use a space ( ) prefix for
private members? :)
> Identifiers with
> leading or trailing underscores look very ugly to me,
> and if I had to use them for anything as common as
> private variables, it would make me feel quite ill!
I agree, they are ugly. On the other hand, underscores for private
members seems to be a common convention already. Their use is somehow
intuitively obvious for the programmers.
> * If it starts with an upper case letter, it is public.
> * If it starts with a lower case letter, it is private.
It is difficult to eye, and too close to the fortran style requiring
'i' or something in the name. I would like to decide the name
myself. Some kind of non-letter prefix leaves the essential part of
the name alone.
The dot thing (..) looks really nice but is against the current
convention and maybe a little non-obvious.
--
Janne Sinkkonen <ja...@iki.fi> <URL: http://www.iki.fi/~janne/ >
Fredrik Lundh
> Entirely lower case code I find bland and hard to find my way around
> in.
We all have differently coloured glasses, don't we?
I think the python style guide (to the extent such a thing exists)
says that things should look like MyClass (*), A_CONSTANT and
yet_another_method. I've never had any problem with that...
> There is one kind of naming convention I would be
> willing to accept, namely:
> * If it starts with an upper case letter, it is public.
> * If it starts with a lower case letter, it is private.
Now that's one serious candidate for the big "let's break as much
existing code as one possibly can" award (hey, what happened to all my
methods?), not to mention all the programmers that would find this
much more weird than block indentation... (I do hope I justed missed
the irony)
/F
*) its quite convenient to let class constructors and factories look
the same, so you should probably name factory functions the same way
as classes.
anthony baxter
>>> Greg Ewing wrote:
> There is one kind of naming convention I would be
> willing to accept, namely:
>
> * If it starts with an upper case letter, it is public.
> * If it starts with a lower case letter, it is private.
> I know this convention would go against the current
> Python style of naming everything in lower case, and
> I make no apology. I've never liked that style much -
> I like to use Upper Case for Major Important Things
> case code I find bland and hard to find my way
> around in.
Aaargh. Do you realise just how much code this would break?
"just rewrite it" is not really practical, is it. Not on this
scale.
I'd have to say that I use both lower, upper, and mixedCase names,
and I don't like this idea at all...
(just a dissenting opinion...)
Of the ideas I've seen so far, I think the leading underscore is the
one that I'd find easiest to work with - but the "var" one (don't overload
def, please) also appeals.
Anthony
--
anthony baxter @ /\/\|| / australian artificial intelligence institute, \
email: ant...@aaii.oz.au ||===============================================||
phone: +613 9663 7922 \ level 6, 171 latrobe st, melbourne aust. 3000 /
Bertil Reinhammar
!!!
Quite interesting thread this...
Reading Peter Munnings' and Donald Beaudry's, I find the ideas that seems
most proper while I can't find any really good arguments against their
case among the replies. I'd like to add the following:
- We are discussing some way to express scope for certains identifiers, right ?
Look at definition of a class, we write "class foo", or look at a global,
we write "global foo". (We do *not* write @foo, %foo or ___foo.) So writing
"var foo ..." for privacy is consistent.
- Using underscore, uppcase letter or some punctuation mark as prefix or suffix
to indicate semantics for an indentifier is, IMHO, inferior.
+ underscore has a long standing tradition of being equal to [a-z][A-Z] in
identifiers,
+ making letter uppercase to be syntax to indicate special identifier semantics
is *error prone*, just like . vs. .. or _ vs. __ , and
+ use of punctuation marks gives real uggly code (save them for operators
where they do proper job).
I can live with the already defined scheme for builtins because that's
primarily a naming convention, it's not enforced by syntax.
- To those who feel it very important that scope is reflected in the name,
it's free to use whatever naming scheme.
In the process of scrutinizing other peoples code, finding out the scope
for a certian identifier is, to my experience, a lesser effort regardless what
language it happen to be.
---BeRe
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bertil Reinhammar IV DocEye AB (Combitech)
phn. +46 13 200606 Teknikringen 9
fax. +46 13 214897 S-58330
bertil_r...@ivab.se Sweden
Guido van Rossum
> I vote for Don's proposal. It leaves everything which currently works
> as is, and allows a lot of flexibility for people who know what they're
> doing (either in terms of privacy, compilation or execution hints,
> efficient implementations, etc.).
Sorry, it's too early to vote. My concerns expressed in a previous
message have to be addressed first (especially how the info is
accessed efficiently at compile time -- I don't believe Don's proposal
of using the parser module and symbolically evaliating the expression
will work).
Guido van Rossum
> - We are discussing some way to express scope for certains
> identifiers, right ? Look at definition of a class, we write
> "class foo", or look at a global, we write "global foo". (We do
> *not* write @foo, %foo or ___foo.) So writing "var foo ..." for
> privacy is consistent.
Hmm, these are quite different. 'global' is the only statement that
tells the *parser* (or (byte-code) compiler, if you want) something
about a name; in all other cases, the parser forgets the name as soon
as it's generated the code for it. (Not quite true, since assignments
are scanned for evidence of variables, but that's an optimization
that's -- mostly -- transparent).
> - Using underscore, uppcase letter or some punctuation mark as
> prefix or suffix to indicate semantics for an indentifier is,
> IMHO, inferior.
> + underscore has a long standing tradition of being equal to
> [a-z][A-Z] in identifiers,
Not true -- *leading* underscore has a long tradition (in the C world,
anyway, but we don't really want to ignore that here) of meaning
"internal use" (of some kind). ANSI C has exact rules for the use of
names with single and double leading underscore (anything beginning
with two underscores or with an underscore and an upper case letter is
reserved for the compiler).
Python follows this lead: ``from M import *'' does not import names
with leading underscore, and uses double leading+trailing underscores
for hidden attributes. The idea of the latter is that user code
should never define or use such names except to reference the special
semantics associated with them (e.g. __dict__, __init__, __add__, even
__version__), and the implementation can use these to insert stuff of
its own into a namespace that is otherwise wholly owned by the user
(e.g. __doc__, __file__).
> + making letter uppercase to be syntax to indicate special
> identifier semantics
> is *error prone*, just like . vs. .. or _ vs. __ , and
No dispute there. There are too many conflicting conventions for when
to use upper case to make any sense out of them. This is as bad as
Fortran's ``implicit integer (i-n)''. For many people it takes
considerable effort to notice that "Spam" and "spam" are spelled
differently.
> + use of punctuation marks gives real uggly code (save them for
> operators where they do proper job).
Agreed. Therein lies the road to Perl :-) Peter Munnings' choice of
`.' was very tasteful by comparison, but still not good enough (in my
eyes anyway).
> I can live with the already defined scheme for builtins because
> that's primarily a naming convention, it's not enforced by syntax.
It may not be enforced by syntax, but it's enforced by the virtual
machine, which is practically as strong a force.
> - To those who feel it very important that scope is reflected in the
> name, it's free to use whatever naming scheme. In the process of
> scrutinizing other peoples code, finding out the scope for a
> certian identifier is, to my experience, a lesser effort
> regardless what language it happen to be.
Python is an experiment in how much freedom programmers need. Too
much freedom and nobody can read another's code; too little and
expressiveness is endangered. Python has a little less freedom than C
-- for example, it enforces more consistent use of indentation. You
are still free to choose by how much you indent your code so it looks
good to your eyes, and you can mix spaces and tabs if your editor has
that habit, but you have to be consistent in the indentation of your
code body. Nobody has complained about *that* (the complaints have
been about not having braces as well).
Enforcing capitalization rules isn't quite the same. There are many
conflicting conventions for capitalization in the world (from classic
K&R style which uses ALLCAPS for macros and lower case for everything
else, to the X11 library style), and it's often necessary to maintain
consistency with conventions that are used by some other software
component, e.g. when wrapping a C or C++ library in Python
(interfacing to X11 or to Microsoft APIs comes to mind).
I believe that enforcing the leading double underscore to mean private
variable has a chance of surviving amongst this all. It has very
little actual use apart from the combination with double_trailing
underscore, and some people tell me that they've been using this
already for private variables. It's a logical extension of the use of
a single leading underscore as a convention to indicate internal use
of some kind. It's not too intrusive, and not too much typing --
after all, we *like* having to write ``self.spam = 1'' rather than
``spam = 1'' since it saves us looking up spam in the class definition
or hunting for a local variable declaration for it.
I'm not putting this in 1.4, but I'm very tempted to put it in the
next version. The 'var' proposal seems far from completion, and is
also lacking supporters apart from Donald...
Robin Friedrich
I agree with Skip and Bertil on this. Please do not put this .. syntax
change in Python. It make's my..skin crawl! Don's proposal for a var
construct that can be extended is the way to go for the future of
robust code. Afterall, that's what we are talking about here; placing
scoping / privacy information in Python above and beyond the dynamic
nature currently enjoyed by folks. If you want to write robust code
(with private scopes for example) then it's not too much to ask a
little more typing <sic> in the source. The argument against the var
statement being verbose doesn't cut it in this environment. If you're
sitting at the editor and whipping up a neat little python goody why
bother declaring something private anyway. One of the nice things
about Python is that I don't have to learn abstract symbology. Let's
not start down that perly road now.
My vote's for "var" in 2.0.
Fredrik Lundh
> Yep! When do I collect my prize? :-)
Well, first you have to score in my "write a 50-line uncommented perl
script that /F can decipher" contest. Code that look like comments
are ok, code only consisting of print statements are not.
Over and out /F
Greg Ewing
> the "var" one (don't overload
> def, please) also appeals.
I could live with this provided that there were some way to make a
single "var" attribute declaration thingy cover a collection of names.
How about making the "var" statement a prefix to a block of
declarations:
var scope(private):
foo = 42
def blarg(x):
...
This would allow just as much extensibility, while allowing attributes
such as privateness which apply to a collection of names to be written
once for the whole collection, rather than repeated for each member.
Although I think it should be called something other than "var",
since it applies to all declarations, not just variables.
Greg
Greg Ewing
> Now that's one serious candidate for the big "let's break as much
> existing code as one possibly can" award
Yep! When do I collect my prize? :-)
> not to mention all the programmers that would find this much more
> weird than block indentation
Seems to me that whatever naming convention you choose, somebody is
going to dislike it. For that reason, I would much rather not tie
scoping to a naming convention at all.
Greg
Sjoerd Mullender
What I haven't seen in this discussion so far is the issue of multiple
levels of scope. When I write a class, some instance variables are
*only* to be used in that class, some other instance variables may be
used in extensions of the class (as long as the extension writer knows
what he/she is doing :-), and still other are ok to use anywhere.
The proposal to use leading underscores doesn't really give the
flexibility to address these different levels, but the var proposal
may be a bit too general and hard to implement efficiently. So, I
think I would be in favor of a simpler var statement or a variation on
the access statement.
The statement "access variable: private" said that you weren't allowed
to access a variable from anywhere but the instance methods, but an
extension writer still had to be aware of the names being used in the
class. A variation would be to let the above mean that the variable
is only visible within instance methods and that extensions could
reuse the name but they would refer to a different object. In
addition to the keyword "private" there could be more keywords to
indicate various levels of disclosure of the variable. The keywords
would only be keywords in this particular context.
-- Sjoerd Mullender <Sjoerd.M...@cwi.nl>
<URL:http://www.cwi.nl/~sjoerd/>
Michael McLay
Sjoerd Mullender writes:
> What I haven't seen in this discussion so far is the issue of multiple
> levels of scope. When I write a class, some instance variables are
> *only* to be used in that class, some other instance variables may be
> used in extensions of the class (as long as the extension writer knows
> what he/she is doing :-), and still other are ok to use anywhere.
Ok, to continue with the naming convention concept we could have:
class foo:
______name = 1 #only used within a function
____name = 2 #only used within a class
__name = 3 #only used in extensions of the class
_name = 4 #only used in the module
name = 5 #can be used anywhere
I expect some loud objections to the ugliness of the ____name
notation. The idea was to continue with the __name__ notation. This
convention seemed ugly at first, but eventually the notation became an
asset. Generally programmer can skip over code starting with a
underscore names unless they are doing something special. The
notation makes visually scanning a module of code easier. The
notation in the class foo follows this concept. Each added set of
underscores narrows the scope of the name. The notation becomes an
intuitive indication of the narrowness of the scope. In practice the
uglier the name the less often it is likely to be used. Programmers
can easily read over the ugly code when scanning a file. The extra
typing for narrowly scoped names should not be a large burden and only
those who seek the protection of hidden names will need to use the
notation.
Skip's objection about mistyping will still be a problem. Is it
possible to be both simple and foolproof? It would be harder to make
a mistake if the notation where something like the following:
class foo:
_o_o_o_name = 1 #only used within a function
_o_o_name = 2 #only used within a class
_o_name = 3 #only used in extensions of the class
_name = 4 #only used in the module
name = 5 #can be used anywhere
This notation is harder to type and it is not as easy to quickly read
over uninteresting names, but it would make it much harder to miss
typing an underscore.
Michael
Skip Montanaro
Michael,
I think you must have forgotten some smileys on that last post. That, or
you got into something in the medicine cabinet... :-)
Presuming you want to go to the trouble of typing all those o's and underscores you
might just as well adopt a naming convention that specifies the scoping a
bit more mnemonically:
class foo:
_f_name = 1 #only used within a function
_c_name = 2 #only used within a class
_e_name = 3 #only used in extensions of the class
_name = 4 #only used in the module
name = 5 #can be used anywhere
Another problem with underscores is they tend to disappear when they are
under the cursor...
Skip
Michael McLay writes:
Ok, to continue with the naming convention concept we could have:
class foo:
______name = 1 #only used within a function
____name = 2 #only used within a class
__name = 3 #only used in extensions of the class
_name = 4 #only used in the module
name = 5 #can be used anywhere
...
Guido van Rossum
> What I haven't seen in this discussion so far is the issue of multiple
> levels of scope. When I write a class, some instance variables are
> *only* to be used in that class, some other instance variables may be
> used in extensions of the class (as long as the extension writer knows
> what he/she is doing :-), and still other are ok to use anywhere.
This is akin to the distinction between private and protected in C++
(private: within the current class only; protected: within the current
class and any derived classes). While private seems to be useful
because it offers a form of data hiding that's currently absent in
Python, I'm not so sure how protected would help -- it's too easy to
get around the protection since there's no restriction on who can
derive a class...
Peter Munnings
From: mc...@eeel.nist.gov (Michael McLay)
>
> Sjoerd Mullender writes:
> > What I haven't seen in this discussion so far is the issue of multiple
> > levels of scope. When I write a class, some instance variables are
> > *only* to be used in that class, some other instance variables may be
> > used in extensions of the class (as long as the extension writer knows
> > what he/she is doing :-), and still other are ok to use anywhere.
>
I think these really _are_ frills. The only reason I proposed 'private' was
because it _couldn't_ be simulated effectively by convention (not without
bizarre contortions anyway).
On to the funny bit... :-)
> Ok, to continue with the naming convention concept we could have:
>
> class foo:
> ______name = 1 #only used within a function
> ____name = 2 #only used within a class
> __name = 3 #only used in extensions of the class
> _name = 4 #only used in the module
> name = 5 #can be used anywhere
>
>
---- Eloquent rational (rationalisation?) trimmed
>
> class foo:
> _o_o_o_name = 1 #only used within a function
> _o_o_name = 2 #only used within a class
> _o_name = 3 #only used in extensions of the class
> _name = 4 #only used in the module
> name = 5 #can be used anywhere
>
I propose the following extension:
(allowing room for expansion) allow type hinting by simply using multiples of
8 underscores i.e. ________name is a public int, whereas
________________name is a string. This can be extended as needed for new
builtin types. The scope is of course easily found by taking the number of
underscores modulo 8. To ease typing, I propose an easy-to-read shorthand
notation:
.<n>name is equivalent to n underscores followed by name.
Hence an integer with class scope would be .11var or more properly self..11var
See...much more compact and self explanatory too!
-Peter
Greg Ewing
Peter Munnings wrote:
> I encourage anyone who would like to see some form of 'privacy' added to
> Python to post on the subject- maybe we can get some kind of debate started...
Well, I'm certainly interested in seeing some notion of
privacy incorporated into the language. It astounds me
that Python has a notion of modules but no control over
what is exported from a module.
There seems to be reluctance to add new syntax for this
purpose without making it serve other possible future
purposes as well.
I appreciate entirely the desire to avoid adding new
syntax without an excellent reason. However, I think
we do have an excellent reason in this case. The concept
of separating interface from implementation is
such a fundamental part of modern language design, that
I think we would be fully justified in adding syntax to
support this concept alone.
I would like to make three alternative proposals, two
of which are special-purpose, and one of which is more
general.
(1) Add a "module" statement and an "export" statement.
By default, all identifiers declared within a "module"
are private. To make them accessible from outside the
module, they must be listed in an "export" statement.
For backward compatibility, identifiers declared outside
of any "module" statement would be automatically exported.
Drawbacks: This proposal deals with modules, but not with
classes.
(2) Add a "private:" keyword which introduces a private
section of a scope. Within any scope (module, class or
otherwise) identifiers declared before the "private:"
keyword are public, and those after are private.
For symmetry a "public:" keyword could also be provided.
This proposal has the advantage over (1) of dealing with
modules and classes uniformly.
(3) Proposal (2) could be generalised to allow arbitrary
attributes to be specified for collections of identifiers
by allowing the syntax:
<expression>:
<declaration>...
where the expression evaluates to an attribute or collection
of attributes to be associated with the identifiers
defined in the following declarations.
For the specific purpose at hand, a predefined attribute
"private" would be provided. Declarations of private
identifiers would then have exactly the same form as
in proposal (2), but using a more general mechanism.
Greg
>
> Regards,
> Peter Munnings
Jack Jansen
The more I think about private attributes the more I think that what
is needed is simply a naming convention.
A convention (like prefixing all your private attributes with
"_ClassName_") has the immense advantage that if I override a class and
I *really* want to access members of the baseclass I can do so without
too much trouble, and the code will be more-or-less self-documenting
too. If the self..bar convention were implemented it would no doubt
still be possible to access the "bar" of a baseclass but this would
probably involve lots of self.__dict__["bar"] type of stuff, which is
a lot less readable than "self._BaseClass_bar".
Of course, getting this to be used would be helped if there were some
syntactic sugar, so to access your own provate attributes you wouldn't
have to write "self._ClassName_bar", but something simpler.
Hmm, "?" is free, isn't it? How about "self.?bar"? Too perlish,
probably...
--
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack....@cwi.nl | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
Ty Sarna
In article <jack.84...@news.cwi.nl>, Jack Jansen <ja...@cwi.nl> wrote:
> The more I think about private attributes the more I think that what
> is needed is simply a naming convention.
>
> A convention (like prefixing all your private attributes with
> "_ClassName_") has the immense advantage that if I override a class and
> I *really* want to access members of the baseclass I can do so without
> too much trouble, and the code will be more-or-less self-documenting
> too. If the self..bar convention were implemented it would no doubt
I have to agree. Why change the language when there's already a easy
solution?
Guido van Rossum
> The more I think about private attributes the more I think that what
> is needed is simply a naming convention.
>
> A convention (like prefixing all your private attributes with
> "_ClassName_") has the immense advantage that if I override a class and
I am hoping that automatic translation of self.__spam to
self._ClassName_spam will be acceptable for most users. Not in 1.4
but possible in 1.5.
Tim Peters
> [his guidoness]
> ...
> While private seems to be useful because it offers a form of data
> hiding that's currently absent in Python, I'm not so sure how
> protected would help -- it's too easy to get around the protection
> since there's no restriction on who can derive a class...
I've done a lot of C++ hacking in the last 2 years, & say ptui to protected.
Stroustrup writes about the forces that brought it into being, in "The Design
and Evolution of C++", section 13.9. Suffice it to quote the last sentence:
"In retrospect, I think that 'protected' is a case where 'good arguments' and
fashion overcame my better judgement and my rules of thumb for accepting new
features.". The great irony, of course, is that its very existence in C++ now
makes it very fashionable indeed!
you-language-designers-should-be-ashamed-of-yourselves<wink>-ly y'rs - tim
Tim Peters tim...@msn.com, t...@dragonsys.com
not speaking for Dragon Systems Inc.