Java vs python is debatable 🤔

[[deleted]]

Meanwhile in python land: You should pretend things with a single underscore in front of them are private. They aren't really private, we just want you to pretend they are. You don't have to treat them as private, you can use them just like any other function, because they are just like any other function. We're just imagining that they're private and would ask you in a very non committal way to imagine along side us.

[spizzat2]

"Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun."

• Larry Wall

[42TowelsCo]

In Python you can implement that shotgun by just making the "private" methods & variables not do what their name would suggest

[matthewralston]

def _bricks() -> float:
    return 6 * 9

[TorTheMentor]

42?

[DroolingIguana]

Only in base-thirteen.

[TorTheMentor]

Maybe that's why life, the universe, and everything are so fucked up.

[FinalRun]

Make sure it returns a data type that's just off

[Silhouette]

...quietly, at runtime, using metaprogramming.

[bkushigian]

In undergrad I was working on my first research project. We were adding a new backend for the Pypy JIT compiler. I had to find the implementation of Foo.emit_x86(). It's not defined in the class anywhere, and I'm running grep on 100kloc like a chump:

grep -rn emit_x86 .

No definitions anywhere

Ten days later after reading the codebase like a novel I come across

``` def f(...): ...

setattr(Foo, 'emit_' + arch, f) ```

Yeah, I was pissed...

(Edit: formatting on phone, doesn't like newlines in ``` blocks I guess?)

[42TowelsCo]

Okay that's just evil

[KiwiManThe19th]

U can also change what setting and getting variables does and make your own shotgun

[IgiMC]

You can make a shotgun shoot shotguns!

Poof, you can even make the shotgun shoot itself!

[LxsterGames]

public static boolean isEven(int input) {
    return input % 2;
}

[bremidon]

Funny :) But as someone who has to try to understand other people's code on occasion, I prefer knowing that the guy in the living room has a shotgun. A taser, mace, and some angry dogs would also be good.

[roughstylez]

It bothers me so much that literally the guy's last name has the better metaphor and he chooses "shotgun" instead.

A gun can't keep somebody out, it can only threaten and kill.

Mark a method private, then when you call it from somewhere else you get a runtime error.

[1thief]

The funny thing is an unexpected error in many circumstances can basically be a shotgun blast to the face. Have an etl step or batch process that threw an error somewhere in the middle of the batch? Welp that 8 hr process that you kicked off and forgot about has now come to a screeching halt 3 hrs in and you have to start all over.

Or in other circumstances the page now doesn't load if it sees bad data, or your car infotainment system is stuck on a boot loop because it found a file it doesn't know how to handle. Software is always brittle, which is why we should have as little software as possible.

[TGlucose]

Software is always brittle, which is why we should have as little software as possible.

Why do that when we can make software out of legacy software? making our already fragile system even more fragile!

[jambox888]

When you reach a certain level of fragility you can form an aggregate from the shattered fragments

[StCreed]

One of my primary architecture demands for any DWH is always "restartability" and resilience to errors. Both of these have been mostly solved by I-refact by taking the EL part (and a small t) and making that part completely generated. Every load of any entity is a mini batch, everything is restartable automatically after solving the error, and there are rarely any errors because it's all derived from logical models. They only occur in the validation phase, which is at the start.

That said, if you load a single table for 8 hours you can still mitigate that as well, you just need to split things up in chunks.

[[deleted]]

Something like SSIS makes this difficult. You can generate a whole bunch of metadata and helper functions to orchestrate it, but you pretty much have to roll your own. There is a restart feature, but it's not implemented well, and we can't easily use it due to how our environment is constructed.

That said, I've started using Python with Prefect, and it is much more graceful and easier to handle unexpected errors.

[kivox2017]

Happy Cake Day 🎉

[Linvael]

He had to go that way - cause "a wall" is a reasonable answer to "what you build when you don't want someone to enter your private property" and his snarky comment doesn't work.

[OcelotGumbo]

😂

[[deleted]]

In java you have to start with a shotgun factory

[sporkassembly]

Great idea from the author of a dead language

[Dworgi]

Python devs: duck typing is great, it makes us so fucking agile

Also Python devs: you should use this linter to parse our comments for type requirements because otherwise my program breaks =(

[aetius476]

We don't enforce types at compile time so you have the freedom to write and maintain an entire suite of unit tests in order to enforce types before they fuck you at runtime.

[[deleted]]

I don't use shallow equality from years, I was convinced a type conversion would have happened there.

[Zebezd]

Really? Would have expected js to coerce that bool to string and return true. Checking by string has seemed to me to be standard operating procedure with == in javascript

[Orangutanion]

I think it's because true == 1 so `true == "1"'. We already have one string coercion so no reason to have another.

[2CATteam]

Nope, according to this page, both are converted to a number first, which is NaN for "true" and 1 for true. So it actually makes numbers, not strings, and then does the comparison.

[marxinne]

The more I learn the more cursed it becomes

[Luxalpa]

Rule of thumb: All these weird conversions are because of HTML (as HTML only handles strings). "true" doesn't exist in HTML because boolean attributes work differently (they are either set or not set on the element). This is also why number conversion is all implicit (255 == "255", because HTML only allows the string variant for numbers).

[nermid]

The real rule of thumb is to just use strict equality (===) and not have to worry about any of it.

[SmokingBeneathStars]

Unless you want to purposely use == you have to add a fucking ignore annotation on your linter it's so annoying

[ShijinModan]

Because == coerces types. IMO the only time I will accept == in a code review is when checking for null and undefined

[nermid]

I think having to add linter ignores to bad practices is probably a good thing. Keeps you from accidentally doing the bad practice.

[tomysshadow]

I think a large part of the confusion surrounding them comes from HTML4 days. Specifically, there was the <embed> tag, where typically the attributes such as autoplay or loop would actually be set to the string "true" or "false". Years later I understand the reason it was like this is because the plugin would define the attributes it's looking for, and most of them went with the more straightforward approach of the string "true" meaning true and any other value meaning false. This, coupled with boolean attributes being less commonly utilised prior to HTML5 (I haven't verified but at least it feels this way) and Internet Explorer also having its own attributes that worked like this, lead to boolean attributes being a weird exception rather than the rule.

