Re: Python, Be Bold!

[o1bigtenor]

On Wed, Jan 1, 2020 at 1:24 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> Greetings list,
>
> I wanted to make some suggestion about the Python interpreter but since
> it's more high-level, i decided to post it here instead of python-ideas.
>
> Well, concerning distributing Python apps, a natural way is to compile to
> native executables. But, another way is to have a python-specific
> executable which specifically requires the Python interpreter to be
> installed on the system. To that end, i propose
>
> -- Self-updating Python distributions
> -- Distributions which notify about new releases
> -- Easy compilation to python-specific executable (.pyz is a good candidate)
> -- More robust native Gui facilities
>
Speaking as just a very newbie very unskilled computer programmer I can tell
you that if Python decided to go to self-updating that that would be
the day that
I stopped using Python. Why?

I spent a considerable amount of time investigating containers and when it
became clear that the version that I was looking into had forced me into
accepting this self-updating I tried to figure out a way to 'control'
that feature.
I won't bore you with the whole mess but the end result was that the only way
that I could regain control over my computer - - - - I couldn't even
delete major
parts of that subsystem - - - - well it was a complete reinstall.

That, imo a very very M$ solution is something I spent many hours trying NOT
to do so anything that wants to take me to such again - - - - it will
get dropped.

To the powers that be - - - - please do NOT program Python to be
self-updating!!

Regards
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Does the argparse generate a wrong help message?

[Random832]

On Fri, Dec 27, 2019, at 23:08, jf...@ms4.hinet.net wrote:
> > > optional arguments:
> > >   -h, --help   show this help message and exit
> > >   --foo [FOO]  foo help
> > >   --goo GOOgoo help
> > >
> > > D:\Works\Python>py test.py --foo 1 --goo 2
> > > 1 ['2']
>
> So the square bracket means optional, not list? My misunderstanding:-(

To be clear, the brackets in the print output do mean a list, and it is because 
nargs=1 produces a list rather than the default (no nargs) which is to produce 
a single value. This is not normally visible to the end user (it's just a 
difference in how your program consumes the one mandatory argument), so it's 
not reflected in the help output. Square brackets in the help output mean an 
optional argument.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Does the argparse generate a wrong help message?

[jfong]

Random832於 2020年1月2日星期四 UTC+8上午5時04分36秒寫道：
> On Fri, Dec 27, 2019, at 23:08, jf...@ms4.hinet.net wrote:
> > > > optional arguments:
> > > >   -h, --help   show this help message and exit
> > > >   --foo [FOO]  foo help
> > > >   --goo GOOgoo help
> > > >
> > > > D:\Works\Python>py test.py --foo 1 --goo 2
> > > > 1 ['2']
> >
> > So the square bracket means optional, not list? My misunderstanding:-(
> 
> To be clear, the brackets in the print output do mean a list, and it is 
> because nargs=1 produces a list rather than the default (no nargs) which is 
> to produce a single value. This is not normally visible to the end user (it's 
> just a difference in how your program consumes the one mandatory argument), 
> so it's not reflected in the help output. Square brackets in the help output 
> mean an optional argument.

Yes, I have noticed my misunderstanding. I thought [FOO] in "--foo [FOO]" is a 
list until Chris had reminded me:-) Thank you for clarifying it in detail.

--Jach
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Front end

[James Lu]

I would use software like Airtable. You set the columns, Airtable produces
a type-checked form. Every spreadsheet also comes with its own API, so you
can exfiltrate the data programmatically easily.

On Sat, Dec 28, 2019, 10:36 L A Smit  wrote:

> Hi
>
> Don't know if this is the correct subject but i want a program like an
> invoice, You make an invoice and save it and the next one is ready to
> use. I am completely new to programming and want this program for myself.
>
>
> I want to use python to do it. Have already build the program but don't
> know how to put it in usable format. I hope you understand what i mean.
>
> Ex: Input.
>
> Quote Nr:
>
> Client:
>
> Product:
>
> Then there will be costs and in the end a cost per product.
>
> In the end a save button to save quote with input from line 1 and 2.
>
> Then the template is ready for next input.
>
> I understand that there is probably hundreds of these programs but to
> teach myself i want to wright my own program and then i can update it
> when needed.
>
>
>
> Thx
>
>
> L Smit
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Source code organisation

[DL Neil via Python-list]

On 29/12/19 5:49 PM, Cameron Simpson wrote:

On 29Dec2019 09:49, Chris Angelico  wrote:

"Define before use" is a broad principle that I try to follow, even
when the code itself doesn't mandate this. This generally means that
"if name is main" is the very last thing in the file, and if there's a
main() function or equivalent, that's usually just before that. Any
metaprogramming goes right at the top; sometimes this is mandated (if
I write a decorator function, it has to be above the functions it's
decorating), but even if it's not, metaprogramming goes before the
mainline.


For main, i have the opposite habit. If a module has a main() function 
for command line use I usually want that right up the front:


  #!/usr/bin/env python3
  
  import...

  def main(argv=None):
    ... main command line ...

  classes, functions, etc

  if __name__ == '__main__':
    sys.exit(main(sys.argv))

My reasoning here is that I want the main programme obvious up front.

But then I loosely follow "define before use" after that.



OK, I'll bite:

1 the reader (one assumes) starts at the top, then scrolls all the way 
to the bottom to find if...__main___, but is then directed to search for 
the def main... which is all the way back up to the top!


2 if instead of a main(), that code was under if ... __main__ would that 
be an equally reasonable and "obvious" place to find it?


--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

if not self-updating, at least the ability to update

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club  | github

Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Source code organisation

[Cameron Simpson]

On 02Jan2020 18:01, DL Neil  wrote:

On 29/12/19 5:49 PM, Cameron Simpson wrote:
For main, i have the opposite habit. If a module has a main() function 
for command line use I usually want that right up the front:


 #!/usr/bin/env python3
 
 import...

 def main(argv=None):
   ... main command line ...

 classes, functions, etc

 if __name__ == '__main__':
   sys.exit(main(sys.argv))

My reasoning here is that I want the main programme obvious up front.

But then I loosely follow "define before use" after that.


OK, I'll bite:

1 the reader (one assumes) starts at the top, then scrolls all the way 
to the bottom to find if...__main___, but is then directed to search 
for the def main... which is all the way back up to the top!


If they scrolled, they'd have seen the main() function. I consider it 
akin to the opening comment/docstring: I want the reader to know pretty 
immediately that this has a meaningful command line mode.


2 if instead of a main(), that code was under if ... __main__ would 
that be an equally reasonable and "obvious" place to find it?


Well...

Inline code under the if...__main__ stuff cannot be called as a 
function; I usually consider the main() function a reusable component.  
The boilerplate under if...__main__ at the bottom is just the call to it 
for when the module is used with "python -m". But main itself is 
standalone. So it won't be under the if...__main__; the only real 
discussion is where to put it.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list