[baavgai]

jon.kiparsky, on 18 September 2012 - 11:27 AM, said:

The reasons for private access are good ones: it increases modularity and decreases chances for bugs.

Those are reasons for encapsulation.

jon.kiparsky, on 18 September 2012 - 11:27 AM, said:

we wouldn't want to advise a Java programmer to use only public access, would we?

Absolutely not. What's public is meant to be used by any other code, after all. That's Java.

Now, in Python, I throw a couple of underscores in front of the method. I tell you, the programmer, that it's not public. The language doesn't stop you from ignoring this, but that's your own damn fault.

Do you NEED the language to stop you? I'm serious. Security levels are tools, telling the programmer what do to. You can make it clear what's meant to be used and what isn't without hiding. So, you hide because... ?

[duffman18]

baavgai, on 18 September 2012 - 11:58 AM, said:

Now, in Python, I throw a couple of underscores in front of the method. I tell you, the programmer, that it's not public. The language doesn't stop you from ignoring this, but that's your own damn fault.

Pretty much took the words out of my mouth. All you need is a documented standard to denote between private and public, you don't NEED the language to bar you from all private data. It serves the same purpose and will have the same effect of reducing the chance of bugs. If the people using your class can't follow your documentation then that is not your fault and those people probably shouldn't be using Python because they are not "adult" enough.

[jon.kiparsky]

Quote

If the people using your class can't follow your documentation then that is not your fault and those people probably shouldn't be using Python because they are not "adult" enough.

This sounds like half-baked ideology to me, not a coherent argument for a language design decision.

Access control is a mechanism for promoting code clarity and reducing unintended coupling. That is a good thing. Losing that is a significant cost on a large project. What do I gain from that tradeoff, aside from a license to smug?

Quote

Do you NEED the language to stop you? I'm serious. Security levels are tools, telling the programmer what do to. You can make it clear what's meant to be used and what isn't without hiding. So, you hide because... ?

They are tools, and they are very useful tools, because they limit the sorts of mistakes that can be made. So I restrict access, because it means the code happens faster and easier. Why should I make my life gratuitously more difficult?

[sepp2k]

It should be mentioned that it is perfectly possible to read and set private variables of an object in Java (using reflection). Java just makes it harder than Python - not impossible. So in the end, you're still relying on the user of your class to not do anything stupid.

[baavgai]

Who is introducing these mistakes? Who, exactly are you restricting? I'm not being coy here, just asking you to think about it.

A programmer doesn't call a monstrosity like Foo()._Foo__bar() by mistake. That's an intentional misuse of the class.

If it's just you, there's nothing to be afraid of; you know to behave yourself. If you're working with a team, the ground rules are clear. Just because you can see it, doesn't mean you mess with it.

Even in a tightly locked down private OO world, scenarios still come up were more is exposed than you'd like. Or, you're forced to interop with other systems. You follow convention and avoid doing those things you know will cause problems.

Again, if it's you, it's moot. If it's people you work with, it should still be moot. Where is the bugbear waiting for you to leave some magic door open so it can come in and ransack the place?

[jon.kiparsky]

sepp2k, on 18 September 2012 - 03:06 PM, said:

It should be mentioned that it is perfectly possible to read and set private variables of an object in Java (using reflection). Java just makes it harder than Python - not impossible. So in the end, you're still relying on the user of your class to not do anything stupid.

Sure, but I didn't say it was impossible to make a mistake in Java. I said Java uses a reasonable elementary precaution to make it easy to manage complexity. Python rejects that. It seems to me that we like languages that help us manage complexity - for example, removing the need to iterate over lists by index, providing map and reduce and filter functions to eliminate the need to iterate at all, and then providing list comprehensions to eliminate the complexity of the map, reduce, and filter functions. At one level, python is all about managing complexity. I want to know why we don't want to manage complexity at the level of object interactions.

[jon.kiparsky]

baavgai, on 18 September 2012 - 03:17 PM, said:

Again, if it's you, it's moot. If it's people you work with, it should still be moot. Where is the bugbear waiting for you to leave some magic door open so it can come in and ransack the place?

This is a bit of a straw man, don't you think? I mean, when you find a bug in your code, you don't look for a bugbear, you fix the bug. And if you're smart, you think about how it happened. Over time, massively-coupled classes have become recognized as bug farms. So we like to reduce coupling.

I still don't see why losing access restriction is a good thing. Is there any good reason not to have control over your interface?

[baavgai]

jon.kiparsky, on 18 September 2012 - 04:40 PM, said:

Over time, massively-coupled classes have become recognized as bug farms. So we like to reduce coupling.

Absolutely agree. I don't see how this has anything to do with security based on convention rather than enforcement, though.

jon.kiparsky, on 18 September 2012 - 04:40 PM, said:

I still don't see why losing access restriction is a good thing. Is there any good reason not to have control over your interface?

You see control, I see blind adherence to an unnecessary paradigm. Ok, that the devil's advocate talking.

When I work in Java, or more often C#, I data hide with the best of them. I understand the perspective. I understand being offended that such an "obvious" feature is missing from Python. Seeing public fields in a class makes me twitch. But, in Python, as with any language, you try to understand the philosophy of design to get the most out of it.

jon.kiparsky, on 18 September 2012 - 04:33 PM, said:

At one level, python is all about managing complexity. I want to know why we don't want to manage complexity at the level of object interactions.

Part of managing complexity is not introducing it. You've seen the Java classes that are all getters and setters, half of which usually aren't needed. You can get completely immersed in good OO design principles and end up getting frighteningly little implementation done.

I've been there, making reusable frameworks at every turn, abstracting like there's no tomorrow, interfaces, factories, design patterns, draconian separation of concerns, deep object hierarchies... oh, the humanity. As many problems as OOP solves, it introduces it's own complexity.

Python is refreshing in that at lot of the OO baggage can be ignored, where appropriate. In this respect, it's a lot like C++, only with less mess.

I see the lack of security as part of the Python package, along with things like duck typing.

[Gamegoofs2]

When this discussion started off I was whole heartily for Java's protection. Now though, I think Python gets it right. Do we really need the language to force us to have private and protected? When a convention would do just as well. Personally I like the convention way better. It makes things simpler and less to learn. The only problem I can see arising is if someone miss uses the double underscore convention.

[jon.kiparsky]

Gamegoofs2, on 18 September 2012 - 07:51 PM, said:

When this discussion started off I was whole heartily for Java's protection. Now though, I think Python gets it right. Do we really need the language to force us to have private and protected? When a convention would do just as well. Personally I like the convention way better. It makes things simpler and less to learn. The only problem I can see arising is if someone miss uses the double underscore convention.

I think you've got it the wrong way around. Java doesn't force anything to be private. If you want the python approach, it's easy enought to declare everything public. Done, sorted. Everyone has access, and you avoid the confusion created by the mangled names - if you want to give people access, give them access.
Or, if you want, and most people prefer this once they've written a few programs of any size, you can communicate correctly and clearly what pieces of the program you're presenting as public-facing, and what you're not.

Python, it seems, forces everything to be public. And this, it seems to me, poses a huge problem if you're writing anything of any size or complexity.

I was hoping for a more substantive reason why this would be a good thing, but I really haven't heard anything substantial - and when guys this smart can't come up with a good reason, I'm pretty sure there isn't one.

Quote

Part of managing complexity is not introducing it. You've seen the Java classes that are all getters and setters, half of which usually aren't needed. You can get completely immersed in good OO design principles and end up getting frighteningly little implementation done.

Getters and setters? That sounds like code written by someone who's never heard of good design principles, frankly. Good OO design actually produces better code, quicker - if it didn't then we'd still be writing plain old ordinary C and python, perl, and whatnot wouldn't have object models built into them.