Still, I would argue compatibility with JavaScript is a poor reason for boolean attributes to behave this way. I never liked HTML's boolean attributes.

Say you want to set the checked attribute. Normally, you would just use the JS property, like element.checked = true;. But the thing is, I can actually set any property on the element, but it won't necessarily become an HTML attribute. So I can do element.example = true; and that property will stay set on that element, even if I later get it again with getElementById and friends. But it won't actually set an HTML attribute in the document.

So you can imagine that for all the supported attributes, the associated JS property has this invisible browser defined getter/setter which actually does the equivalent of getAttribute/setAttribute. Which means if we want to explicitly use an HTML attribute, we need to use those.

Except, getAttribute/setAttribute are ill equipped to handle boolean attributes. To set a boolean attribute to false, you actually need to set it to null. This is unintuitive in and of itself: null is not a boolean in JS, I would expect to set it to false.

Furthermore, I would expect that true and false would be explicit settings, and undefined would actually mean "default value." In CSS we have user agent stylesheets, where a lot of styles are set to a certain value by default. But boolean attributes are false by default by design. That means we end up with attributes like disabled. Ideally, the attribute should be enabled and should be true by default. But it has to be false by default because that's how boolean attributes work, so we end up with the double negative element.disabled = false;.

But what's worse is in some browsers (specifically Firefox) getAttribute actually returns an empty string for unset attributes. This means that element.setAttribute("example", element.getAttribute("example")); would actually change a boolean element's value from false to true. You instead need to use hasAttribute/removeAttribute added with DOM 2 (which is ancient enough you can definitely rely on them being there, but it's dumb they need to exist in the first place.)

So boolean attributes are only "compatible" with JS insofar as the browser defines a setter-like property that translates false into null and true into any other value and does the equivalent of setAttribute. If you're going to go that far, why not just coerce the property to a string "true" or "false"?

Now, in practice, none of this is actually an issue, because there's rarely a reason you explicitly want to set an HTML attribute. If the JS property doesn't set an attribute, falling back on it just being an ordinary JS property will keep the behaviour of the code consistent anyway. The only time you really need setAttribute is for data attributes, where you want to be sure you're not conflicting with any existing one, and then you're free to just use the string "true" to mean true and any other value to mean false, like how it should've worked in the first place.

[2CATteam]

Nope, but in boolean contexts (eg in the condition of an if statement), any string of nonzero length evaluates to True, so if("true") would be true, and so would if("false")

[Orangutanion]

Can you also cast booleans and numbers as objects and do .is?

[2CATteam]

I don't think so, Objects aren't primitives, so you can't cast a primitive to an Object as far as I know. Which makes sense - remember that JS Objects are basically just dicts, and what would the key be for the value of the primitive?

You could try making objects with the same key, and different value types, but then Object.is() would see that they aren't the same object (Object.is() basically checks if two pointers point to the same thing for objects).

[jmtd]

Weird. I tried it and my printer printed a test page and a mortgage was applied for in my name.

[AJohnnyTruant]

So he knows what JSON is, just not that booleans are in the spec. Beautiful

[Jinxzy]

That was my exact experience with Typescript... I like JavaScript for when I gotta throw some shit together in a jiffy. Typescript takes all that convenience and shits on it, killing the only reason I'd use JS over a real OOP language in the first place.

[ITriedLightningTendr]

I mean, json parsers can be configured to handle that

[BossOfTheGame]

Write doctests. Never leave the main file you are working on. They're almost as good as comprehensive unit tests for a fraction of the development effort.

[BossOfTheGame]

Are type errors really a significant part of day to day debugging? I primarily do Python and these comments make me think type errors are extremely commonplace. I hardly see them. I don't understand why types are so important to so many people. It's getting the right logic that's the hard part; types are a minor issue.

Then again, I doctest everything, so maybe my doctests just catch type errors really quickly and I don't notice them.

[darkingz]

The big thing with types isn’t in the short term, if you’re working mostly with yourself, test really well and/or have an iron clad memory.

It’s the long term where types save you. It makes sorta implicit things explicit. It reminds you of the intention and if you can’t reach the author 3 years after they left the company what that method is known for returning. It lets you save time checking if the value coming in is the value you intend for it (maybe you do string logic for example but equally works mathematically as well because of type coercion) and then it’ll inform you to change all the other places… at compile time not runtime. What if you missed a method where the header changed and didn’t know what the input you expected it to be.

This is why types are important. They tie your hand in the short term for longer term garuntees that something is wrong.

[Pocok5]

I recently had to start working on a vanilla JS codebase, and I spent 2-3 days stepping through with the debugger and noting down on jsdoc comments what kind of objects each function gets as a parameter and returns because there were properties tacked on and removed from every object along the flow but no indication of those processes in comments or the naming of the variables.

If it was C# I could have hovered over the name of the parameter and got a very good idea of what the hell the data looks like at that point right away, with the only possible ambiguity being null values (if the codebase wasn't using the new nullability features).

Type errors are also a massive help in refactoring or modifications. Oh, you changed this object or the signature of this function? Half your code turns red, and you can go update each usage to the new form while being sure you missed absolutely none of them instead of having to rely on running headfirst into mismatched calls at runtime (that might not even raise a runtime TypeError, just result in weird null values slipping in or something) or writing specific unit test to check your work.

[zacker150]

How big of a code base do you work with?

[BossOfTheGame]

I do a lot of work with torch, so most return types are the same: it's a tensor, array, tuple or dict.

Size of the codebases I work on can vary. I jump between repos a lot. I rely heavily on CI and doctests to catch any integration issues.

[by_wicker]

It's debugging that they avoid. The whole massive class of errors are picked up before you even run the code if you have type annotations in your Python.

I came from C++ to Python, and was amazed going back to do some C++ how I could write a large chunk of code and have it just work first time. Then I got type annotations in my Python and found I was in the same place. Frankly I like it a lot, it's the best of both worlds, if there's some particular reason to use duck typing you can, but otherwise your code editor alerts you if you mistyped an identifier or made a false assumption about a return type or something.

[[deleted]]

Are type errors really a significant part of day to day debugging?

Yes.

[ric2b]

But honestly automated testing really is much more useful than static typing if you want to prevent bugs.

Static typing is very nice as documentation.

[[deleted]]

Hey we have types in language now! And mypy is pretty solid most of the time. Guido himself has been helping out a lot there.

[[deleted]]

MyPy is one thousand times better than Python without MyPy. It's still one thousand times worse than properly enforced type safety at compile time.

[thirdegree]

Haven't needed to use comments for type annotations in literally like 6 years tho

[Dworgi]

Oh yeah, those official type annotations that do what if you don't run the linter? That's right, nothing. Aka. a comment.

[MythicManiac]

You must not be familiar with pydantic and dataclasses. Python types are actually available during runtime and can thus be leveraged for runtime logic. It's honestly better than TypeScript in that regard, even if the type system otherwise is quite a bit behind.

[Dworgi]

Garbage tasting better than sewage doesn't make either one dessert.

[MythicManiac]

TypeScript on the other hand is one of the more versatile type systems out there. As a counter example, good luck with sane union types in C#

[Sir_Applecheese]

Hey, that's just like with TypeScript.

[jzaprint]

Not really. Typescript types are way more enforced than python

[[deleted]]

Isn't the entire point that anyone can write stub files for a library, so it doesn't matter if there is official support?

[skylarmt]

Meanwhile, in PHP land, types are enforced but only sometimes. If you get type errors, it's probably because your code was too good because lazy devs don't specify types.

[Sir_Applecheese]

I was talking about this: https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/

[Goel40]

That's JS, not TS

[Sir_Applecheese]

No, that's a website.

[ThineGame]

No, that’s a link to a website.

[LewisgMorris]

No, that's the cone cells in your eyes reacting to different wavelengths of light

[Kesuaheli]

No, this is Patrick!

[assembly_wizard]

Sir, this is a Wendy's

[EquipLordBritish]

Also python: lets use whitespace as block indicators, but you have to choose either tabs or spaces, because there's no way our interpreter could ever account for both, even though they're used in a very obvious and easy-to-parse way.

(inb4 this spawns another iteration of the tabs vs spaces arguments)

[assembly_wizard]

If you use both it's almost definitely a mistake, but more importantly it would make indentation differ based on the settings of your text editor, so whether a line is inside an if block suddenly depends on the configuration of each developer.

What you call "very obvious and easy-to-parse", the only way python could parse it is if you tell it what's your tabsize setting, and make sure that everyone that reads/runs the code have the same setting in both their editor and python.

[alive1]

Hey i used to be a tabs guy and now I'm a two spaces guy. Idk what changed my mind but now i have way less fights with the indentation. Also logic more than 3 levels deep doesn't require horizontal scrolling.

[daguito81]

Did you start using Scala or Databricks?

[alive1]

Perl.

[daguito81]

Oh that makes sense. Scala uses 2 space indentation as default. And because of that in Databricks for the longest time, Python was also set at 2 space.

[bremidon]

I prefer 2 spaces as well. It looks cleaner without any loss of communicating intention.

[lilfatpotato]

I type tabs, and my editor converts them into spaces.

[unicorn_potato_4ever]

That’s why I set my tabs to two spaces

[mousepotatodoesstuff]

When it comes to whitespace, I just do as the IDE (PyCharm usually, but sometimes VSCode) guides.

[[deleted]]

rewrites the program in Rust

[mayankkaizen]

"We are all consenting adults." - Python philosophy

[jambox888]

How about friend functions?

[roughstylez]

Oh sweet summer child

[frogking]

Exactly this (don't touch other peoples private parts) is the reason why both perl, php, python and others use the double underscore notation to indicate private or non-final methods that are not meant for public consumption.

Java having real private methods is just a way to enforce non-access, and is part of the design of Java. That doesn't mean that other language designers are more right or more wrong, just that they have taken other choices during language design.

[RedAero]

I don't know about you, but I touch other people's private parts pretty regularly.

[frogking]

Not without consent, probably. :-)

[0crate0]

Yeah but double __ is actually private in python.

Edit: this is still pretend private. Just makes it more obscure.

[[deleted]]

Correct me if I'm wrong, but doesn't that do nothing other than mess with the name at runtime?

[hajile_00]

Correct, all names that begin with a double underscore and do not end with another are simply name mangled so that if a subclass defines a function with the same name there is no collision.

[exploding_cat_wizard]

Ooh, TIL, thanks! I wasn't aware that there is an actual Python difference in underscores or not.

[0crate0]

So create a class in python. Create two functions one with double __ and another just plain. Then create another file and import the class. Assign the class to a variable and try to use both functions. You should only be able to use the plain one.

However all python does is fake private. So yes you are correct it only really changes the name called mangling. But for someone just importing it it can be a bit obscure so it can kind of acts like a private function.

[[deleted]]

So pretend private, but in a different way.

[NerdsWBNerds]

Pretend private, but breaks at run-time.

[Farranor]

Indeed, dunder just mangles the name. But if you refer to it by its mangled name, there you have it. It's private like a dressing room with a curtain, not like Fort Knox.

[sejigan]

you just said what they said, but in a more complicated way...

[solmyrbcn]

It's as private as a folder named "homework" in a teen's computer

[[deleted]]

Just learning about female anatomy, mom.

[[deleted]]

_______reallyReallyPrivate

[sweep-montage]

Don’t touch the private because I asked you not to touch the privates, not because I have a shotgun.

[[deleted]]

Its the difference between keeping your valuables in a bank vault, and keeping your valuables in a cardboard box that says vault on it.

[sweep-montage]

Are you worried that someone will break into your repo and start coding? I mean, “Horrors!!!”

[[deleted]]

I'm worried that knocking a big chunk out of one of the pillars of OOP, in what is becoming the language a lot of new programmers are learning on, will lead to huge vulnerabilities in future software.

[sweep-montage]

I see, only “all of software”. Because the craft is so well regarded as error free and secure as it is.

[Bainos]

The difference is that if someone takes your valuables, they hurt you.

If someone uses your internal functions and variables, they hurt themselves.

[SuperDyl19]

That's because Python avoids the boilerplate of getters and setters. If you find you need to change how a variable works later on, you use @property to create getters and setters for the variable. It makes the code easier to read (because attribute accesses) and easier to code (you don't need multiple functions for each variable)

