On 24/05/2023 10.21, Rob Cliffe via Python-list wrote:
>
>> This sort of code might be better as a single expression. For example:
>>
>> user = (
>> request.GET["user"]
>> .decode("utf-8")
>> .strip()
>> .lower()
>> )
>> user = orm.user.get(name=user)
>>
>>
> LOL. And I thought I was the one with a (self-confessed) tendency to
> write too slick, dense, smart-alec code. ????
> Indeed, I was itching to shorten it (starting with the low-hanging
> fruit: user = user.strip().lower() ).
> Seriously though: this kind of condensation can come unstuck when any of
> the steps need to be made more complicated.
...
> Peter's actual code feels more Pythonic to me. (It's even 2 lines
> shorter! ????)
On 24/05/2023 09.03, Peter J. Holzer wrote:
> I sometimes have a chain of transformations (e.g. first decode it, then
> strip extra spaces, then normalize spelling, then look it up in a
> database and replace it with the record, ...). Technically, of course
> all these intermediate objects are different, and I could make that
> explicit by using different variable names:
>
> user_param = request.GET["user"]
> user_decoded = str(user_param, encoding="utf-8")
> user_stripped = user_decoded.strip()
> user_normalized = user_stripped.lower()
> user_object = orm.user.get(name=user_normalized)
>
> But I find it easier to read if I just reuse the same variable name:
>
> user = request.GET["user"]
> user = str(user, encoding="utf-8")
> user = user.strip()
> user = user.lower()
> user = orm.user.get(name=user)
>
> Each instance only has a livetime of a single line (or maybe two or
> three lines if I have to combine variables), so there's little risk of
> confusion, and reusing the variable name makes it very clear that all
> those intermediate results are gone and won't be used again.
Once again/recently/another trainee came with a question about input()
because he expected an number (cf input() providing a string). In this
case, and to drive-home the point, preferred training illustration is:
quantity_input = input( "How many would you like? " )
quantity = float( quantity_input )
Many others, and I dare so all those who suffer from the aforementioned
"itch", want to condense this into a single line.
However, (continuing @Peter's theme) such confuses things when something
goes wrong - was the error in the input() or in the float()?
- particularly for 'beginners'
- and yes, we can expand the above discussion to talk about
error-handling, and repetition until satisfactory data is input by the
user or (?frustration leads to) EOD...
Accordingly, I'd start by favoring @Peter's "explicit" approach. However
(as mentioned), we end-up with a bunch of names (storage-space) which
are essentially unused - and many lint-er types will deplore such
single-use [like it's s-u plastic].
Thus, advice becomes somewhat the opposite(!) of function parameter
handling - there, I'm happy with one or two positional-parameters, but
by three-or-more, this over-taxed brain starts begging/itching for
named-parameters instead.
Now, the "easier" approach appeals. Indeed, if something goes wrong (per
input()/float(), above), at least one has the assistance of a
line-number (where error was noted). Further, using the PyCharm
Debugger/pdb makes locating the design-error/coder's mistaken
assumption, a snap.
A debatable-point is how much we should consider more junior-level
programmers. IMHO more common functions such as strip() and lower() can
be combined without much loss of readability or comprehension (apart
from 'function-chaining' adding complication). Whereas, the other three
lines are more likely to challenge - and/or become a source of concern
if mods are requested...
However, some disagreement - which comes back to why the "_input" suffix
(above) acts as an aide-memoire: When "user" is first used (hah!), it is
the result of an http request. It is then transmogrified, until at the
end where it is a query-result/object. Yes, however contrived and
deliberately drawn-out the example, there is still a difference between
the value which the code first produces (request/input) and that which
eventually settles-out (orm/float).
Accordingly (perhaps), "user_request" or "user_requested" and "user" or
"user_record" (according to the way 'that' ORM operates). Perhaps more
psychology rather than coding?
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
>
>> This sort of code might be better as a single expression. For example:
>>
>> user = (
>> request.GET["user"]
>> .decode("utf-8")
>> .strip()
>> .lower()
>> )
>> user = orm.user.get(name=user)
>>
>>
> LOL. And I thought I was the one with a (self-confessed) tendency to
> write too slick, dense, smart-alec code. ????
> Indeed, I was itching to shorten it (starting with the low-hanging
> fruit: user = user.strip().lower() ).
> Seriously though: this kind of condensation can come unstuck when any of
> the steps need to be made more complicated.
...
> Peter's actual code feels more Pythonic to me. (It's even 2 lines
> shorter! ????)
On 24/05/2023 09.03, Peter J. Holzer wrote:
> I sometimes have a chain of transformations (e.g. first decode it, then
> strip extra spaces, then normalize spelling, then look it up in a
> database and replace it with the record, ...). Technically, of course
> all these intermediate objects are different, and I could make that
> explicit by using different variable names:
>
> user_param = request.GET["user"]
> user_decoded = str(user_param, encoding="utf-8")
> user_stripped = user_decoded.strip()
> user_normalized = user_stripped.lower()
> user_object = orm.user.get(name=user_normalized)
>
> But I find it easier to read if I just reuse the same variable name:
>
> user = request.GET["user"]
> user = str(user, encoding="utf-8")
> user = user.strip()
> user = user.lower()
> user = orm.user.get(name=user)
>
> Each instance only has a livetime of a single line (or maybe two or
> three lines if I have to combine variables), so there's little risk of
> confusion, and reusing the variable name makes it very clear that all
> those intermediate results are gone and won't be used again.
Once again/recently/another trainee came with a question about input()
because he expected an number (cf input() providing a string). In this
case, and to drive-home the point, preferred training illustration is:
quantity_input = input( "How many would you like? " )
quantity = float( quantity_input )
Many others, and I dare so all those who suffer from the aforementioned
"itch", want to condense this into a single line.
However, (continuing @Peter's theme) such confuses things when something
goes wrong - was the error in the input() or in the float()?
- particularly for 'beginners'
- and yes, we can expand the above discussion to talk about
error-handling, and repetition until satisfactory data is input by the
user or (?frustration leads to) EOD...
Accordingly, I'd start by favoring @Peter's "explicit" approach. However
(as mentioned), we end-up with a bunch of names (storage-space) which
are essentially unused - and many lint-er types will deplore such
single-use [like it's s-u plastic].
Thus, advice becomes somewhat the opposite(!) of function parameter
handling - there, I'm happy with one or two positional-parameters, but
by three-or-more, this over-taxed brain starts begging/itching for
named-parameters instead.
Now, the "easier" approach appeals. Indeed, if something goes wrong (per
input()/float(), above), at least one has the assistance of a
line-number (where error was noted). Further, using the PyCharm
Debugger/pdb makes locating the design-error/coder's mistaken
assumption, a snap.
A debatable-point is how much we should consider more junior-level
programmers. IMHO more common functions such as strip() and lower() can
be combined without much loss of readability or comprehension (apart
from 'function-chaining' adding complication). Whereas, the other three
lines are more likely to challenge - and/or become a source of concern
if mods are requested...
However, some disagreement - which comes back to why the "_input" suffix
(above) acts as an aide-memoire: When "user" is first used (hah!), it is
the result of an http request. It is then transmogrified, until at the
end where it is a query-result/object. Yes, however contrived and
deliberately drawn-out the example, there is still a difference between
the value which the code first produces (request/input) and that which
eventually settles-out (orm/float).
Accordingly (perhaps), "user_request" or "user_requested" and "user" or
"user_record" (according to the way 'that' ORM operates). Perhaps more
psychology rather than coding?
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
