Re:
On 19 Apr 2019 at 16:37, Tamara Berger wrote: > What code can I use to break out of a program completely, and not just out > of a loop? exit(1) ... but this exits the python interpreter. inside a function, a return statement might be more suitable. > I wrote code with 3 conditions for saving for a downpayment. The > first addresses cases that don't meet the minimum condition; i.e., enough > money to save for a downpayment within the allotted time. It has its own > print line, but also executes the irrelevant print lines for the other two > conditions. maybe you should regroup your if-statements. Or if you only want to display error messages of the first condition a user didn't met, save your conditions and the error messages as a tuple in a list and iterate over it: payment_ok = [ (cond1, "Not enough money"), (cond2, "some other error"), (cond3, "even another error"), ] all_ok = True for cond, err_str in payment_ok: if not cond: print(err_str): all_ok = False break -- Mit freundlichen Gruessen / Best Regards Mark Kettner -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a "gotcha" in Python?
Gilmeh Serda writes: > On Fri, 19 Apr 2019 21:01:05 +, Stefan Ram wrote: > >> Has this ever been a problem for someone? > > Only for programmers who come here from other languages and expect Python > to behave in the same manner as their favorite language, so they try and > argue that things from other languages should be implemented into Python > because they think it is a good idea, when it usually isn't. Python's > success proves that. Depends. If their favourite language was Fortran, the posted code would be unsurprising. (There would, of course, be loads of /other/ things that would be potential "gotcha"s.) -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode mail list archeology
On 20-4-2019 11:26, [email protected] wrote: http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML018/0594.html [quoot] > It is simple to make a compacter version of UTF-8 using the base > 256 character codes were possible (comacter for many languages). No. If you think otherwise, you have completely misunderstood what UTF-8 is all about. Please read the section "What is UTF-8?" in http://www.cl.cam.ac.uk/~mgk25/unicode.html carefully then you will see, why a base256 transfer encoding lacks essential properties that make UTF-8 so damn useful. [/quoot] I must be one of the persons who do not understand what base256 transfer encoding means. UTF-8 is, in bytes, just a sequence of 8 bit things, why can it not be transferred using a bas256 transfer encoding? $ echo "just my € 0.02 cents" | hexdump -C 6a 75 73 74 20 6d 79 20 e2 82 ac 20 30 2e 30 32 20 63 65 6e 74 73 0a -- Luuk -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode mail list archeology
On 20-4-2019 12:47, Luuk wrote: On 20-4-2019 11:26, [email protected] wrote: http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML018/0594.html [quoot] > It is simple to make a compacter version of UTF-8 using the base > 256 character codes were possible (comacter for many languages). No. If you think otherwise, you have completely misunderstood what UTF-8 is all about. Please read the section "What is UTF-8?" in http://www.cl.cam.ac.uk/~mgk25/unicode.html carefully then you will see, why a base256 transfer encoding lacks essential properties that make UTF-8 so damn useful. [/quoot] I must be one of the persons who do not understand what base256 transfer encoding means. UTF-8 is, in bytes, just a sequence of 8 bit things, why can it not be transferred using a bas256 transfer encoding? $ echo "just my € 0.02 cents" | hexdump -C 6a 75 73 74 20 6d 79 20 e2 82 ac 20 30 2e 30 32 20 63 65 6e 74 73 0a This is about python... luuk@computer:$ python Python 2.7.15rc1 (default, Nov 12 2018, 14:31:15) [GCC 7.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a="just my € 0.02 cents" >>> a 'just my \xe2\x82\xac 0.02 cents' >>> -- Luuk -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a "gotcha" in Python?
On 2019-04-19, Stefan Ram wrote: > Now consider the same in Python: > > def f(): > # ... > l = 22 # representing a length > # ... > l = 'abc'; # representing the left half of something > # ... > > A Python implementation does not catch the "error". Obviously it is a deliberate design decision that Python does not require declaration of variables. > Has this ever been a problem for someone? It would be astonishing if it had not. > Are there means to deal with this? You would hope that pylint would catch it, but it appears it does not. mypy --strict will catch it if the reassignment has a different type. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a "gotcha" in Python?
On Sun, Apr 21, 2019 at 2:14 AM Dennis Lee Bieber wrote: > Only use short (single character) names for items that only exist as > loop control, and are not rebound within the loop, nor used outside of the > scope of that loop (but can be reused in another subsequent loop > control)... > > >>> for l in range(50): > ... print l, > ... > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 > 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 > >>> > Be aware that this is using an old form of Python syntax, not supported by current versions. To try this example in a modern version of Python, write it like this: for l in range(50): print(l, end=" ") ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this a "gotcha" in Python?
On 21/04/19 8:16 AM, Chris Angelico wrote:
On Sun, Apr 21, 2019 at 2:14 AM Dennis Lee Bieber wrote:
Only use short (single character) names for items that only exist as
loop control, and are not rebound within the loop, nor used outside of the
scope of that loop (but can be reused in another subsequent loop
control)...
for l in range(50):
... print l,
...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
Be aware that this is using an old form of Python syntax, not
supported by current versions. To try this example in a modern version
of Python, write it like this:
for l in range(50):
print(l, end=" ")
Python2: print l,
Python3: print( l )
Recommend using the latter, unless "this application" MUST use/import an
externally-sourced module which has yet to be updated from Python2!
Regarding the choice of variable names/attaching meaning:-
Isn't there an argument that in this context, using the single letter
"l" as a variable name is 'lazy'? That the "l" could be used in
different contexts (per OP). That it conveys no meaning as to the
variable's purpose?
Surely the variable actually has 'meaning'. Otherwise it wouldn't be
used in the print statement/function! (appreciating this is a simple
situation/'toy example')
That being the case, "l" should be something like "list_of_choices"?
There is an opposite case (and I'm somewhat diffident about it). Namely,
using the underscore as a temporary variable. I have not seen it very
often (YMMV). However, it seems to fit under the heading of 'a Pythonic
convention'.
Remember that Python variable names may commence with a letter [pep3] or
an underscore [lexi]. Variables commencing with an underscore are
described as <<<2.3.2. Reserved classes of identifiers>>>.
PEP-8 [pep8] talks of <<<_single_leading_underscore: weak "internal use"
indicator>>> because whilst there is a convention of 'private use' it is
not enforced as a 'rule' - ie the "consenting adults" clause applies!
Thus, I have occasionally seen a sole underscore used as a variable
name. The "weak internal use" seemingly: <<'here', but I have no use for it.>>>
Example usage includes:
- accessing a tuple, but not being interested in every element, eg
>>> t = ( 1, 2, 3 )
# We ignore the first element unpacked from the tuple
>>> _, a, b = t
>>> print( f'There are { a } of these and { b } of those' )
There are 2 of these and 3 of those
>>> a
2
>>> b
3
# We can ignore more than one element - but here be dragons!
>>> _, c, _ = t
>>> print( f'{ c } is the only value needed' )
2 is the only value needed
>>> c
2
# We can even ascertain the (latest) value applied to the _ variable:
>>> _
3
# See the need to watch for those dragons!
- ignoring the 'index' of a for-loop, eg
# Let's do a speed test against client requirements
for _ in range( 100 ):
time_something()
- most usually I've seen the two combined:
# Ignore one element's value and process the other
for _, value in list_of_tuples:
# use value but not _
Arguing that the "l" variable name conveys no meaning, or is 'just a
counter', could one then modify the previous example:
> for _ in range( 50 ):
> print( _, end=" " )
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 >>>
Would this provoke a discussion (or an argument) in your next code review?
--
Regards =dn
Web-refs:
[lexi]
https://docs.python.org/3.6/reference/lexical_analysis.html#identifiers
[pep3] https://www.python.org/dev/peps/pep-3131/
[pep8] https://www.python.org/dev/peps/pep-0008/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is this a "gotcha" in Python?
On Sun, Apr 21, 2019 at 8:43 AM DL Neil wrote: > > Be aware that this is using an old form of Python syntax, not > > supported by current versions. To try this example in a modern version > > of Python, write it like this: > > > > for l in range(50): > > print(l, end=" ") > > > Python2: print l, > > Python3: print( l ) > > Recommend using the latter, unless "this application" MUST use/import an > externally-sourced module which has yet to be updated from Python2! And even then, you can choose to use print as a function in your module. Helps with compatibility. Anyhow. > Regarding the choice of variable names/attaching meaning:- > > Isn't there an argument that in this context, using the single letter > "l" as a variable name is 'lazy'? That the "l" could be used in > different contexts (per OP). That it conveys no meaning as to the > variable's purpose? In this specific case, I actually think that "l" is a bad choice, but not because it's a single letter - more because there is a very strong convention of using "i" for a loop iterator, and the lowercase "l" is confusingly similar. > Surely the variable actually has 'meaning'. Otherwise it wouldn't be > used in the print statement/function! (appreciating this is a simple > situation/'toy example') > > That being the case, "l" should be something like "list_of_choices"? No; a name like that would imply that it is a *collection*. You could iterate over such a thing, but the loop iterator gets just one of them. (Unless you're iterating over a list of lists of choices, or something unusual like that.) > There is an opposite case (and I'm somewhat diffident about it). Namely, > using the underscore as a temporary variable. I have not seen it very > often (YMMV). However, it seems to fit under the heading of 'a Pythonic > convention'. Generally, the lone underscore means "this doesn't matter". A Python program might do something five times thus (as per your example below): for _ in range(5): do_something() But if you want to take notice of WHICH something you're doing, it's much better to use a different name: for i in range(5): do_something(i) > PEP-8 [pep8] talks of <<<_single_leading_underscore: weak "internal use" > indicator>>> because whilst there is a convention of 'private use' it is > not enforced as a 'rule' - ie the "consenting adults" clause applies! > > Thus, I have occasionally seen a sole underscore used as a variable > name. The "weak internal use" seemingly: << 'here', but I have no use for it.>>> More or less. I would distinguish the lone underscore from the leading underscore, but there is a broad parallel. > # We can even ascertain the (latest) value applied to the _ variable: > >>> _ > 3 This is actually a different convention again, as the lone underscore is used automatically by the REPL: >>> 1 + 2 3 >>> _ + 3 6 > Arguing that the "l" variable name conveys no meaning, or is 'just a > counter', could one then modify the previous example: > > for _ in range( 50 ): > > print( _, end=" " ) > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 > 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 >>> > IMO this is a dangerous use of the underscore. If you DO care about the value, it should get another name. That said, though: the name does NOT need to be long. Single-letter variable names are entirely valuable. Short names for short-lived variables with small scope are absolutely fine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