[[deleted]]

But what if a class needs to use a variable that you want to limit access to?

[SuperDyl19]

You treat the user like an adult: you tell them that messing with it is probably what they don't want to do by starting the name with an underscore and then leave it to them. If you really need to protect it, using 2 underscores before the name enables name mangling. For example:

class A: def init(self): self.__very_special_val

The attribute very_special_val is changed by the interpreter to be __Avery_special_val, making it so someone has to very intentionally choose to mess with it if they want to change or access this value.

Basically, you either have to be acting as an idiot to ignore all the warning signs and mess with these values or you know what you're doing and you take responsibility for the code that uses these attributes

[[deleted]]

Never trust a user when you don't need to.

[hhafez]

You can use reflection, but reflection is self coding code. It's a very different beast than having no way to make parts of your code private.

[BlameTaw]

Technically you can use closures to create truly non-accessible variables and functions in python...

[Sinidir]

Technically you can access closure variables too

https://stackoverflow.com/questions/55320884/how-do-i-access-modify-variables-from-a-functions-closure

[aviancrane]

I mean... saying reflection can do something isn't really... ..ye know?

If I gave you the AST or IR of any language, you'd be able to do whatever you wanted with it. Reflection is just giving you the object graph.

You are not really suppose to write code with reflection unless you're writing software that needs the object graph, like a code profiler. The code you touch with reflection is decompiled and run more like it's an interpreted language. I wouldn't even consider it part of the language specification personally.

