Simon Brunning [EMAIL PROTECTED] wrote:
On 9/28/05, Steven D'Aprano [EMAIL PROTECTED] wrote:
If *real* private and protected are *enforced*, Python will be the
poorer for it. See
http://groups.google.com/group/comp.lang.python/msg/b977ed1312e10b21.
That's a wonderful, if long,
Kay Schluehr [EMAIL PROTECTED] wrote:
Honestly I like to use private/protect/public modifiers in C++ for the
sake of code documentation. I like to know which attributes are
dedicated to be known by other objects, which ones are for internal use
only and which ones should be at least publicly
Title: RE: Will python never intend to support private, protected and public?
Alex Martelli wrote:
I used to like [double-underscore private names], but as time
goes by have come to like it less and less; right now,
unless I have to respect existing coding standards,
I entirely avoid
Mike Meyer [EMAIL PROTECTED] writes:
I assumed the Java model was based on the C++ model because it seems
that everything in Java is based on C++, and they share the same
vocabulary. If I'm wrong - well, that means you considered another
language already.
I guess it's similar that way,
Op 2005-10-03, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Mon, 03 Oct 2005 09:14:34 +, Antoon Pardon wrote:
If you are in a project with
multiple authors, your usage of private variables can break code
that other people rely on.
If you are in a project with multiple authors, your
Paul Rubin wrote:
Let's see, say I'm a bank manager, and I want to close my cash vault
at 5pm today and set its time lock so it can't be opened until 9am
tomorrow, including by me. Is that handcuffs? It's normal
procedure at any bank, for good reason. It's not necessarily some
distrustful
El Pitonero [EMAIL PROTECTED] writes:
If so, you would probably be the type of person that also likes static
typing, type safety and variable declaration, right?
I certainly want type safety, which Python claims to have. I'd like
to have variable declaration, at least like var x. Perl has
Op 2005-09-30, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Fri, 30 Sep 2005 06:52:50 +, Antoon Pardon wrote:
Op 2005-09-29, Bill Mill schreef [EMAIL PROTECTED]:
But, if your users can't figure out that they shouldn't be changing
the variable called t._test__i without expecting side
Op 2005-09-30, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-09-30, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-09-29, Bill Mill schreef [EMAIL PROTECTED]:
But, if your users can't figure out that they shouldn't be changing
the variable called
El Pitonero [EMAIL PROTECTED] writes:
The thing is, there are two sides to every coin. Features surely can
be viewed as goodies, or they can be viewed as handcuffs.
Let's see, say I'm a bank manager, and I want to close my cash vault
at 5pm today and set its time lock so it can't be opened
Paul Rubin http://[EMAIL PROTECTED] writes:
def countdown():
n = 3
while n 0:
yield n
Bah, ommitted a line:
def countdown():
n = 3
while n 0:
yield n
n -= 1
--
http://mail.python.org/mailman/listinfo/python-list
On 03 Oct 2005 00:22:22 -0700, Paul Rubin http://[EMAIL PROTECTED] wrote:
El Pitonero [EMAIL PROTECTED] writes:
The thing is, there are two sides to every coin. Features surely can
be viewed as goodies, or they can be viewed as handcuffs.
Let's see, say I'm a bank manager, and I want to close
Op 2005-09-30, Steven D'Aprano schreef [EMAIL PROTECTED]:
On Fri, 30 Sep 2005 07:37:14 +, Antoon Pardon wrote:
Well I have the following reasons not to like the current python way:
1) Beginning all your private variables with an underscore is like
starting all your integers with an 'i'
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
Privilege separation is considered a good coding practice. How does
Python help it?
With conventions and name mangling. Which are only slightly less
effective than the C++/Java technic for doing the same
Op 2005-09-30, Rocco Moretti schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
What if the class author removes a non-private variable or changes a
method's documented parameters in the next version of the class, because
he think it'll work better, or just because he can?
Changing an
Mike Meyer [EMAIL PROTECTED] writes:
That's not what privilege separation means. It means that the
privileged objects stay secure even when the unprivileged part of the
program is completely controlled by an attacker.
In which case, what's private got to do with this? The examples I've
[EMAIL PROTECTED] (Bengt Richter) writes:
Would you want to outlaw 'None' as an attribute name?
Python seems to be straddling the fence at this point:
c.None = 'c.None'
SyntaxError: assignment to None
Heehee, I think that's just a compiler artifact, the lexer is treating
None as a keyword
On 03 Oct 2005 04:47:26 -0700, Paul Rubin http://[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bengt Richter) writes:
Would you want to outlaw 'None' as an attribute name?
Python seems to be straddling the fence at this point:
c.None = 'c.None'
SyntaxError: assignment to None
Heehee, I
On Mon, 03 Oct 2005 09:14:34 +, Antoon Pardon wrote:
If you are in a project with
multiple authors, your usage of private variables can break code
that other people rely on.
If you are in a project with multiple authors, your usage of PUBLIC
variables can break code that other people rely
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
No, but that is precisely why Python's semi-private variables are
usually better. Names like _X and class.__X are warnings to the developer
use these at your own risk, without preventing developers who need them
from using them. You
Paul Rubin http://[EMAIL PROTECTED] writes:
That's not what privilege separation means. It means that the
privileged objects stay secure even when the unprivileged part of the
program is completely controlled by an attacker.
In which case, what's private got to do with this? The examples
Mike Meyer [EMAIL PROTECTED] writes:
If you have a java class instance with a private member that's (say) a
network socket to a special port, access to the port is controlled
entirely by that class.
Are you sure? My understanding was that Java's introspection mechanism
could be used to
Paul Rubin http://[EMAIL PROTECTED] writes:
A couple of other things to think about:
Are you sure you want to use the C++ model for privilege separation?
I'm not sure what you mean by the C++ model. If you mean the Java
model, as I keep saying, applet sandbox security relies on it, so it
may
On 03 Oct 2005 14:45:43 -0700, Paul Rubin http://[EMAIL PROTECTED] wrote:
Mike Meyer [EMAIL PROTECTED] writes:
If you have a java class instance with a private member that's (say) a
network socket to a special port, access to the port is controlled
entirely by that class.
Are you sure?
On 30 Sep 2005 05:23:35 -0700, Paul Rubin http://[EMAIL PROTECTED] wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
It's not easy if the base classes change after you check your code in.
You shouldn't need to know about that if it happens. Modularity, remember?
Yes. And if you are relying
[EMAIL PROTECTED] (Bengt Richter) writes:
I decided to read this thread today, and I still don't know exactly
what your requirements are for private whatevers. No one seems to
have discussed what you could do with properties and __getattribute__
and metaclasses and decorators, yet there are
1) Something that fixes the broken name mangling in the current
system, but still doesn't try to defeat intentional unmangling.
Currently, if you have a class with the same name as one of its
superclasses, the name mangling can fail even its existing purpose of
preventing accidental
Bengt Richter wrote:
I decided to read this thread today, and I still don't know exactly
what your requirements are for private whatevers.
No name collision in subclassing. Notice that even if you use
self._x = 3
in a parent class, it can be overriden in a sub-sub-class accidentally.
Or
El Pitonero [EMAIL PROTECTED] wrote:
Python's lack of Java-style private surely has its drawback: name
collisions can happen. But, that's just one side. Name collisions are
allowed in many dynamic languages, where you can override the default
system behavior (in some languages, you can
El Pitonero schrieb:
The fact that you can override Python's list() function can be either
viewed as pro or con. The fact that you can override member variables
can also be viewed as pro or con.
If there is a tool like pyChecker, which can detect such pitfalls and
warns but not forbidds -
Mike Meyer [EMAIL PROTECTED] writes:
Yes, the point is that it's something that you can check for by
examining the class in question without having to examine any other
classes.
That's a pretty restrictive convention to follow.
What convention? It just makes it possible to write code
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
Yes, the point is that it's something that you can check for by
examining the class in question without having to examine any other
classes.
That's a pretty restrictive convention to follow.
What
Paul Rubin http://[EMAIL PROTECTED] writes:
Well, it's a discussion of why a certain feature might be useful, not
that it's required. Mike Meyer points out some reasons it might be
hard to do smoothly without changing Python semantics in a deep way
(i.e. Python 3.0 or later).
Actually, I
On Sun, 02 Oct 2005 12:05:53 -0700, Paul Rubin wrote:
I just don't understand your point here. Yes, you can do all those
things and leak any variable. However, if you want to NOT leak some
particular variable, private lets you code in a way that lets you
easily confirm that you didn't leak
Mike Meyer [EMAIL PROTECTED] writes:
What convention? It just makes it possible to write code with some
specific invariants if there's a need to do so.
That you don't pass private variables to a function unless it's a builtin.
No, I don't see that as convention, it's just something that
Steven D'Aprano [EMAIL PROTECTED] writes:
The philosophy of dynamic languages like Python is that the class designer
shouldn't be the only one who decides whether or not a particular variable
should be private or public.
I don't see that as part of the philosophy of dynamic languages. For
Mike Meyer [EMAIL PROTECTED] writes:
Actually, I think that the semantic changes required to make private
do what you want are deep enough that the resulting language
wouldn't be Python any longer. It has deep implications from the
interpeter implementation all the way out to the design of the
Mike Meyer [EMAIL PROTECTED] writes:
Compile-time restrictions don't matter for squat - you need
serious restrictions on what the program can do at runtime.
You need both.
Yup. Any language besides Java even *try* to provide both for a
production environment?
Yes. Python tried. It
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
What convention? It just makes it possible to write code with some
specific invariants if there's a need to do so.
That you don't pass private variables to a function unless it's a builtin.
No, I don't see
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
Compile-time restrictions don't matter for squat - you need
serious restrictions on what the program can do at runtime.
You need both.
Yup. Any language besides Java even *try* to provide both for a
Mike Meyer [EMAIL PROTECTED] writes:
I'd say CPython was missing the features that you need to guarantee
that. Missing quite a *lot* of features, in fact. But Python has never
been about keeping people from writing bad code - it's about helping
people write good code.
Privilege separation is
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
Which brings me to my point. Rather than trying to bandage Python to
do what you want - and what, based on this thread, a lot of other
people *don't* want - you should be building a system from the ground
up to
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
I'd say CPython was missing the features that you need to guarantee
that. Missing quite a *lot* of features, in fact. But Python has never
been about keeping people from writing bad code - it's about helping
On Sun, 02 Oct 2005 16:42:49 -0400, Mike Meyer [EMAIL PROTECTED] wrote:
Paul Rubin http://[EMAIL PROTECTED] writes:
Well, it's a discussion of why a certain feature might be useful, not
that it's required. Mike Meyer points out some reasons it might be
hard to do smoothly without changing
Mike Meyer [EMAIL PROTECTED] writes:
Privilege separation is considered a good coding practice. How does
Python help it?
With conventions and name mangling. Which are only slightly less
effective than the C++/Java technic for doing the same thing.
That's not what privilege separation
Mike Meyer [EMAIL PROTECTED] writes:
Unless your compiler detects and flags passing private variables to
external functions all you've got is a convention that you don't pass
private variables to external functions.
Yes, the point is that it's something that you can check for by
examining the
Steven D'Aprano [EMAIL PROTECTED] writes:
A cautionary tale of what happens when religious wars enter programming
debates. For all I know, Paul Rubin is intelligent, gentle, kind to
animals and small children, generous, charitable and modest.
Don't bet on it.
But touch his religious belief
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
Unless your compiler detects and flags passing private variables to
external functions all you've got is a convention that you don't pass
private variables to external functions.
Yes, the point is that it's
On 30 Sep 2005 15:00:39 -0700
Paul Rubin wrote:
Rocco Moretti [EMAIL PROTECTED] writes:
There is little in the way of technical problems that are solved by
language level enforcement of private variables. The issues in
question are mostly social ones, and if you're not reading and
On 30 Sep 2005 22:11:46 +
John J. Lee wrote:
Steve Holden [EMAIL PROTECTED] writes:
That would make a good Onion (www.TheOnion.com) headline: Users
Discover Computer Security Conflicts with Desire for Convenience
:-) The Onion, yay.
Area Man Forgets Work Password, Will Employ
Op 2005-09-29, Bill Mill schreef [EMAIL PROTECTED]:
But, if your users can't figure out that they shouldn't be changing
the variable called t._test__i without expecting side effects, what do
you think of the users of your class?
Python is for consenting adults.
No it is not. Consenting
Op 2005-09-29, Simon Brunning schreef [EMAIL PROTECTED]:
On 9/29/05, could ildg [EMAIL PROTECTED] wrote:
**Encapsulation** is one of the 3 basic characteristics of OOP.
Pyhton has encapsulation. On objetcts members are encapsulated in a
namespace all of its own. You can't change these by
Dennis Lee Bieber [EMAIL PROTECTED] writes:
They did? Fine... Add another that Python names beginning with _ or
__ are not to be accessed from outside the module/class that defined
them. And if one is not the owner of that module/class, they should
contact the responsible person and
Op 2005-09-29, Rocco Moretti schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
On Fri, 30 Sep 2005 00:16:02 +1000
Steven D'Aprano wrote:
Say you have written a class, with a private variable. I decide that I
need access to that variable, for reasons you never foresaw.
What if the access
Op 2005-09-29, Steve Holden schreef [EMAIL PROTECTED]:
Think about it: we have a language that has an eval() function and an
exec statement, and people are concerned that some service consumer
shouldn't be allowed to go poking around inside namespaces? What do we
have to do, put up signs
[EMAIL PROTECTED] wrote:
On Fri, 30 Sep 2005 06:31:44 +0200
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
Looks like you must know every one of the base classes of the NotSoSecret,
whether there is some base class named Secret? And, if so, you must also
know these classes _implementation_
Antoon Pardon wrote:
Op 2005-09-29, Bill Mill schreef [EMAIL PROTECTED]:
But, if your users can't figure out that they shouldn't be changing
the variable called t._test__i without expecting side effects, what do
you think of the users of your class?
Python is for consenting adults.
No it
Steve Holden [EMAIL PROTECTED] writes:
Good grief, the ultimate choice is to use Python because you like it,
or not to use it because you don't. Enough with the picking every
available nit, please. Consent or stop complaining :-)
Riiight. If she was walking in that neighborhood she must have
[EMAIL PROTECTED] wrote:
So you have read every line of the python std library, I guess?
yes, but that's irrelevant. in python, you don't need the source to find hidden
stuff. finding out is a matter of writing a very small program, or tinkering
at the
interactive prompt for a couple of
Antoon Pardon wrote:
Op 2005-09-29, Steve Holden schreef [EMAIL PROTECTED]:
Think about it: we have a language that has an eval() function and an
exec statement, and people are concerned that some service consumer
shouldn't be allowed to go poking around inside namespaces? What do we
have
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
Good grief, the ultimate choice is to use Python because you like it,
or not to use it because you don't. Enough with the picking every
available nit, please. Consent or stop complaining :-)
Riiight. If she was walking in that
Steve Holden wrote:
1) Allow keywords like private (or implemetation) to mark certain
variables, functions or classes as an implementation detail.
Personnally I would prefer the opposite such as a interface
to mark objects which are not private, but that would break too
much code.
Just an
Gregor Horvath [EMAIL PROTECTED] writes:
Real open source live example from yesterdays mailinglists:
I don't see any use of name mangling in that example.
Someone has a problem and tweaks a private variable as a workaround.
They should have patched the source instead.
No python program
Op 2005-09-30, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-09-29, Steve Holden schreef [EMAIL PROTECTED]:
Think about it: we have a language that has an eval() function and an
exec statement, and people are concerned that some service consumer
shouldn't be allowed
Op 2005-09-30, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-09-29, Bill Mill schreef [EMAIL PROTECTED]:
But, if your users can't figure out that they shouldn't be changing
the variable called t._test__i without expecting side effects, what do
you think of the users of
Op 2005-09-30, Fredrik Lundh schreef [EMAIL PROTECTED]:
Steve Holden wrote:
1) Allow keywords like private (or implemetation) to mark certain
variables, functions or classes as an implementation detail.
Personnally I would prefer the opposite such as a interface
to mark objects which are not
Paul Rubin wrote:
Gregor Horvath [EMAIL PROTECTED] writes:
Someone has a problem and tweaks a private variable as a workaround.
They should have patched the source instead.
I think they are going to do that. In the meantime our friend has a
working solution otherwise he would have
On Fri, 30 Sep 2005 06:31:44 +0200, Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
Looks like you must know every one of the base classes of the NotSoSecret,
whether there is some base class named Secret? And, if so, you must also
know these classes _implementation_
that information isn't
Antoon Pardon wrote:
Op 2005-09-30, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-09-29, Bill Mill schreef [EMAIL PROTECTED]:
But, if your users can't figure out that they shouldn't be changing
the variable called t._test__i without expecting side effects, what do
you
On Fri, 30 Sep 2005 06:52:50 +, Antoon Pardon wrote:
Op 2005-09-29, Bill Mill schreef [EMAIL PROTECTED]:
But, if your users can't figure out that they shouldn't be changing
the variable called t._test__i without expecting side effects, what do
you think of the users of your class?
Steven D'Aprano [EMAIL PROTECTED] writes:
Still, [EMAIL PROTECTED]'s point that you must know the base classes
is correct. It is *easy* to find them out (NotSoSecret.__bases__ should do
it), but if you don't you are taking a chance that your class name doesn't
clash with one of the bases.
On Fri, 30 Sep 2005 00:58:17 -0700, Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
Good grief, the ultimate choice is to use Python because you like it,
or not to use it because you don't. Enough with the picking every
available nit, please. Consent or stop complaining :-)
On Fri, 30 Sep 2005 07:37:14 +, Antoon Pardon wrote:
Well I have the following reasons not to like the current python way:
1) Beginning all your private variables with an underscore is like
starting all your integers with an 'i' or all your dictionary with
a 'd' etc.
Three points:
(1)
Steven D'Aprano [EMAIL PROTECTED] writes:
2) Allow the client access to these private variables, through
a special construct. Maybe instead of from ... import ...
from ... spy
What you are suggesting is that you have private variables that are only
private by convention, since
On Fri, 30 Sep 2005 03:42:32 -0700, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Still, [EMAIL PROTECTED]'s point that you must know the base classes
is correct. It is *easy* to find them out (NotSoSecret.__bases__ should do
it), but if you don't you are taking a chance that
Steven D'Aprano [EMAIL PROTECTED] writes:
It's not easy if the base classes change after you check your code in.
You shouldn't need to know about that if it happens. Modularity, remember?
Yes. And if you are relying on a public method in a class, and somebody
dynamically modifies that
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
2) Allow the client access to these private variables, through
a special construct. Maybe instead of from ... import ...
from ... spy
What you are suggesting is that you have private variables that are only
private by convention,
Antoon Pardon wrote:
What if the class author removes a non-private variable or changes a
method's documented parameters in the next version of the class, because
he think it'll work better, or just because he can?
Changing an interface is different from changing the implementation.
A
Paul Rubin wrote:
I don't know of a single program that's actually relying on the
non-enforcement. I've asked for examples but have only gotten
theoretical ones. As far as I can tell, the feature is useless.
I'd like to turn the question around on you - can you come up with an
instance
Rocco Moretti wrote:
Antoon Pardon wrote:
[...]
It helps, just as locks wont save you from burglars if they really
want to rob you, but the locks do help.
Right, but like doors that automatically lock when they close, items
which are there to protect you can be a nusaince, especially when
On Friday 30 September 2005 01:58, Paul Rubin http://[EMAIL PROTECTED]
([EMAIL PROTECTED]) wrote:
Steve Holden [EMAIL PROTECTED] writes:
Good grief, the ultimate choice is to use Python because you like it,
or not to use it because you don't. Enough with the picking every
available nit,
Steve Holden [EMAIL PROTECTED] writes:
That would make a good Onion (www.TheOnion.com) headline: Users
Discover Computer Security Conflicts with Desire for Convenience
+1 QOTW
--
http://mail.python.org/mailman/listinfo/python-list
Rocco Moretti [EMAIL PROTECTED] writes:
There is little in the way of technical problems that are solved by
language level enforcement of private variables. The issues in
question are mostly social ones, and if you're not reading and
following the documented interface, stopping private
Steve Holden [EMAIL PROTECTED] writes:
Rocco Moretti wrote:
[...]
Right, but like doors that automatically lock when they close, items
which are there to protect you can be a nusaince, especially when you've
left your keys on the dining room table.
That would make a good Onion
Paul Rubin http://[EMAIL PROTECTED] writes:
OTOH, private lets you say 100% for certain that another class
didn't clobber __xyz, and that any bug that clobbered it MUST reside
in the class that declared it. That makes auditing for __xyz-related
errors a lot simpler since you only have to look
Mike Meyer [EMAIL PROTECTED] writes:
So, fool._bar is now clobbered. Nuts, the _bar attribute is broken for
*every* instance of Fools. According to you, the error must be in
Fools. Care to point it out?
Yes, the error is in the breaker function, which leaks the private
variable to other
Paul Rubin http://[EMAIL PROTECTED] writes:
Mike Meyer [EMAIL PROTECTED] writes:
So, fool._bar is now clobbered. Nuts, the _bar attribute is broken for
*every* instance of Fools. According to you, the error must be in
Fools. Care to point it out?
Yes, the error is in the breaker function,
Paul Rubin schrieb:
Huh? If my car has a feature that lets someone blow it to
smithereens from hundreds of miles away without even intending to,
that's somehow an advantage?
I would not accept a car that does constraint my driving directions. I
want to drive for myself, because its fun.
Gregor Horvath [EMAIL PROTECTED] writes:
One reason is that it does not restrict the programer to tight und has
genuine simple solutions, like the one with private instance
variables.
If you don't want the compiler to make sure your private instance
variables stay private, then don't declare
Steve Holden wrote:
could ildg wrote:
Python is wonderful except that it has no real private and protected
properties and methods.
Every py object has dict so that you can easily find what fields and
methods an obj has,
this is very convenient, but because of this, py is very hard to
Dennis Lee Bieber [EMAIL PROTECTED] writes:
Ah, but in the way of your code -- it is not your car... It is the
car you supplied to someone hundreds of miles away... And they are
perfectly free to open the hood... tamper with the engine programming, etc.
I don't understand what you're
Paul Rubin schrieb:
If you don't want the compiler to make sure your private instance
variables stay private, then don't declare them that way. You're the
one asking for less flexibility.
I want to declare them as privat, but want to give the flexibilty to
access them at the users own
Gregor Horvath [EMAIL PROTECTED] writes:
If you don't want the compiler to make sure your private instance
variables stay private, then don't declare them that way. You're the
one asking for less flexibility.
I want to declare them as private, but want to give the flexibilty to
access
On Wed, 28 Sep 2005 08:14:50 -0500
Chris Gonnerman wrote:
There are two philosophies about programming:
-- Make it hard to do wrong.
-- Make it easy to do right.
What you are promoting is the first philosophy: Tie the programmer's
hands so he can't do wrong. Python for the most part
Paul Rubin schrieb:
You could have a friend declaration like in C++, if you want to let
some class see the private instance variables of another class.
Everything is said on this topic. There are two ligitimate solutions to
the problem of private instance variables. Its a matter of taste,
Gregor Horvath [EMAIL PROTECTED] writes:
Everything is said on this topic. There are two ligitimate solutions
to the problem of private instance variables. Its a matter of taste,
and mine is the pythonic one.
The Pythonic solution is to have both solutions available, and Python
in fact used to
Paul Rubin wrote:
Gregor Horvath [EMAIL PROTECTED] writes:
If you don't want the compiler to make sure your private instance
variables stay private, then don't declare them that way. You're the
one asking for less flexibility.
I want to declare them as private, but want to give the flexibilty
Paul Rubin wrote:
If changing the way a class uses its own private variables breaks an
application
because another class was using the private variable unexpectedly,
then that's bad, regardless of whether the other class's author was
notified or not. It's better to let the compiler
On Wed, 28 Sep 2005 22:07:56 -0700, Paul Rubin wrote:
One that is in other languages not even possible. A clear disadvantage.
Python gives me power and does not take it away like the others.
Huh? If my car has a feature that lets someone blow it to
smithereens from hundreds of miles away
On Fri, 30 Sep 2005 00:16:02 +1000
Steven D'Aprano wrote:
Say you have written a class, with a private variable. I decide that I
need access to that variable, for reasons you never foresaw.
What if the access to that variable was forbidden for reasons you never
foresaw? What if the class
1 - 100 of 173 matches
Mail list logo
