nice, just wanted some "styling" guide rather than technical guides
you know doing things the python style rather than the python way Abdur-Rahmaan Janhangeer, Mauritius abdurrahmaanjanhangeer.wordpress.com On 24 Jul 2017 05:09, "Steven D'Aprano" <st...@pearwood.info> wrote: > On Sun, Jul 23, 2017 at 07:02:09PM +0400, Abdur-Rahmaan Janhangeer wrote: > > > assert(... is liked by some strongly typed programmers > > Not just strongly-typed programmers: > > http://import-that.dreamwidth.org/676.html > > > > data encapsulation might be depressing to some migrating coders > > "Data encapsulation" does not mean "data hiding". Python has excellent > data encapsulation: > > - packages encapsulate modules together; > > - modules encapsulate classes, functions and variables together; > > - classes encapsulate object state and behaviour together. > > > Compared to languages like C++ and Java, Python's data HIDING is weak. > Python has no private, public, protected, etc. > > But even in the strictest languages like C++ and Java, there is usually > some way to "defeat" the compiler and get access to private data and > break data hiding. For instance, in C++ you can often do something like > > #define private public > > and in Java you can use reflection. The creator of Python, Guido van > Rossum, understands that sometimes there *are* good uses for breaking > data hiding (usually for testing and debugging). Because Python is an > interpreter where most features are done at runtime rather than compile > time, implementing data hiding in Python would hurt performance, and > there would be some way to break it anyway. > > So why bother? > > Instead, Python is "for consenting adults". Data hiding is very simple: > the developer flags objects they want to keep private with a leading > underscore: > > _private > > and that tells you that this is private and you shouldn't touch it. If > you decide to ignore this and touch it anyway, then: > > - either you have a good reason, and that's okay; > > - or you are a "consenting adult", and if your code blows up, > well, that's your own fault and don't complain to us. > > > > -- > Steve > _______________________________________________ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
