RE: Will python never intend to support private, protected and public?

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 en

Re: Will python never intend to support private, protected and public?

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 publ

Re: Will python never intend to support private, protected and public?

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 > > > . > > > > That's a wonder

Re: Will python never intend to support private, protected and public?

"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

Re: Will python never intend to support private, protected and public?

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 > distr

Re: Will python never intend to support private, protected and public?

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 author

Re: Will python never intend to support private, protected and public?

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, h

Re: Will python never intend to support private, protected and public?

On 03 Oct 2005 14:45:43 -0700, Paul Rubin 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. >> >

Re: Will python never intend to support private, protected and public?

Paul Rubin 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

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

Paul Rubin 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?

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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 re

Re: Will python never intend to support private, protected and public?

On 03 Oct 2005 04:47:26 -0700, Paul Rubin 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 >

Re: Will python never intend to support private, protected and public?

[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 ke

Re: Will python never intend to support private, protected and public?

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 exam

Re: Will python never intend to support private, protected and public?

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? >> >> Chan

Re: Will python never intend to support private, protected and public?

Paul Rubin 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

Re: Will python never intend to support private, protected and public?

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 w

Re: Will python never intend to support private, protected and public?

On 03 Oct 2005 00:22:22 -0700, Paul Rubin 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

Re: Will python never intend to support private, protected and public?

Paul Rubin 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

Re: Will python never intend to support private, protected and public?

"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 op

Re: Will python never intend to support private, protected and public?

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'

Re: Will python never intend to support private, protected and public?

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 ex

Re: Will python never intend to support private, protected and public?

On 2 Oct 2005 10:31:07 -0700, "El Pitonero" <[EMAIL PROTECTED]> wrote: >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

Re: Will python never intend to support private, protected and public?

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 separa

Re: Will python never intend to support private, protected and public?

On Sun, 02 Oct 2005 16:42:49 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote: >Paul Rubin 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 ch

Re: Will python never intend to support private, protected and public?

Paul Rubin 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 hel

Re: Will python never intend to support private, protected and public?

Paul Rubin 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 groun

Re: Will python never intend to support private, protected and public?

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 separatio

Re: Will python never intend to support private, protected and public?

Paul Rubin 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

Re: Will python never intend to support private, protected and public?

Paul Rubin 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

Re: Will python never intend to support private, protected and public?

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. Pyth

Re: Will python never intend to support private, protected and public?

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 o

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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 somethi

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

Paul Rubin 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

Re: Will python never intend to support private, protected and public?

Paul Rubin 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.

Re: Will python never intend to support private, protected and public?

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 writ

Re: Will python never intend to support private, protected and public?

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 forb

Virgin keyword (Was: Will python never intend to support private, protected and public?)

"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 ca

Re: Will python never intend to support private, protected and public?

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. >

Re: Will python never intend to support private, protected and public?

> 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 colli

Re: Will python never intend to support private, protected and public?

[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 a

Re: Will python never intend to support private, protected and public?

On 30 Sep 2005 05:23:35 -0700, Paul Rubin 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 y

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private,protected and public?

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

Re: Will python never intend to support private, protected and public?

Paul Rubin 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 tha

Re: Will python never intend to support private, protected and public?

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 bel

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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. But touch his religious belief in the necessity of "truly" private variables, and boy oh boy does

Re: Will python never intend to support private, protected and public?

Paul Rubin 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 "breake

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

Paul Rubin 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

Re: Will python never intend to support private, protected and public?

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 Onio

Re: Will python never intend to support private, protected and public?

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 va

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

On Friday 30 September 2005 01:58, Paul Rubin (<[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 >> availabl

Re: Will python never intend to support private, protected and public?

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, especial

Re: Will python never intend to support private, protected and public?

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 w

Re: Will python never intend to support private, protected and public?

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.

Re: Will python never intend to support private, protected and public?

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 >>

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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 conventio

Re: Will python never intend to support private, protected and public?

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:

Re: Will python never intend to support private, protected and public?

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 :-) >

Re: Will python never intend to support private, protected and public?

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.

Re: Will python never intend to support private, protected and public?

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 cla

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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 informat

Re: Will python never intend to support private, protected and public?

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 hav

Re: Will python never intend to support private, protected and public?

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 object

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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 >>>sh

Re: Will python never intend to support private, protected and public?

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 p

Re: Will python never intend to support private, protected and public?

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.

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

[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 seco

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

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

Re: Will python never intend to support private, protected and public?

[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

Re: Will python never intend to support private, protected and public?

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 si

Re: Will python never intend to support private, protected and public?

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. >> >> W

Re: Will python never intend to support private, protected and public?

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 a

Re: Will python never intend to support private, protected and public?

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 thes

Re: Will python never intend to support private, protected and public?

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. Consenti

Re: Will python never intend to support private, protected and public?

Paul Rubin schrieb: > 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. No python program will rely by defin

Re: Will python never intend to support private, protected and public?

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. -- http://mail.python.org/mailman/listinfo/python-list

Re: Will python never intend to support private, protected and public?

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 inform

Re: Will python never intend to support private, protected and public?

Paul Rubin schrieb: > > 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. Real open source live example from yesterdays mailinglists: quick question:

Re: Will python never intend to support private, protected and public?

Gregor Horvath <[EMAIL PROTECTED]> writes: > Are the numerous working python open source projects not multi-person > software projects? Even multiple persons that even dont know each > other and can discuss the latest news at the coffee machine? There are not that many such projects being done in

Re: Will python never intend to support private, protected and public?

[EMAIL PROTECTED] wrote: >> > Do you ever heard of that funny things named "an interface" and "an >> > implementation"? >> >> the "shared DLL:s ought to work" school of thought, you mean? > > No, the other way around: my app works when I upgrade libraries it depends > on. yeah, because it's only

Re: Will python never intend to support private, protected and public?

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > > 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 hidden, so there's nothing "you

Re: Will python never intend to support private, protected and public?

Paul Rubin schrieb: > Bill Mill <[EMAIL PROTECTED]> writes: > >>Python is for consenting adults. > > Python might be for consenting adults, but multi-person software > projects are supposed to be done in the workplace, not the bedroom. Are the numerous working python open source projects not mul

Re: Will python never intend to support private, protected and public?

[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 hidden, so there's nothing "you must know". finding out is

Re: Will python never intend to support private, protected and public?

On Thu, 29 Sep 2005 21:05:28 +0200 Fredrik Lundh wrote: > [EMAIL PROTECTED] wrote: > > > Do you ever heard of that funny things named "an interface" and "an > > implementation"? > > the "shared DLL:s ought to work" school of thought, you mean? No, the other way around: my app works when I upgra

Re: Will python never intend to support private, protected and public?

On Thu, 29 Sep 2005 16:59:01 +0200 Fredrik Lundh wrote: > as long as you don't cheat, that is: > > # your code > > class Secret: > def __init__(self): > self.__hidden = "very secret value" > > # my code > > from yourcode import Secret > > class Secret(Secret): > def gethidden(

  1   2   >