3 ms·
imo stuff like this should be moved up to the linter I guess private fields means 'we're not maintaining this as an API', but in practice these days means 'hah
by awinter-py 4y ago
imo stuff like this should be moved up to the linter
I guess private fields means 'we're not maintaining this as an API', but in practice these days means 'haha my library just wraps platform functionality but you'll have to fork it if you want to do a thing that should be easy'
we need better ways of indicating that a library consumer depends on a semantic, or that a library exports a semantic, or that a semantic has changed between releases
getting this right can enable safer + more maintainable software, but field privacy isn't the way IMO
- Doxin 4y ago> I guess private fields means 'we're not maintaining this as an API', but in practice these days means 'haha my library just wraps platform functionality but you'll have to fork it if you want to do a thing that should be easy' And now you know why python has decided to not have privacy at all but depend on convention instead. More languages should have some form of "I know this is private but I know what I'm doing" override IMO. It's irreplaceable in some circumstances.
- awinter-py 4y agopython in a sense has privacy. it's just less annoying than, say, dart's (which bruises my head a lot) dunder-prefixed members get mangled https://docs.python.org/3.10/tutorial/classes.html?highlight=private%20member#tut-private https://docs.python.org/3.10/tutorial/classes.html?highlight..., but you can get at them if you really want to pylint is angry when you access underscore methods https://pylint.pycqa.org/en/latest/user_guide/messages/warning/protected-access.html https://pylint.pycqa.org/en/latest/user_guide/messages/warni... these patterns are valuable for some teams and it's awesome that they're available as opt-ins, but it's hard to justify privacy without an escape hatch