Yes, you can write bad java, and people do. However, it's hard for me to see how this is a good argument for you since you can't not write the setters and getters in python. They're there, implicitly, and you can't unwrite them. So if that complexity is bad in Java, it's unavoidably bad in python. What you're saying with that argument is that there is good code that can be written in Java that you simply can't write in python.

And it simply won't do to claim that python programmers are somehow protected by the python force-field, that "we're all adults here". Python programmers are not inherently better, or more cautious, or more mature, or less reckless, or less hagridden by evil managers, or luckier, or whatever than other programmers, and it's crazy to suppose that this is the case.

Quote

But, in Python, as with any language, you try to understand the philosophy of design to get the most out of it.

That's what I'm asking for, but there really doesn't seem to be a design philosophy behind this decision at all. At least, it's not one that's been articulated yet.

I think this is really not going anywhere. Thanks for trying, but based on what you're telling me, this is just a total faceplant. I guess every language has its design goofs - Java has more than a few! - and this is one of python's.

This post has been edited by jon.kiparsky: 18 September 2012 - 07:14 PM

[baavgai]

I agree, we're going to have to agree to disagree. Not that I completely disagree. Rather, I don't see the NEED as much as you. And I believe that insight is valuable.

jon.kiparsky, on 18 September 2012 - 10:10 PM, said:

Or, if you want, and most people prefer this once they've written a few programs of any size, you can communicate correctly and clearly what pieces of the program you're presenting as public-facing, and what you're not.

Completely agree. Clarity is required. Language enforcement is, obviously, debatable.

jon.kiparsky, on 18 September 2012 - 10:10 PM, said:

Python, it seems, forces everything to be public.

Well, everything IS public and there's no mechanism to avoid that. We just have to rely on programmers behaving themselves. The horror.

jon.kiparsky, on 18 September 2012 - 10:10 PM, said:

I was hoping for a more substantive reason why this would be a good thing

I don't have one. More control, more gooder. But, then, Python trusts me not to be an idiot. I appreciate that. Perhaps that's the only reason I need; a language that respects me enough to allow me to hurt myself. In this way, it's much like C, only with less toes being blown off.

jon.kiparsky, on 18 September 2012 - 10:10 PM, said:

Python programmers are not inherently better, or more cautious, or more mature, or less reckless, or less hagridden by evil managers, or luckier, or whatever than other programmers, and it's crazy to suppose that this is the case.

Agreed. Programmers can write hideious crap in any language. There is no language that can stop them. I don't believe Python is immune to this nor do I believe I ever implied it.

jon.kiparsky, on 18 September 2012 - 10:10 PM, said:

Getters and setters? That sounds like code written by someone who's never heard of good design principles, frankly.

That would be Sun. They formalized the convention when they started with JavaBeans. I'm not sure what your issue is with this, it's a standard way of exposing properites of an object. Which is the better design? Perhaps we're not on the same page here?

jon.kiparsky, on 18 September 2012 - 10:10 PM, said:

it's hard for me to see how this is a good argument for you since you can't not write the setters and getters in python. They're there, implicitly, and you can't unwrite them.

I'm honestly not following. Do you mean you can't hide the variables? Sure. But you can mark them private. You can write methods to control access. Again, you are still relying on the programmer not to be an idiot.

[Gamegoofs2]

I think I could be on both sides of the fence. I love Java and I've fallen in love with Python. I like the ease of Python a lot, but I think Java has a lot more power behind.

[atraub]

I chose to sit this one out, but I can't help but mention, it is interesting isn't it? Python claims that explicit is better than implicit, and yet you can't explicitly make things private (although well-accepted conventions do exist) nor can you explicitly enforce a type.

This post has been edited by atraub: 20 September 2012 - 09:58 PM

[baavgai]

There's actually an acronym floating around: EIBTI (Explicit Is Better Than Implicit). Granted, it doesn't really roll off the tongue.

I think lack of data hiding enforces the explicit is better concept. Once it's hidden, it's rather the opposite of an explicit data element.

The type itself is explicit. You can ask any box what it holds and it will tell you. Variables in python are just holders for something. The nature of that something doesn't matter.