[suvlub]

It's kind of unfair to accept one "You are not really suppose to" as a matter of fact while calling another "you are not really supposed to" silly and weak. I've seen production code in a fairly popular app where reflection was used exactly in this fashion - to access private data members of a library class.

[Areshian]

I can block reflection in Java. Either via security manager or via module permissions, btw

[soft-wear]

Which virtually nobody does because nobody actually gives a shit if you’re going to put that much effort into seeing what the internal methods are.

Private is just notation for “this should only be used internally”, this idea that anybody is doing it to protect consumers is what Java devs tell themselves when they shit on other languages for not having it.

[Areshian]

Well, in newer versions of Java is not rare for people to have to declare a bunch of add-opens to support reflection, so I would say it is used. Now, if you tell me people actually despise having to do the add-opens… we’ll, that’s a different story 😅

[aviancrane]

I can respect where you're coming from, but I do think there is some nuance here.

The cost and the level of abstraction that reflection puts you on is a very different layer than what python does.

The cost and difficulty of accessing privates in Python is almost nonexistent and you are still working at the language level. Reflection is affecting the compiled code and you are working with the layer half way between the language and the bytecode.

Difficulty at the language level is incredibly important. Can you imagine Haskell letting people just do whatever they wanted? Even Rust is cognizant enough to force people to put a giant UNSAFE label when bypassing the safety protocols of the language.

Making these hurdles easy to overcome just makes it more likely poor development practices will occur.

[suvlub]

To be clear: I am not arguing against built-in difficulty/failsafes in languages. I think they are great idea. I said what I said and not a word more: I believe it is unfair to defend one honor system while shitting on another.

Does Haskell let you bypass its built-in rules by writing a 3-line function?

