Re: [Tutor] Quick Pythonic Style Tips
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" 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
Re: [Tutor] Quick Pythonic Style Tips
On 23Jul2017 19:02, Abdur-Rahmaan Janhangeer wrote:
ah pylint yes, great checker ! *some guys thought of inventing it*
Yes, very handy. Greate for checking for simple logic errors too (variable used
but never bound, missing imports, etc).
Just for folks' interest, I have a shell script called "lint" which I use which
encapsulates my personal lint practices. Great for a final check before
committing code. I append it for anyone else to use or adapt.
Interactively I've got a personal shell function called "lint" which, if no
files are specificly named, runs that script against whatever files are
currently modified in my working code repo. So one can just say "lint" at the
shell prompt to get a report on one's work in progress.
Script appended below.
Cheers,
Cameron Simpson
#!/bin/sh
#
# Lint the named files.
# - Cameron Simpson 22apr2017
#
set -ue
trace=
[ -t 2 ] && trace=set-x
cmd=$0
usage="Usage: $cmd filenames..."
[ $# -gt 0 ] || { echo "$cmd: missing filenames" >&2; echo "$usage" >&2; exit
2; }
xit=0
for lintfile
do
case "$lintfile" in
*.json)
$trace json-pprint <"$lintfile" 2>&1 >/dev/null || xit=1
;;
*.go)
$trace go tool vet -all -shadowstrict "$lintfile" || xit=1
;;
*.php)
{ $trace php -l "$lintfile" \
&& $trace phpcs --standard=PSR2 --report=emacs "$lintfile"
} || xit=1
;;
*.py)
{ $trace python3 -m py_compile "$lintfile" \
&& $trace pyflakes-2.7 "$lintfile" \
&& $trace pep8
--ignore=E111,E114,E126,E201,E202,E265,E266,E301,E302,E501,E731,W503 "$lintfile" \
&& $trace pylint "$lintfile"
} || xit=1
;;
*)echo "$cmd: no lint for $lintfile"
;;
esac
done
exit $xit
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Quick Pythonic Style Tips
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
Re: [Tutor] Quick Pythonic Style Tips
Thanks everybody, i wanted to get some pythonic ideas. yes forgot that assert(... is liked by some strongly typed programmers anInt -> did not not some people liked tha data encapsulation might be depressing to some migrating coders ah pylint yes, great checker ! *some guys thought of inventing it* Else more styling tips if any and whenever, appreciated ! Abdur-Rahmaan Janhangeer, Mauritius abdurrahmaanjanhangeer.wordpress.com On 23 Jul 2017 01:59, "Danny Yoo" wrote: > > I'd like to contibute a rather different sort of tidbit to what Alan > > wrote: be really careful about using mutable data types in function > > calls, as class variables, and just in general. > > By the way, there are some tools known as "linters" that can help > catch these kind of errors. https://www.pylint.org/ is one of them, > and it is worth using. > ___ > 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
Re: [Tutor] Quick Pythonic Style Tips
> I'd like to contibute a rather different sort of tidbit to what Alan > wrote: be really careful about using mutable data types in function > calls, as class variables, and just in general. By the way, there are some tools known as "linters" that can help catch these kind of errors. https://www.pylint.org/ is one of them, and it is worth using. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Quick Pythonic Style Tips
On 07/22/2017 07:46 AM, Alan Gauld via Tutor wrote: > On 22/07/17 12:20, Abdur-Rahmaan Janhangeer wrote: > >> As a user switching between some languages, it took sometimes before i >> discovered that there was a styling guide in python > > There are style idioms in most languages although not always > written down as clearly as in PEP8. That having been said > they should be viewed as guides not rules. In addition there > are often local style guides that must be followed in > a particular company. > >> i'd like to know if there was a specific C++ or java> style of doing things >> which should be avoided ? I'd like to contibute a rather different sort of tidbit to what Alan wrote: be really careful about using mutable data types in function calls, as class variables, and just in general. Here's a quick example of a classic "trap": # append value to list, if list omitted return a new list def func(val, alist=[]): alist.append(val) print alist return alist func(1) func(2) func(3) pop quiz :) what is the output? C++ has default arguments as well, so the output might be surprising in that context: [1] [1, 2] [1, 2, 3] Instead of you getting a new empty list each time 'func' is called without a second argument, the default list is part of the function. Python runs the function code when it comes across it, creating a function object which is then used each time the function is called, so this initially empty list is reused each time. To move the instantiation of the list to run-time, you could recode like this: def func(val, alist=None): if not alist: alist = [] alist.append(val) print alist return alist func(1) func(2) func(3) This is really a bit of "Python style" (using None as the default to act as a flag to do something special) that may not be reflected in the code format parts of style guides. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Quick Pythonic Style Tips
On 22/07/17 12:20, Abdur-Rahmaan Janhangeer wrote: > As a user switching between some languages, it took sometimes before i > discovered that there was a styling guide in python There are style idioms in most languages although not always written down as clearly as in PEP8. That having been said they should be viewed as guides not rules. In addition there are often local style guides that must be followed in a particular company. > i'd like to know if there was a specific C++ or java> style of doing things > which should be avoided ? Mostly it's not layout style things that should be avoided but actual programming styles - such as using Java style getXXX/setXXX type methods for attribute access. Or getting overly hung-up on trying to make data "private". Some people get excited about naming (xxx_yyy v xxxYyy v XxxYyy) but in practice these things make very little difference in comprehensibility of code, which is the most important consideration. Much more important is clarity of intent in naming (such as the plurals-for-collections rule you mentioned, or not using types as names - eg. anInt - unless it truly is a completely generic place-holder). The exception to all of this is code submitted to the standard library. It really should have PEP8 applied fairly rigorously both for the sake of consistency and because the library is often cited as a style template. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
