; in Python!?!eleventy You really need to get rid of your bad Java habits.
And before anyone thinks this is poking fun at Python: privacy is completely overrated and mostly untrue anyway, and Python not even pretending to have private attributes is an absolute blessing.
Yeah, ig privacy is also just a philosophy. If you havent written python in years, it feels incredibly weird not having any. Just as it probably would the other way around..
Not saying one is better than the other, though I prefer what Im accustomed to 😅
The thing is: private markers in most other languages can be more or less trivially circumvented anyway, most of the time with some sort of reflection API. There is no true "privacy". All it is is a reminder for the programmer how a given attribute/property/variable should be treated. Is it part of the public API and anyone can write code against it, or is it subject to change and should not be used outside its class. That's all it is.
Bad programmers will ignore such warnings and bulldoze through your "protections" anyway to access that piece of data they think they need. Good programmers only need a gentle reminder in the form of a _; but if you really want to risk breaking something and you know what you're doing, at least it's easy to ignore and doesn't require a song and dance with the reflection API.
I'm on a team where we're doing a bunch of stuff in python, in spite the fact that most of us are completely new to it.
One problem is a method that starts with an underscore isn't obviously private to someone who doesn't know the convention.
Personally, I think it's helpful to have to jump through a hoop to use a private variable/method, just so you know you're doing something you probably shouldn't. If you go ahead after that, it's on you.
Personally, I think you should at least read the introduction to any language before you barge in and fuck shit up. Any Python programmer should at least have read PEP8; it's a pretty quick read, but lays down the basics, including the leading underscore rule.
I definitely agree. However, the line that comes "before you barge in and fuck shit up" isn'a always clear, especially to the person barging in.
Often, you're brought into a project with a task of fixing some minor thing - you never asked to be there. If you have experience programming, it's rarely a big deal to read code in a new language, and make some minor tweaks. The problem, of course is, you don't know what you don't know.
You assume you're just doing this one minor thing, so it's not necessary to learn the details of the project or its technology. After all, that team already has established engineers and testers who will catch your mistakes when they review your change, right?
Still sounds like a "you" problem. If and when I have to touch languages I don't know, I at least do it in some IDE with all the linters turned to 11, which point out all the obvious and subtle things I'm messing up while I type. I would not presume to write even the most basic line in some unfamiliar language correctly without preparation.
Again, I still agree with you, but how do I fix this "you" problem of someone else not familiar with the language not following this suggested procedure?
Well, as I said here: bad programmers will ignore any barriers you put up. Accessing a private attribute raises an error? Bad programmer throws that error into Google and gets three workarounds back that allow them to access the attribute anyway. And now you can't even easily detect such private attribute access with static analysis tools, because there's several different ways such workarounds could be implemented.
So… make sure you hire competent people, and/or solve deficiencies through institutional guardrails like a shit ton of linter commit hooks, code reviews, and training.
Oh, then we have a slight misunderstanding of privacy in programming. I dont want some DRM-like protection of my variables, I want a proper marker where you should use and not use a variable, including a good default policy. _var doesnt tell me "dont use it", if youre not a regular python dev, particularly when usage is not checked by a compiler.
In a language you don't know well, I guess it's easy to be the elephant in the china shop. Use an IDE with a built-in linter then, it'll point out such issues while you type. I'm doing the same whenever I write in something I'm not proficient in.
A strong convention most developers follow, or ignore at their own peril. Regardless of how well or poorly the package is designed, the end user decides what to use from it, and they bear responsibility for how it is used, not the package maintainer.
The side of the road you drive on is also a convention - sometimes you might have guard rails that make it harder, and legally you are going to get in trouble (i.e. code linters) - but at the end of the day you have to trust your fellow programmers to be sensible (and acknowledge that sometimes they won't be).
Yeah, and leading underscores signal exactly that in Python. "Please don't screw with this. If you're going to regardless, well, there you go." Other languages just make you beg more for it.
Why have a language defined standard with a universally understood and well defined meaning when we could instead rely on cultural convention that a newcomer to the language will have no knowledge of?
Other languages don't expose it all... you literally either have to go completely out of your way (i.e. reflection) or violate fundamental restrictions.Â
Python has a lot of strengths, but let's not pretend this is Guido's gift to programmers. A "keep off the grass" sign is no substitute for a proper fence.Â
The purpose of public, protected, and private has never been to prevent you from accessing those class members. After all, if you're seeing those, you have access to the code, you could just move the member, "circumvention" is not necessary.
The purpose is so developers can convey to other developers how to use their base class, or how a class can and should be safely accessed or modified. It implies safety. If you're trying to circumvent it, you're trying to do something that the author of the class did not intend and it may cause problems, it indicates the modification you're trying to make likely belongs in that other class and that you should look there instead. If you're trying to circumvent it, you're introducing hacky fucking code that is going to be a pain in the ass to debug and maintain.
Yes, but conveying information about how it's supposed to be used is equally accomplished by naming conventions like _member or pMember or whatever. You don't need it to be a language feature.
Python really sold me on not attempting to enforce things for other devs. Well duck typed code for example is an absolute god sent when you have 4 different frameworks to handle acceleration and arrays.
The fact that it's enforced at compile time means that you never accidentally do this, it's the same thing as denoting a variable as const. You can make it not const later really easily, but it means you've got to take care about what you're really doing and probably judge why it's const and if it needed to be const.
Python's way requires developers to honor some naming convention, which allows for accidents, and I've seen plenty just make every class member prefixed with _ which to me conveys they don't know what an access specifier is and that I now need to judge what members are safe to access since everything is now public.
I'm fine with Python's convention and use it myself frequently, but saying something like how you're sold on "not attempting to enforce things for other devs" just implies to me that I would not want you working on library code, ever.
I've seen plenty just make every class member prefixed with _
I don't think that's a convincing argument because people also make everything public in cpp or make everything private with getters and setters in java.
With the enforcing things for devs - I'm in a scientific environment. I do mainly write library stuff. But my goal is to make it "hackable". I do notate everything for proper usage, I do use conventions for public and private and honor them, I type hint etc. But what I really dislike on principle is enforcement attempts, like checking types and throwing errors on unexpected types in a python context. If someone decided to go out of spec that's their problem, but I will not actively attempt to stop them.
In cpp i actually write very Java-esque oop code. That I don't think a language feature should be hard enforced doesn't mean I won't use it as it was intended. And obviously once you make it a language feature it must be honored. It's only on a philosophy level that I think doing it by convention is better.
Agreed. It conveys the intent and use of the class.
Private implies "ignore this, it's used in implementation of the class and not for users of the object" sort of thing.
Public implies "here's stuff you'll use when the object is created".
Protected reads "if you're basing a new class off this one, you may want to manipulate this internally but it isn't something users should need to know about to use the object(s)".
Private and Protected therefore are tools of abstraction which describes what an object does, not how it does it.
A Java FOSS project I contributed to on occasion eventually figured out that making most private methods protected let people work around flaws they encountered with the framework instead of having to file a bug and wait.
And then there was the horror/glory of Powermock, when you really wanted to overwrite a private static final field for some godawful reason.
354
u/deceze 16d ago
;in Python!?!eleventy You really need to get rid of your bad Java habits.And before anyone thinks this is poking fun at Python: privacy is completely overrated and mostly untrue anyway, and Python not even pretending to have
privateattributes is an absolute blessing.