On 3/01/20 7:36 AM, Terry Reedy wrote:
On 1/2/2020 2:46 AM, Cameron Simpson wrote:
Inline code under the if...__main__ stuff cannot be called as a function;
Which makes it difficult to test app startup.
I usually consider the main() function a reusable component.
Which, if called (at
On 1/2/2020 2:46 AM, Cameron Simpson wrote:
Inline code under the if...__main__ stuff cannot be called as a
function;
Which makes it difficult to test app startup.
I usually consider the main() function a reusable component.
Which, if called (at least optionally) with a list of string
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
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
On 31/12/19 3:47 am, Barry Scott wrote:
"define before use" is basically email top-posting for code isn't it?
It means that the first things that you read in a module are the least
interesting.
That's not a big problem for top-level code, since you can easily
scroll down to the bottom of
> On 30 Dec 2019, at 15:35, Chris Angelico wrote:
>
> On Tue, Dec 31, 2019 at 1:47 AM Barry Scott wrote:
>>
>>
>>
>>> On 28 Dec 2019, at 22:49, Chris Angelico wrote:
>>>
>>> On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list
>>> wrote:
Is it helpful to, and thus, do you
On Tue, Dec 31, 2019 at 3:08 AM Barry Scott wrote:
>
>
>
> > On 30 Dec 2019, at 15:35, Chris Angelico wrote:
> >
> > On Tue, Dec 31, 2019 at 1:47 AM Barry Scott wrote:
> >>
> >>
> >>
> >>> On 28 Dec 2019, at 22:49, Chris Angelico wrote:
> >>>
> >>> On Sun, Dec 29, 2019 at 9:37 AM DL Neil via
On Tue, Dec 31, 2019 at 1:47 AM Barry Scott wrote:
>
>
>
> > On 28 Dec 2019, at 22:49, Chris Angelico wrote:
> >
> > On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list
> > wrote:
> >>
> >> Is it helpful to, and thus, do you have a style/convention for ordering
> >> the methods within each
> On 28 Dec 2019, at 22:49, Chris Angelico wrote:
>
> On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list
> wrote:
>>
>> Is it helpful to, and thus, do you have a style/convention for ordering
>> the methods within each class in your code?
>>
>> A major difference however, is that if
On 28Dec2019 19:19, Tim Chase wrote:
Inside a class, I tend to roughly follow
__new__ (if present)
__init__
other dunder methods
subsequent methods alphabetically
I put the factory methods up near __init__, ahead of other methods. But
after most dunders. Here I mean things like this:
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
On 29/12/19 2:19 PM, Tim Chase wrote:
On 2019-12-29 12:52, Greg Ewing wrote:
I tend to do this too, although it's probably just a habit
carried over from languages such as Pascal and C where you
have to go out of your way to get things in a different
order.
Apparently I'm not alone in my
"Define before use" is a broad principle that I try to follow, even
when the code itself doesn't mandate this.
IMO it makes the code easier to navigate even when it's not strictly
necessary. As others have said, Python mandates that the functions be
defined before they're CALLED, but I find
On 2019-12-29 12:52, Greg Ewing wrote:
> On 29/12/19 11:49 am, Chris Angelico wrote:
> > "Define before use" is a broad principle that I try to follow,
> > even when the code itself doesn't mandate this.
>
> I tend to do this too, although it's probably just a habit
> carried over from
On 12/28/19 6:52 PM, Greg Ewing wrote:
> On 29/12/19 11:49 am, Chris Angelico wrote:
>> "Define before use" is a broad principle that I try to follow, even
>> when the code itself doesn't mandate this.
> But strangely, I tend to do the opposite for methods of a class. I
> don't really know
On Sun, Dec 29, 2019 at 10:56 AM Greg Ewing wrote:
>
> On 29/12/19 11:49 am, Chris Angelico wrote:
> > "Define before use" is a broad principle that I try to follow, even
> > when the code itself doesn't mandate this.
>
> I tend to do this too, although it's probably just a habit
> carried over
On 29/12/19 11:49 am, Chris Angelico wrote:
"Define before use" is a broad principle that I try to follow, even
when the code itself doesn't mandate this.
I tend to do this too, although it's probably just a habit
carried over from languages such as Pascal and C where you
have to go out of
On 29/12/19 11:35 am, DL Neil wrote:
if our mythical collection of
module-functions has an internal-reference, eg b() requires a(), then
function a() MUST exist, ie be defined, 'before' function b().
Not true in Python -- a() must exist by the time b() is run,
but they can be written in the
On 12/28/19 5:35 PM, DL Neil via Python-list wrote:
Is it helpful to, and thus, do you have a style/convention for
ordering the methods within each class in your code?
Python's "honking great idea" of namespaces enables us to gather
functions/methods under a single name-umbrella, thereby
On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list
wrote:
>
> Is it helpful to, and thus, do you have a style/convention for ordering
> the methods within each class in your code?
>
> A major difference however, is that if our mythical collection of
> module-functions has an
20 matches
Mail list logo
