Re: Review, suggestion etc?
On 2020-12-18, Joe Pfeiffer wrote: > Grant Edwards writes: > >> Yep, there are definitly cases where it's pretty much the only right >> answer. If you try to avoid it, you end up writing what turns into a >> simulation of recursion -- and doing that correctly isn't easy. > > Decades ago I had to write a binary tree search in FORTRAN IV. It > wasn't pretty. I saw somebody try to write a graph search in GW-BASIC once. It was a huge mess, and wasn't anywhere close to working. Doing the same thing recursively was trivial -- even in C. In Python it wuld have been even trivialler. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
Grant Edwards writes: > On 2020-12-18, Joe Pfeiffer wrote: > >> Recursion has very limited application, but where it's the right >> tool it's invaluable (top-down parsers, some graph algorithms...). >> We teach it primarily because by the time a student has a good >> handle on how to write a recursive function they understand >> functions in general really well. > > Yep, there are definitly cases where it's pretty much the only right > answer. If you try to avoid it, you end up writing what turns into a > simulation of recursion -- and doing that correctly isn't easy. Decades ago I had to write a binary tree search in FORTRAN IV. It wasn't pretty. -- https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 2020-12-18, Joe Pfeiffer wrote: > Recursion has very limited application, but where it's the right > tool it's invaluable (top-down parsers, some graph algorithms...). > We teach it primarily because by the time a student has a good > handle on how to write a recursive function they understand > functions in general really well. Yep, there are definitly cases where it's pretty much the only right answer. If you try to avoid it, you end up writing what turns into a simulation of recursion -- and doing that correctly isn't easy. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
Bischoop writes:
> On 2020-12-17, Dennis Lee Bieber wrote:
>>>
>>
>> The main concern is that you are using a RECURSIVE call. It is much
>> better for such input checking to use an ITERATIVE (loop) scheme.
>>
>> def marriage():
>> #loop forever
>> while True:
>> #get response from user
>> maritals = input("Married: Yes/No ?").title()
>> #if response is good, exit (break) the loop
>> if maritals in ["Yes", "No"]: break
>> #otherwise display error message and repeat loop
>> print("Try again. Please respond with Yes or No")
>> #return valid response
>> return maritals
>>
>>
> It makes sense for me now, better logic used here than mine.
> I've never met that way used in * if maritals in ['Yes', No']: * ,
> it makes code elegant.
> So it's not good to use calling function itself (recursive call), I get it
> now.
Recursion has very limited application, but where it's the right tool
it's invaluable (top-down parsers, some graph algorithms...). We teach
it primarily because by the time a student has a good handle on how to
write a recursive function they understand functions in general really well.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 2020-12-17, Bischoop wrote:
> On 2020-12-17, Dennis Lee Bieber wrote:
>>>
>>
>> The main concern is that you are using a RECURSIVE call. It is much
>> better for such input checking to use an ITERATIVE (loop) scheme.
>>
>> def marriage():
>> #loop forever
>> while True:
>> #get response from user
>> maritals = input("Married: Yes/No ?").title()
>> #if response is good, exit (break) the loop
>> if maritals in ["Yes", "No"]: break
>> #otherwise display error message and repeat loop
>> print("Try again. Please respond with Yes or No")
>> #return valid response
>> return maritals
>>
>>
> It makes sense for me now, better logic used here than mine.
> I've never met that way used in * if maritals in ['Yes', No']: * ,
> it makes code elegant.
> So it's not good to use calling function itself (recursive call), I get it
> now.
--
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 2020-12-17, Dennis Lee Bieber wrote:
>>
>
> The main concern is that you are using a RECURSIVE call. It is much
> better for such input checking to use an ITERATIVE (loop) scheme.
>
> def marriage():
> #loop forever
> while True:
> #get response from user
> maritals = input("Married: Yes/No ?").title()
> #if response is good, exit (break) the loop
> if maritals in ["Yes", "No"]: break
> #otherwise display error message and repeat loop
> print("Try again. Please respond with Yes or No")
> #return valid response
> return maritals
>
>
It makes sense for me now, better logic used here than mine.
I've never met that way used in * if maritals in ['Yes', No']: * ,
it makes code elegant.
So it's not good to use calling function itself (recursive call), I get it now.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 2020-12-17, Michał Jaworski wrote:
>
> Exactly. I would go even further and make it a reusable function. Eg.
>
> def prompt_choices(prompt, choices):
> choices = set(c.lower() for c in choices)
> while value := input(f"{prompt} {choices}:").lower() not in choices:
> pass
> return value
>
> Or without := operator:
>
> def prompt_choices(prompt, choices):
> value = None
> choices = set(c.lower() for c in choices)
> while value not in choices:
> input(f"{prompt} {choices}:").lower()
> return value
>
> That way you can use it as follows:
>
> marital = prompt_choices("Married", ["yes", "no"])
>
Oh man that really not like they teach in tutorials.
These are the examples at which you look and think: moment, I need a few sec
to follow :-)
>> So in other words I shoudn't nest functions like in
>> changes(), add_people() etc but keep
>> everything in one functions.
>
> Simply move those functions outside of their "hosting" functions and
> call them as they are. Also, many of them won't be needed anymore as you
> introduce some generic helper functions (e.g. prompt_choices).
>
Honestly I've done it like that because I thought that would be more elegant
way to have how_old(), marriage() etc hosted in add_people() but I'm glad I've
done this time because learn a bit, I had quite a problem to keep people
argument storing and returning in every function, I see it was unecessary
as I know now but another experience.
>> Now I'll learn OOP as you said and then try to made this program again
>> with OOP from scratch.
>
> Recommend polishing the procedural approach a bit more too, though. Like
> reducing code repetition. Looking into how data is stored, eg. can fields
> be stored in CSV columns instead of JSON? OOP can be overwhelming at the
> very beginning. For instance it can take some time learning what should be
> an object and what shouldn't. You definitely can start adding e.g.
> dataclasses because they are more like structures (e.g. struct in C
> mentioned earlier).
>
Right I keep it in mind. Yes, the storing you mention I'll have to
improve, even the json I've done sucks because I've noticed it storing
everything in one column lol I thought that json library handles it
itself but apparently I have to tell him about it to insert key,values
into different columns.
--
Dzieki
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
> I think he's hinting at using a loop instead.
>
> while maritals != 'Yes' and maritals != 'No':
>maritals = input('Married: Yes/No ?: ').title()
Exactly. I would go even further and make it a reusable function. Eg.
def prompt_choices(prompt, choices):
choices = set(c.lower() for c in choices)
while value := input(f"{prompt} {choices}:").lower() not in choices:
pass
return value
Or without := operator:
def prompt_choices(prompt, choices):
value = None
choices = set(c.lower() for c in choices)
while value not in choices:
input(f"{prompt} {choices}:").lower()
return value
That way you can use it as follows:
marital = prompt_choices("Married", ["yes", "no"])
> So in other words I shoudn't nest functions like in
> changes(), add_people() etc but keep
> everything in one functions.
Simply move those functions outside of their "hosting" functions and
call them as they are. Also, many of them won't be needed anymore as you
introduce some generic helper functions (e.g. prompt_choices).
> Now I'll learn OOP as you said and then try to made this program again
> with OOP from scratch.
Recommend polishing the procedural approach a bit more too, though. Like
reducing code repetition. Looking into how data is stored, eg. can fields
be stored in CSV columns instead of JSON? OOP can be overwhelming at the
very beginning. For instance it can take some time learning what should be
an object and what shouldn't. You definitely can start adding e.g.
dataclasses because they are more like structures (e.g. struct in C
mentioned earlier).
czw., 17 gru 2020 o 17:38 Michael Torrie napisał(a):
> On 12/17/20 9:10 AM, Bischoop wrote:
> > Could you expand here, I rather don't know how I could do it different
> > way apart from if maritals == 'Yes' or maritals == 'No' or is it what
> > you meant?
>
> I think he's hinting at using a loop instead.
>
> while maritals != 'Yes' and maritals != 'No':
> maritals = input('Married: Yes/No ?: ').title()
>
> I think I got the logical condition right. Sometimes those are tricky!
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 2020-12-17, Michael Torrie wrote:
> On 12/17/20 9:10 AM, Bischoop wrote:
>> Could you expand here, I rather don't know how I could do it different
>> way apart from if maritals == 'Yes' or maritals == 'No' or is it what
>> you meant?
>
> I think he's hinting at using a loop instead.
>
> while maritals != 'Yes' and maritals != 'No':
> maritals = input('Married: Yes/No ?: ').title()
>
> I think I got the logical condition right. Sometimes those are tricky!
I think you're right.
Yes those are tricky sometimes :-)
Look how I had it previously:
def marriage():
maritals = input('Married: Yes/No ?: ').title()
while maritals != 'Yes' and maritals != 'No':
return marriage()
return maritals
marital = marriage()
When looking at it now I couldn't find the dumbest way for it.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 12/17/20 9:10 AM, Bischoop wrote:
> Could you expand here, I rather don't know how I could do it different
> way apart from if maritals == 'Yes' or maritals == 'No' or is it what
> you meant?
I think he's hinting at using a loop instead.
while maritals != 'Yes' and maritals != 'No':
maritals = input('Married: Yes/No ?: ').title()
I think I got the logical condition right. Sometimes those are tricky!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 2020-12-17, Michał Jaworski wrote:
Thanks for feedback and useful tips.
I couldn't use any OOP here because have not a clue about it, just going
to go toward it.
> I've made a quick look at the code and even executed it. It looks pretty
> clear and is easy to understand, although it has some structural problems.
> I won't do a thorough review but highlight the most important problems.
>
> First, the recursive user input pattern you use:
> def marriage():
> maritals = input('Married: Yes/No ?: ').title()
> while maritals != 'Yes' and maritals != 'No':
> return marriage()
> return maritals
>
>
> def marriage():
> ...
>
Could you expand here, I rather don't know how I could do it different
way apart from if maritals == 'Yes' or maritals == 'No' or is it what
you meant?
> You shouldn't be doing that unless you need a closure with nonlocal
> variables to read from. Otherwise it really harms the readability. I
> understand the urge to keep relevant code close to the usage but you would
> have better results with modules. If you really want to keep everything in
> a single module, keep functions close together in the file but don't nest
> them. Use relevant naming conventions instead. Simply think of how you
> would write that in C. You could use some object-oriented approach too, but
> I would recommend polishing structural programming first.
>
Well I don't know C, the only other language I was learning it was basic
for Atari :-) So in other words I shoudn't nest functions like in
changes(), add_people() etc but keep
everything in one functions.
> There are also other issues like not always closing files, and not
> validating the user input in specific places. Still, these will be more
> evident as you improve the structure of application and do thorough
> testing. Anyway, the code doesn't look bad. It of course needs improvement
> but I've also seen worse specimens from people being actually paid for
> writing the code.
>
> Remember that "how to make things better" is a function of few parameters:
> - what you want to achieve
> - what are you able to do
> - how much time do you have
>
> If your sole goal is to learn and improve skills, I would recommend
> polishing this in current procedural fashion to some extent, but not trying
> to make it perfect. Then I would start from scratch and experiment with
> different paradigms (OOP for instance). Then I would try to make a smaller
> project that has some actual utility.
>
Yes, I was pretty much interested in Python at the end 90s however life
made me putting this hobby away and now life changed again so I've more
free time and I'm happy be back with Python so after couple months
learning it again and writing few liners this is first thing that got me
to use what I've learnt so far and gave opportunity to solve moany
problems I had to deal with (had few nights without sleep ) :-)
Now I'll learn OOP as you said and then try to made this program again
with OOP from scratch.
--
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
I've made a quick look at the code and even executed it. It looks pretty
clear and is easy to understand, although it has some structural problems.
I won't do a thorough review but highlight the most important problems.
First, the recursive user input pattern you use:
def marriage():
maritals = input('Married: Yes/No ?: ').title()
while maritals != 'Yes' and maritals != 'No':
return marriage()
return maritals
It may look really convenient but you should really avoid that. In small
amounts it can be harmless, but it is kind of a resource leak. Aslo this
pattern is omnipresent so can quickly get out of hand and exceed maximum
recursion depth:
...
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
What you wanna do?:
You can choose only numbers.
Fatal Python error: Cannot recover from stack overflow.
Current thread 0x000112836dc0 (most recent call first):
...
File "vimart.py", line 52 in menu_choice
File "vimart.py", line 52 in menu_choice
...
Abort trap: 6
Also, this choice-prompt pattern could be moved to a separate general
function so you don't have to repeat it all over the code. Take a look at
the prompt() function from click.termui module to get a better
understanding on how to build such things (
https://github.com/pallets/click/blob/master/src/click/termui.py). I would
also recommend creating helper functions for common things like displaying
results because right now it's hard to figure out which parts of
application constitute its presentation layer and which are part of "core
logic". Try to keep these two concepts separate and you will get better
results.
Second major structural "problem" are inline function definitions:
def add_people():
def how_old():
...
def p_sex():
...
def marriage():
...
You shouldn't be doing that unless you need a closure with nonlocal
variables to read from. Otherwise it really harms the readability. I
understand the urge to keep relevant code close to the usage but you would
have better results with modules. If you really want to keep everything in
a single module, keep functions close together in the file but don't nest
them. Use relevant naming conventions instead. Simply think of how you
would write that in C. You could use some object-oriented approach too, but
I would recommend polishing structural programming first.
There are also other issues like not always closing files, and not
validating the user input in specific places. Still, these will be more
evident as you improve the structure of application and do thorough
testing. Anyway, the code doesn't look bad. It of course needs improvement
but I've also seen worse specimens from people being actually paid for
writing the code.
Remember that "how to make things better" is a function of few parameters:
- what you want to achieve
- what are you able to do
- how much time do you have
If your sole goal is to learn and improve skills, I would recommend
polishing this in current procedural fashion to some extent, but not trying
to make it perfect. Then I would start from scratch and experiment with
different paradigms (OOP for instance). Then I would try to make a smaller
project that has some actual utility.
czw., 17 gru 2020 o 04:17 Bischoop napisał(a):
> On 2020-12-17, Bischoop wrote:
>
>
> Accidently removed the paste, https://bpa.st/E3FQ
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Review, suggestion etc?
On 2020-12-17, Bischoop wrote: Accidently removed the paste, https://bpa.st/E3FQ -- https://mail.python.org/mailman/listinfo/python-list
Review, suggestion etc?
I've done my biggest project that allowed me to learn a lot. It's basically simply Database with basic options >> https://bpa.st/FU4A . What sucks here is basically the find_people() I'll have to work on it yet to make it more useful. . If anyone was bored and wished to point me some wrong way or suggest a better one I'd appreciate. -- Thanks -- https://mail.python.org/mailman/listinfo/python-list