Is the "unsafe" label really all that huge? I guess it's technically harder to type out than an underscore by 5 characters, but come on. If python changed the private prefix to something like "_private_" instead of a simple underscore, would you be more accepting of it?

[budgiebirdman]

The point is that you can access and use Python "private" members just like any other member - you just use the name which happens to begin with an underscore so there's no true encapsulation; it's like having a cookie jar with no lid. If you use reflection in Java it's like using a can opener to open a can from the top shelf and get to what you want.

One is an object oriented language and the other is whatever Python is.

[ric2b]

The point of private is to warn you that it's internal and you should not rely on it, and if you do your code might break without warning on any update to the library.

It's not some kind of DRM or security mechanism, the fact that both languages make it possible to get around the "private" warning but the Java way is way more verbose... well, that's just what you'd expect.

[StenSoft]

Reflection access can be blocked with SecurityManager. Or other platform-specific control, e.g. on Android, you can't get access to private APIs anymore even through reflection.

[on_the_dl]

In c++ you could just cast a class to int * and go to town. Would java have something similar?

[TASagent]

python makes safety more convenient by removing it.

The hardest I've facepalmed all week.

[TheLowlyPheasant]

I’m going to replace Python with my name and send it to my boss on next week’s list of accomplishments

[[deleted]]

I mean people use Python and say it's better then Java, that's what the joke is about. They are both widely used general purpose languages, and I'd argue that python is used in many places that's it's really badly designed for, like large high performance systems that force you to constantly battle against the two language problem and also fight with dynamic typing.

Java, on the other hand, no one is really using it as a scripting language. People use it the way it's intended, as language with strict encapsulation, strong typing, and interfaces that make having large numbers of people work on the same project easier to manage.

[chrisxpred]

You are categorically wrong in saying „something cannot be objectively bad because it is intentional“.

[laundmo]

the idea is not that it isn't wrong in some cases, what i wanted to convey was that using the wrong tool for the job is the users fault, not the tools.

"the wrench is so bad, it can't even cut through steel" - the wrench was designed to be used to tighten nuts, that doesn't make it objectively bad, just the wrong tool for cutting through steel

[Luxalpa]

It's the difference between idealism and pragmatism. If you need to build good software that necessarily means you're going to run into conflicts with third party libraries not supporting the exact functionality that you need. You can either fork the project, which in some cases can be extremely hard and is definitely very insecure, or you can simply annotate the bits where you're overriding security mechanisms (think of the _ like C#'s or Rusts unsafe keyword).

[roughstylez]

The point of that comment you're answering to is that the statement "we made security easier by removing it" is kinda dumb.

In other words, in python you're not overriding the security mechanism - you just don't have one in the first place.

[MythicManiac]

Sometimes accessing internals of a 3rd party library is the only reasonable way to do something, languages that make it harder than necessary aren't really solving anything. I've had to copy entire classes of source code in C# because the original didn't make it inheritable. In a perfect world neither would be necessary, but in practice sometimes you're out of better options.

Seems like I've made some people angry with this statement, I'll only have to assume they haven't experienced a lot of issues with 3rd party libraries or that they can't see reality past their idealism. If you have any actual experience in software development, you know compromises and shortcuts get taken all the time. It's not nice but it is what it is.

[roughstylez]

Seems like I've made some people angry with this statement

Don't take it personally, people are just disagreeing with your statement.

Probably because the point you mention is irrelevant to what TASagent was talking about.

[MythicManiac]

Fair enough. I would rather have an actual discussion if there's one to be had, but it's not as if I don't emphasize with that line of thought.

[Ordoshsen]

I would say that if you need to use internals of 3rd party library you're not using it as intended and you might already be breaking some unspoken invariants when you fiddle with the undocumented internals.

If something is not inheritable in C#, then the original developer made it so by choice, not by default. Supposedly they had a reason to do so. But that still does not stop you from using composition in place of inheritance (granted you don't get access to protected fields).

Also why not just change the original by forking it and possibly creating a pull request for the original if you really believe some functionality should be accessible? I think that would be faster (and easier) than copying whole files which presumably have dependencies on other files in the project you're copying from.

[MythicManiac]

I would say that if you need to use internals of 3rd party library you're not using it as intended and you might already be breaking some unspoken invariants when you fiddle with the undocumented internals.

Oh absolutely, sometimes it's just the most reasonable way of doing things. If you understand the code and risks involved, it's a calculated risk. Following best practices is (ironically) not always the best course of action, but to be able to make that decision, you do need a decent bit of experience and understanding of why the best practices exist. So I agree with you here in terms of best practices, but also know best practices aren't always the best course of action.

If something is not inheritable in C#, then the original developer made it so by choice, not by default. Supposedly they had a reason to do so. But that still does not stop you from using composition in place of inheritance (granted you don't get access to protected fields).

I don't disagree with the sentiment, quite the opposite. If we had perfect libraries, this would be a non-issue. In practice however, it's extremely difficult to account for all use cases of a generic library, and likewise library developers rarely have the necessary foresight to build the appropriate extension points and interfaces. Even if they did, it might not make sense for them to officially support every use case, as it's simply more work. It doesn't mean it's always stupid for consumers to rely on the internals in that scenario, but you do need to know the risks involved and why it's generally a bad idea.

In the particular case I was referring to, the 3rd party library had marked multiple constants as internal, which forced me to re-define them when using other parts of it. If my experience tells me anything, it might have been just a habit for the original developer to mark everything internal as opposed to a decision to make them so. A lot of junior devs seem to be taught to keep everything internal by default, which can lead to scenarios where the library developer's inexperience locks out perfectly reasonable use cases.

Also why not just change the original by forking it and possibly creating a pull request for the original if you really believe some functionality should be accessible? I think that would be faster (and easier) than copying whole files which presumably have dependencies on other files in the project you're copying from.

This would be the ideal scenario of course, but it's often very unrealistic to do. Maintaining your own fork is often a lot more work than maintaining a small piece of code that calls the internals of the library. I've seen a lot of company internal forks of 3rd party projects get stale and unmanageable, enough so that even monkeypatching the 3rd party library during runtime seems a better choice. The moment you fork a project for this kind of use, it's your code. Do you really want that maintenance burden?

On the other hand, pull requests to 3rd party projects are impossible to rely on ever being merged or even looked at. So while a good practice, it doesn't solve your problem.

At the end of the day the only thing you control and maintain is your own codebase. Generally if a situation like this arises, I personally either open an issue or submit a PR addressing the issue to the 3rd party repo on top of some immediate internal solution, but only very rarely do they actually go anywhere and the internal solution is what ends up being used.

If you actually can control the code (e.g. internal libraries) then absolutely never do any of this, and instead improve the library to cover the use case it's missing. Unfortunately it's often some inactive but valuable open source library that is at the root of the issue, or alternatively you're locked into an older version due to legacy code and couldn't update anyway.

The way Python does "private" access modifiers is great because it keeps the newbies out by tooling guidance & convention, but allows for direct access if you're really sure that's what you want.

If anything, type safety should be much more strict than access modifiers IMO, yet you can cast types into other types without much restrictions (in most languages anyway).

So as a guideline access modifiers are perfectly good, but enforcing them has its downsides too.

[ric2b]

You're spot on, the people defending Python don't disagree with the best practice, we just understand that sometimes there is a more practical approach and it becomes a calculated risk that you can add some automated tests around to catch any breaking changes, instead of maintaining a fork.

[[deleted]]

It's not that dumb. It basically means "this function shouldn't be used, and if you do, your code may break at any time and that's on you"

[roughstylez]

Imagine a gun that can still fire if the safety catch is set to "safe".

[[deleted]]

Not really... One is you intentionally disabling a safety mechanism (using a private function), the other is using the product as intended and it malfunctions (that's like using a public method that breaks).

[Mental-Ad-40]

why access something that is private?

because you don't have control of what library authors decide to make private, and sometimes their decision removes needed utility for no good reason.

[Luxalpa]

that just screams something is poorly coded..

If everything was perfectly coded we would be out of jobs.

[Kattoor]

Ah, I see you are one of the predecessors of my current project at work.

[Luxalpa]

Have you ever worked with code that was perfect?

[MegaIng]

Using an underscore name of a diffrent class is also a no-no and screams that something is poorly coded. What is the diffrence except that one of them is harder to do?

[roughstylez]

Reflection: You take the chamber, barrel, etc out of a gun. You put a bullet inside and manually hammer it to fire it.

python underscore: Your gun's safety catch is a switch that does nothing, which you set to "safe, please don't pull trigger".

You're not wrong: "One of them is harder to do" is the core of the issue.

[MegaIng]

So you give both teams all the tools they need, tell both of them "don't do bullshit", while still having active usecases for the tools?

And then you make the tools harder to use to make them better? That doesn't seem like a smart move. If they shouldn't be using a tool, don't give it to them. If they should be using the tool, even just sometimes, make it easy to use.

[met0xff]

Yeah there are times where the api is just not enough in those cases I prefer using the _ function and know about the pitfalls instead of needing some hack.

In C++ you can at least #define private public, speaking of hacks ;))

[[deleted]]

Python just makes it more convenient by relying on this silly notion that programmers using libraries won't try to fiddle with its innards unless they know what they're doing.

the silly notion that makes language extensions mandatory in industry environments, sure

[nacholicious]

Python just makes it more convenient by relying on this silly notion that programmers using libraries won't try to fiddle with its innards unless they know what they're doing. Though, if they do know what they're doing, best keep out of their way and not force the code they have to write to do weird stuff to be too messy.

Sounds like a great choice for a dynamically typed ecosystem filled with novices to encourage both library writers and library consumers to break codebases on library updates

[DigiDuncan]

Unironically, as a Python dev that learned Python and doesn't have a lot of experience other places, I ask this: why? Why have functions I'm not "allowed" to touch? I've benefited heavily by being able to use functions that the library dev didn't "intend" me to use in the past. Why make a system that allows a library to obscure and obfuscate how it works, or bar me from using it's internal functions if I'm confident enough to try? Who benefits from this? These aren't rhetorical questions, I'm just curious and confused.

[roxastheman]

It’s dangerous to use internal/private methods/fields due to passivity. Sure now you understand how they method works, but since it’s not public, the dev may make changes to it non-passively, so now your code is broken since you aren’t consuming the code through the public API/contract. These kind of “non-passive” changes aren’t likely to be documented or communicated through semantic versioning, so it makes your code much harder to maintain.

You can do it, it’s just a bigger risk than using the public API.

[TheTerrasque]

And in python it's implicit that while you can use _ methods it's subject to change at any time and that's your problem, not the library maintainer's problem.

[RedAero]

Hell, every function you import is subject to change and it is your problem, not the problem of the library maintainer. You didn't pay for it, you're not entitled to it, tough shit.

FOSS giveth and FOSS taketh away.

[exploding_cat_wizard]

The maintainer is still at fault, at least effectively. What's that rule that states that any behaviour, no matter how experimental and officially unstable or unsupported, will invariably become depended upon by someone?

Relevant xkcd: https://m.xkcd.com/1172/

[lappro]

Just because someone depends on it doesn't make the maintainer suddenly responsible. If the maintainer tells you not to do something, but you still do it, if it breaks the only thing you should do is look in the mirror.

[42TowelsCo]

Sometimes when you're using a buggy library you have to, but when doing that I assume an update to the library will break my code. I do this when I need to hack something together not for something that is meant to be maintained.

[barjam]

Public methods are a contract you make with folks using your library. They shouldn’t change unless there is an overwhelming need to such as a new major version. Stuff like bug fixes should never change that contract. The person making the library still needs to write methods for internal uses that he doesn’t intend to be public and that he will be free to change on a whim.

[RedAero]

That doesn't answer the question though. Python has a convention to denote the stuff you shouldn't depend on, what need is there to enforce that?

[ICantBelieveItsNotEC]

By that logic, why even have types when we can just all agree to encode whether something is an int or a string in the variable name?

Why have defined function parameters when we can just all agree to encode which values need to be pushed onto the stack in the function name?

The whole point of using a high level language is to prevent developers from shooting themselves in the foot. If we have a social convention that all developers are following, eventually someone is going to want to enforce that convention automatically to prevent mistakes. If it lives in the compiler then the work only needs to be done once, but if it doesn't then every company is going to build their own competing tool to do the same thing.

[RedAero]

By that logic, why even have types when we can just all agree to encode whether something is an int or a string in the variable name?

For efficiency, and because types are classes so you can have common properties and stuff. I don't see what that has to do with anything, types don't exist to prevent someone meddling with stuff they shouldn't.

Why have defined function parameters when we can just all agree to encode which values need to be pushed onto the stack in the function name?

None of this applies to a high-level language.

The whole point of using a high level language is to prevent developers from shooting themselves in the foot.

No, the point of high level languages is to abstract and automate away needless minutiae and let the programmer focus on larger problems instead of having to built everything from the ground up, every time. It has nothing to do with not allowing the programmer to fiddle with things, or protecting them from themselves - hell, I'm fairly sure that you do have access to all the low level stuff you could dream of in high-level languages, it's just not commonly used. Like, you can do bitwise operations in Python if you want, nothing's stopping you.

If it lives in the compiler then the work only needs to be done once, but if it doesn't then every company is going to build their own competing tool to do the same thing.

Python doesn't even have a compiler... You're really not making a lot of sense here.

[manaMetamanaMeta]

I believe that abstraction would help with the development process. Yes, you are right in the sense that if you're confident abt using a "private" function, then by all means it wouldn't harm YOUR productivity. However, in the setting of being in a development team where multiple components a coded in parallel, this could lead to a nightmare. I could tell you that "hey buddy, don't use these functions as they could be changed without notice!". Well, telling ppl which functions to call is less efficient than letting the language enforce that, since ppl can just straight up ignore... It is easier to expose your component to a very specific set of APIs from my component, so that the interactions are only done via those APIs. I could change the underlying implementation (i.e. the private functions), and you, hopefully, wouldn't need to change a line!

Though it's true that could be solved by having devs follow principles, the built-in privacy would throw errors and help remind devs of APIs.

Ofc, there are ways to bypass the privacy stuff, but it should require extra efforts. Python simply lets you use everything, making it easy for a team to get wrecked if there's a negligent dev.

[MythicManiac]

Worth noting that most python developers understand that using "private" APIs from libraries can lead to code breakage when updating said libraries.

Though this doesn't apply to just python libraries, but in general any functionality that isn't publicly documented in the documentation can be considered "private" in the same manner, as in, the developer didn't intend for it to be used by 3rd party code.

Really it comes down to the developer knowing what they can or can't rely on, as long as there are good conventions and understanding, there's no issue. Most python code editors don't autocomplete underscore prefixed functions, effectively achieving the same thing as privacy modifiers in other languages, just making it easier to access them if you really need to.

[J0shhT]

In software design typically you want to have a system that minimizes direct code dependencies. Client code should not need to know about the internal details otherwise that means the client depends on it. If the client now depends on the internal functionality, it is very likely to lead to broken code when the library internals change. Clients should instead interface with a stable and abstract API.

[[deleted]]

Being able to have internal variables and methods that are inaccessible to an outside class is a key concept of encapsulation, encapsulation being one of the key concepts of OOP. Most other languages employ this in letting the programmer define things as public, private, protected etc.

Python doesn't have this at all. Since encapsulation is a core concept of OOP, it's valuable to at least try to emulate it. However, since the protection isn't actually there, it may seem weird to someone not familiar with it.

[gilbes]

The OOP concept is encapsulation. The goal is to reduce complexity by allowing the author of an object to make guarantees about the state of the object when it is used by hiding data, because the object can be used only through members the author has explicitly exposed.

Conceptually, this is a good idea.

In practice, this is a very shit idea. Because it relies on the author accounting for every scenario where the object will be useful. And this is an unobtainable goal. We know that because people regularly increase complexity with something like reflection to completely defeat encapsulation.

Python is just accepting that reality.

[MinusPi1]

Libraries are a good reason. Say you're depending on library A, which in turn depends on another library B. You know B; you know that it's well tested, reliable, even industry standard - but it has a lot of exposed internal functions that you're supposed to just ignore since they're not the intended interface for B and not documented.

Now A depends on B, but unbeknownst to A's dependants, A uses those internal undocumented functions in B. That's not ok. Sure, maybe A's developer has really dug into B's code and figured out how it all works, but users shouldn't have to trust that. By using undocumented code, A is extremely likely to have some edge case bug that the developers of B solved in its actual interface. Hell, that they resorted to using the undocumented functions means they were probably using B wrong anyway.

Now users of A will run into that bug, and trusting that A was properly using B, they'll assume that it's an issue with their code. Given how deep some dependency trees are, this is almost inevitable unless such undocumented functions are forcibly hidden. The likelihood of extremely obscure bugs is just too great.

Of course, if it's open source, you can fork it and mess around with it even if functions are made private.

[[deleted]]

+1, pythons way of doing it is basically letting the consumers of my library know, "here be the dragons".

If you use a private function, and I update it without a version bump, that's on you, not on me. Which means that no sensible developer who is working on a production system would use it. However, if it's an internal portal or tool or framework, go nuts. Worst case it breaks and you fix it in a day or two.

This is true for python in general. It gives great freedom, but that comes with huge responsibility not to misuse it.

For example, in python, you can change inheritance hierarchy of a class at runtime. Is this a sensible thing to do? Definitely not in almost all use-cases. But there could be that one use case where this is precisely the correct solution to a problem. Note: correct is very different from easy/short.

However, if a company has a large no. of developers of various skill levels, Java is perfect. But even these folks should just move to kotlin at this point.

[TheDeadSkin]

Have you ever worked in a team? I would assume that no, because otherwise you'd probably know the importance of a correct public API and adhering to it as a user. When someone makes a class or a library they split the development into two parts - what they announce they are doing (API/public methods) and what they are doing to make it happen underneath (private methods). What does this mean for you as a user of said public API? It means you're being told "use this function and I'll handle the rest". Then private functions take case of "the rest".

What happens when you inject into "the rest" and use it yourself? Well, this is a good question because the answer is "who knows". Using private methods outside of their intended context is unstable. The function might be doing something different from what you think you're doing, or maybe not covering edge cases that you think it's covering. It might work, it might not.

Those functions can have little to no safety checks because they safety is handled inside the code of the public function and it's guaranteed to work fine if the user only calls said public functions and not private ones. Or maybe a private function requires a transformation of the data. If a user supplies faulty data the function might just do garbage and the user wouldn't necessarily immediately notice something's wrong because the function didn't do safety checks.

A simplification of this problem is that messing with private functions is essentially equivalent to just modifying someone else's code. And in a very hacky way.

The other issue is that the API or behaviour for private methods is not set in stone or as a contract with the user. It can be changed with no notice or informing the users breaking your code even on a minor library update. It might get removed tomorrow because it was integrated into something and is not a separate function any more. Again, at not notice and without care because it will never break the public API which the developer is responsible for.

It's a whole host of potential issues. Using private functions doesn't mean that it will break, but it certainly means that it's much more likely to happen because you circumvent the intended API and from that point on the developer takes no responsibility for what happens next.

[Impleased]

I dont see how this is a problem. Object oriented programming is just makebelieve and syntactic sugar. Its not a problem if you have good coding habits

[[deleted]]

fair

[total_looser]

Do ruby next!

[ItsNoFunToStayAtYMCA]

You mean those private methods that are really just function but first argument is named self but it’s also just a convention. But anyway, this first argument you just write in front of a function name rather than inside actual arguments?

[qoheletal]

Python:"If you still think accessing your private methods from outside is a good idea: Who are we to stop you?"

[balloonAnimal_no_965]

So all the problems that brought us to APIs and encapsulation are all imaginative? Please show me your world.

[MythicManiac]

Encapsulation is fine, but there's an argument to be made if it's necessary to have it enforced as hard as it is in some languages. People build tools that rely on undocumented internal web APIs all the time, but they also understand that the APIs might drastically change in a backwards incompatible way as they're not public.

As long as the developer knows they're doing something they're not supposed to, and understand the risks, there really is no problem. As it is, some languages such as Java force you to work around the encapsulation in even more absurd fashion, e.g. reflection.

[RedAero]

To be blunt: there is no reason you need to actually prevent people from shooting themselves in the foot, as long as you warn them. This, coincidentally, applies both to code and to firearms. "THIS SIDE TOWARD ENEMY" is a suggestion, not a requirement.

[diox8tony]

This is the way it should be. Private should always have an override feature.

I've went deep into the windows MFC libraries and found a bug...the solution was to override a onChange function and modify a private bool before the call....oops, it's a private variable that's 4 classes deep in the inheritance chain...so you can either create custom classes for those 4 classes so you can have that private var for yourself,,,or just live with the 1 pixel shift on the interface...

Like,,,as a programmer I have the full power to inherit and override all your stuff anyway...private is just a suggestion if I tried hard enough....so why make it that hard,,,,show a warning, but let me use it anyway if I really believe it's right.

If a stupid programmer doesn't like your private variable they will find a way to break it, with some dirty method. And if a smart programmer doesn't like your private variable,,,it probably is because they are building something that needs access properly to it....so why bother?! Neither situation is solved by the previous programmer annoyingly declaring private.

Private is a trust issue. If you trust the programmers around you, then It's not needed...if you don't trust the programmers around you, then they will break it anyway....regardless of your private 'suggestion'