RE: Improvement to imports, what is a better way ?

[avi.e.gross]

I stand corrected. Thomas is (mostly) writing valid Python if you use the
module that looks (deliberately) like the R implementation. The use of "+"
in two contexts such as when not needed to concatenate strings, reminded me
too much of R.

Either way, this thread has moved on from any original question. Now it is
about the long and short of it.

-Original Message-
From: Python-list  On
Behalf Of Thomas Passin
Sent: Thursday, January 19, 2023 9:37 PM
To: python-list@python.org
Subject: Re: Improvement to imports, what is a better way ?

On 1/19/2023 7:33 PM, avi.e.gr...@gmail.com wrote:
> Just FYI, the example Dave supplied was not using python code and 
> using a rather strange re-definition in the R language package he was 
> using. Or maybe not.
> 
> Anyone not interested, skip the rest.
> 
> First, R does not use indentation for almost anything. So you can 
> break one long line up into many lines all over the place where it is 
> clear you are continuing.
> 
> Second, the ggplot package (another name for module) came along before 
> pipes were used a lot and made a choice to overload the meaning of the 
> plus sign selectively between "verbs" of sorts.
> 
> The code Thomas shared says:
> 
> - Set up the beginning of a plot using the arguments provided and 
> create a DATA STRUCTURE. This structure is a rather complex list 
> structure composed internally of many kinds of named parts, some optional.
> - Then call a verb of sorts, called geom_point() to update the same 
> data structure appropriately and store info to be used LATER when you 
> call the print driver that knows how to handle this data structure. In 
> a sense, the first command sends the dta structure to the second 
> command which changes it and passes it along to
> - the next verb is theme_bw() which changes all kinds of elements in 
> the data structure and returns the update data structure.
> 
> The result is stored as the value of g2 and NOTHING HAPPENS.
> 
> If you even wrote print(g2) or implicitly printed it at the REPL level 
> such as by typing "g2" or not assigning it at all to a variable at the 
> REPL level, then the driver that handles such an object generates a 
> graph to whatever output device is currently set in whatever format is 
> set such as a JPEG image or a PDF file.
> 
> There are errors in what Thomas wrote as an example but not what is 
> mentioned.

Just to be clear, my example was copy-pasted from working Python code. 
It uses the plotnine package, available from PyPi, which is a partial
implementation of R's ggplot2 API as adapted for Python;  both are
implementations of the ideas from The Language of Graphics of Wilkinson.

I shortened a line or two to prevent wrapping by email clients and perhaps I
chopped something off by mistake.

> The overall flow looks like:
> 
> g2 <- ggplot(ARGS) + geom_point(ARGS) + theme_bw(ARGS)
> 
> The parentheses around the RHS are NOT needed and the above is very 
> typically written as:
> 
> g2 <- ggplot(ARGS) +
>   geom_point(ARGS) +
>   theme_bw(ARGS)
> 
> The plus signs at the end of each line tell the REPL to keep reading.
> 
> The code shown is not working code but was an illustration. The 
> ggplot() function takes many potential arguments including one for the 
> data.frame or tibble that holds rows and columns of data. You then 
> have to map some aesthetics such as what X and Y are bound to directly 
> to some column, or perhaps to a function involving columns. That is 
> not shown inside the aes() inner function and what is shown is 
> nonsense. As usual, function arguments are separated by commas and I 
> assume a line or more are missing. This example does not tell us what 
> columns I being graphed against what other column or other necessary 
> things. That can sometimes be told or changed later but I see none in 
> this example. This function call should have ended without a comma and
with a close parentheses followed by a plus sign.
> 
> The geom_point() function that follows can be empty and then would ask 
> for a chart overlay showing just the points. This example added the 
> size and color of those points.
> 
> The last verb of theme_bw() adjusts all kinds of parameters to provide 
> a certain look to be basically black and white for various background
items.
> 
> The example chose to include parens around everything so the plus 
> signs could now be anywhere, including the start of future lines. I 
> generally do not do things this way but it is a valid way.
> 
> I do note there is a python version of the ggplot package and maybe 
> Thomas is writing from that point of view in python.  I have never used
that.
> 
> As noted, most other R constructs use PIPES not the plu

Re: Improvement to imports, what is a better way ?

[Thomas Passin]

On 1/19/2023 7:33 PM, avi.e.gr...@gmail.com wrote:

Just FYI, the example Dave supplied was not using python code and using a
rather strange re-definition in the R language package he was using. Or
maybe not.

Anyone not interested, skip the rest.

First, R does not use indentation for almost anything. So you can break one
long line up into many lines all over the place where it is clear you are
continuing.

Second, the ggplot package (another name for module) came along before pipes
were used a lot and made a choice to overload the meaning of the plus sign
selectively between "verbs" of sorts.

The code Thomas shared says:

- Set up the beginning of a plot using the arguments provided and create a
DATA STRUCTURE. This structure is a rather complex list structure composed
internally of many kinds of named parts, some optional.
- Then call a verb of sorts, called geom_point() to update the same data
structure appropriately and store info to be used LATER when you call the
print driver that knows how to handle this data structure. In a sense, the
first command sends the dta structure to the second command which changes it
and passes it along to
- the next verb is theme_bw() which changes all kinds of elements in the
data structure and returns the update data structure.

The result is stored as the value of g2 and NOTHING HAPPENS.

If you even wrote print(g2) or implicitly printed it at the REPL level such
as by typing "g2" or not assigning it at all to a variable at the REPL
level, then the driver that handles such an object generates a graph to
whatever output device is currently set in whatever format is set such as a
JPEG image or a PDF file.

There are errors in what Thomas wrote as an example but not what is
mentioned.


Just to be clear, my example was copy-pasted from working Python code. 
It uses the plotnine package, available from PyPi, which is a partial 
implementation of R's ggplot2 API as adapted for Python;  both are 
implementations of the ideas from The Language of Graphics of Wilkinson.


I shortened a line or two to prevent wrapping by email clients and 
perhaps I chopped something off by mistake.



The overall flow looks like:

g2 <- ggplot(ARGS) + geom_point(ARGS) + theme_bw(ARGS)

The parentheses around the RHS are NOT needed and the above is very
typically written as:

g2 <- ggplot(ARGS) +
geom_point(ARGS) +
theme_bw(ARGS)

The plus signs at the end of each line tell the REPL to keep reading.

The code shown is not working code but was an illustration. The ggplot()
function takes many potential arguments including one for the data.frame or
tibble that holds rows and columns of data. You then have to map some
aesthetics such as what X and Y are bound to directly to some column, or
perhaps to a function involving columns. That is not shown inside the aes()
inner function and what is shown is nonsense. As usual, function arguments
are separated by commas and I assume a line or more are missing. This
example does not tell us what columns I being graphed against what other
column or other necessary things. That can sometimes be told or changed
later but I see none in this example. This function call should have ended
without a comma and with a close parentheses followed by a plus sign.

The geom_point() function that follows can be empty and then would ask for a
chart overlay showing just the points. This example added the size and color
of those points.

The last verb of theme_bw() adjusts all kinds of parameters to provide a
certain look to be basically black and white for various background items.

The example chose to include parens around everything so the plus signs
could now be anywhere, including the start of future lines. I generally do
not do things this way but it is a valid way.

I do note there is a python version of the ggplot package and maybe Thomas
is writing from that point of view in python.  I have never used that.

As noted, most other R constructs use PIPES not the plus sign and I wish
this package would change to conform but it is a bit late! LOL!

Avi



-Original Message-
From: Python-list  On
Behalf Of 2qdxy4rzwzuui...@potatochowder.com
Sent: Thursday, January 19, 2023 1:30 PM
To: python-list@python.org
Subject: Re: Improvement to imports, what is a better way ?

On 2023-01-19 at 12:59:21 -0500,
Thomas Passin  wrote:


Well, it's an art, not a science [...]


+1


# Create a plot
g2 = (
   ggplot(df2,
   aes('Days Since Jan 22',  # Comments can clarify these params
   + geom_point(size=.1, color='blue') # size, color params optional
   + theme_bw() # Optional theme (background, grid color, ...)
  )


You've got a comma followed by a plus sign in there, so I'm not exactly sure
where the parameters to which function begin and end.

When it starts to look like this, I begin breaking out the parameters:

label = 'Days Since Jan 22'
size = geom_point(size=.1, color='blue') theme = theme_bw()
g2 = g

RE: Improvement to imports, what is a better way ?

[avi.e.gross]

Just FYI, the example Dave supplied was not using python code and using a
rather strange re-definition in the R language package he was using. Or
maybe not.

Anyone not interested, skip the rest.

First, R does not use indentation for almost anything. So you can break one
long line up into many lines all over the place where it is clear you are
continuing.

Second, the ggplot package (another name for module) came along before pipes
were used a lot and made a choice to overload the meaning of the plus sign
selectively between "verbs" of sorts. 

The code Thomas shared says:

- Set up the beginning of a plot using the arguments provided and create a
DATA STRUCTURE. This structure is a rather complex list structure composed
internally of many kinds of named parts, some optional. 
- Then call a verb of sorts, called geom_point() to update the same data
structure appropriately and store info to be used LATER when you call the
print driver that knows how to handle this data structure. In a sense, the
first command sends the dta structure to the second command which changes it
and passes it along to
- the next verb is theme_bw() which changes all kinds of elements in the
data structure and returns the update data structure.

The result is stored as the value of g2 and NOTHING HAPPENS.

If you even wrote print(g2) or implicitly printed it at the REPL level such
as by typing "g2" or not assigning it at all to a variable at the REPL
level, then the driver that handles such an object generates a graph to
whatever output device is currently set in whatever format is set such as a
JPEG image or a PDF file.

There are errors in what Thomas wrote as an example but not what is
mentioned. 

The overall flow looks like:

g2 <- ggplot(ARGS) + geom_point(ARGS) + theme_bw(ARGS)

The parentheses around the RHS are NOT needed and the above is very
typically written as:

g2 <- ggplot(ARGS) + 
geom_point(ARGS) + 
theme_bw(ARGS)

The plus signs at the end of each line tell the REPL to keep reading.

The code shown is not working code but was an illustration. The ggplot()
function takes many potential arguments including one for the data.frame or
tibble that holds rows and columns of data. You then have to map some
aesthetics such as what X and Y are bound to directly to some column, or
perhaps to a function involving columns. That is not shown inside the aes()
inner function and what is shown is nonsense. As usual, function arguments
are separated by commas and I assume a line or more are missing. This
example does not tell us what columns I being graphed against what other
column or other necessary things. That can sometimes be told or changed
later but I see none in this example. This function call should have ended
without a comma and with a close parentheses followed by a plus sign.

The geom_point() function that follows can be empty and then would ask for a
chart overlay showing just the points. This example added the size and color
of those points.

The last verb of theme_bw() adjusts all kinds of parameters to provide a
certain look to be basically black and white for various background items.

The example chose to include parens around everything so the plus signs
could now be anywhere, including the start of future lines. I generally do
not do things this way but it is a valid way.

I do note there is a python version of the ggplot package and maybe Thomas
is writing from that point of view in python.  I have never used that.

As noted, most other R constructs use PIPES not the plus sign and I wish
this package would change to conform but it is a bit late! LOL!

Avi



-Original Message-
From: Python-list  On
Behalf Of 2qdxy4rzwzuui...@potatochowder.com
Sent: Thursday, January 19, 2023 1:30 PM
To: python-list@python.org
Subject: Re: Improvement to imports, what is a better way ?

On 2023-01-19 at 12:59:21 -0500,
Thomas Passin  wrote:

> Well, it's an art, not a science [...]

+1

> # Create a plot
> g2 = (
>   ggplot(df2,
>   aes('Days Since Jan 22',  # Comments can clarify these params
>   + geom_point(size=.1, color='blue') # size, color params optional
>   + theme_bw() # Optional theme (background, grid color, ...)
>  )

You've got a comma followed by a plus sign in there, so I'm not exactly sure
where the parameters to which function begin and end.

When it starts to look like this, I begin breaking out the parameters:

label = 'Days Since Jan 22'
size = geom_point(size=.1, color='blue') theme = theme_bw()
g2 = ggplot(df2, aes(label, size, theme))

> # Compose a long string:
> msg = ('A very long line .\n'
>   + 'Another long bit of text '
>   + 'plus another '
>   )

If all the pieces are constants, then Python will concatenate them for
you:

msg = ('A very long line .\n'
   'Another long bit of text '
   'plus another')

You can even mix in "f" strings:

m

Re: Improvement to imports, what is a better way ?

[Cameron Simpson]

On 19Jan2023 07:34, Dan Kolis  wrote:

On Thursday, January 19, 2023 at 12:09:02 AM UTC-5, cameron wrote:

I know this is vague. Once you find its stalling in a particular
function (if it is) you may be able to run that function directly. Also,
a print() at the top abd bottom/return of the stalling function. And so
on.


Dan says:
After lots of iterations, I changed one line in a call used to refresh 
windows from .update() to .update_idle_tasks()


Yeah. See the bottom of this page:
https://tkdocs.com/tutorial/eventloop.html


Some other dudes were so nice they tested it before that, it worked perfectly 
on their computers anyway.


This kind of thing can be timing and user interaction sensitive.


Now it seems to work 'all the way' too after this change on my favroritish 
computer.
Since a CTRL C often started it going again I had a hint there, reading 
other peoples various troubles all over the web made me think it was 
'someplace in this part'.


The `update_idle_tasks()` call runs pending display updates (i.e.  
redraws) but does not process any events (mostly user actions). So it 
generally returns promptly.


The `update()` call processes events as well. If those events make 
callbacks, the callbacks can block (depending what they do). Or they 
themselves might call update() if you've written your code that way.


There's a note on the page mentioned above.

Calling update() effectively runs the main event loop _here_, at the 
call. This is also how things like interactive dialogue boxes work: draw 
the dialogue, then internally call update() to process user interaction 
until the dialogue is done, then return.


This description is lousy, and we'd need to see the code to pin point 
exactly how your interface is deadlocking (or, possibly, just pausing 
for a long time while something happens).


But the key points are:
- there's no threading in the stuff above, so if you need GUI updates 
  _during_ some process you need to _call_ the GUI main loop for it to 
  do some work - you've blocked until that call comes back, like any 
  other function call
- the update_idle_tasks just does redraws; because it doesn't process 
  events those events' callbacks do not run, therefore those callbacks 
  cannot block your current code
- the update function does the full mainloop, including processing 
  events, and processing events can make callbacks, whcih can themselves 
  call update etc and ...


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

Re: Improvement to imports, what is a better way ?

[Thomas Passin]

On 1/19/2023 1:30 PM, 2qdxy4rzwzuui...@potatochowder.com wrote:

On 2023-01-19 at 12:59:21 -0500,
Thomas Passin  wrote:


Well, it's an art, not a science [...]


+1


# Create a plot
g2 = (
   ggplot(df2,
   aes('Days Since Jan 22',  # Comments can clarify these params
   + geom_point(size=.1, color='blue') # size, color params optional
   + theme_bw() # Optional theme (background, grid color, ...)
  )


You've got a comma followed by a plus sign in there, so I'm not exactly
sure where the parameters to which function begin and end.

When it starts to look like this, I begin breaking out the parameters:

label = 'Days Since Jan 22'
size = geom_point(size=.1, color='blue')
theme = theme_bw()
g2 = ggplot(df2, aes(label, size, theme))


# Compose a long string:
msg = ('A very long line .\n'
+ 'Another long bit of text '
+ 'plus another '
   )


If all the pieces are constants, then Python will concatenate them for
you:

msg = ('A very long line .\n'
'Another long bit of text '
'plus another')


Yes, the "+" sign is not actually needed in Python, but I find it's 
helpful anyway. Using one also mirrors the use of other operators, such 
as "or", where you cannot omit the operator.  Another matter of taste ...



You can even mix in "f" strings:

msg = ('long line\n'
f'left text {name} right text'
'more here')

But watch out for missing spaces between the pieces!  :-)


The PEP-8 rules are good, but they can't cover all cases perfectly.


Some the PEP-8 rules are debatable.  Regardless, they can't cover all
cases perfectly.  (IOW, we agree on the bit that's relevant to this
thread.)


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

Re: Improvement to imports, what is a better way ?

[Roel Schroeven]

2qdxy4rzwzuui...@potatochowder.com schreef op 19/01/2023 om 19:30:

> The PEP-8 rules are good, but they can't cover all cases perfectly.

Some the PEP-8 rules are debatable.  Regardless, they can't cover all
cases perfectly.  (IOW, we agree on the bit that's relevant to this
thread.)

PEP 8 even covers that:

A Foolish Consistency is the Hobgoblin of Little Minds
[...]
However, know when to be inconsistent – sometimes style guide 
recommendations just aren’t applicable. When in doubt, use your best 
judgment. [...]


--
"For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled."
-- Richard Feynman

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

Re: Improvement to imports, what is a better way ?

[2QdxY4RzWzUUiLuE]

On 2023-01-19 at 12:59:21 -0500,
Thomas Passin  wrote:

> Well, it's an art, not a science [...]

+1

> # Create a plot
> g2 = (
>   ggplot(df2,
>   aes('Days Since Jan 22',  # Comments can clarify these params
>   + geom_point(size=.1, color='blue') # size, color params optional
>   + theme_bw() # Optional theme (background, grid color, ...)
>  )

You've got a comma followed by a plus sign in there, so I'm not exactly
sure where the parameters to which function begin and end.

When it starts to look like this, I begin breaking out the parameters:

label = 'Days Since Jan 22'
size = geom_point(size=.1, color='blue')
theme = theme_bw()
g2 = ggplot(df2, aes(label, size, theme))

> # Compose a long string:
> msg = ('A very long line .\n'
>   + 'Another long bit of text '
>   + 'plus another '
>   )

If all the pieces are constants, then Python will concatenate them for
you:

msg = ('A very long line .\n'
   'Another long bit of text '
   'plus another')

You can even mix in "f" strings:

msg = ('long line\n'
   f'left text {name} right text'
   'more here')

But watch out for missing spaces between the pieces!  :-)

> The PEP-8 rules are good, but they can't cover all cases perfectly.

Some the PEP-8 rules are debatable.  Regardless, they can't cover all
cases perfectly.  (IOW, we agree on the bit that's relevant to this
thread.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Thomas Passin]

On 1/19/2023 11:55 AM, Roel Schroeven wrote:

Op 19/01/2023 om 11:32 schreef Stefan Ram:

dn  writes:
>The longer an identifier, the more it 'pushes' code over to the right 
or >to expand over multiple screen-lines. Some thoughts on this are 
behind >PEP-008 philosophies, eg line-limit.


   Raymond Hettinger (transcribed, shortened and partially
   paraphrased by me [Stefan Ram]):

|The line-width part of PEP 8 bugs me.
|
|You have to wrap your commits in seventy-two characters. You have
|to end your lines at seventy-nine characters.
|
|One time it bugs me is when I'm writing unit tests.
|
|When I write unit tests, I have to start with a class, and then
|inside the class there's a "def" for tests, and then the test
|starts with a "self.assertEqual", and by then most of my line
|is gone. So by the time I get to any business logic in my test,
|I'm near the end of the line.
|
|If I go over seventy-nine characters, somebody will come and
|PEP 8 me.

 [snip]

Well, it's an art, not a science.  Very long lines are hard to read. 
Multi-line "lines" can be hard because we are all used to taking in a 
line of code at a time.  And some things you can't shorten, like a long URL.


Personally I prefer shorter lines, even shorter than 72 characters.  But 
splitting a long line of code while still making it easy to grasp is an 
art in itself.  Some constructions do lend themselves nicely to 
splitting into several lines (I hope they don't get wrapped by your 
email reader!):


# Create a plot
g2 = (
  ggplot(df2,
  aes('Days Since Jan 22',  # Comments can clarify these params
  + geom_point(size=.1, color='blue') # size, color params optional
  + theme_bw() # Optional theme (background, grid color, ...)
 )

# Compose a long string:
msg = ('A very long line .\n'
+ 'Another long bit of text '
+ 'plus another '
  )

For the second example, I will sometimes tokenize it:

M1A = 'A very long line .\n'
M1B = 'Another long bit of text '
M1C = 'plus another '
msg = M1A + M1B + M1C

But I usually find the first form easier to grasp, so I tend to use it 
more - and I don't have to invent throwaway variable names.


The PEP-8 rules are good, but they can't cover all cases perfectly.

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

Re: Improvement to imports, what is a better way ?

[Roel Schroeven]

Op 19/01/2023 om 11:32 schreef Stefan Ram:

dn  writes:
>The longer an identifier, the more it 'pushes' code over to the right or 
>to expand over multiple screen-lines. Some thoughts on this are behind 
>PEP-008 philosophies, eg line-limit.


   Raymond Hettinger (transcribed, shortened and partially
   paraphrased by me [Stefan Ram]):

|The line-width part of PEP 8 bugs me.
|
|You have to wrap your commits in seventy-two characters. You have
|to end your lines at seventy-nine characters.
|
|One time it bugs me is when I'm writing unit tests.
|
|When I write unit tests, I have to start with a class, and then
|inside the class there's a "def" for tests, and then the test
|starts with a "self.assertEqual", and by then most of my line
|is gone. So by the time I get to any business logic in my test,
|I'm near the end of the line.
|
|If I go over seventy-nine characters, somebody will come and
|PEP 8 me.
|
|They'll come in and say: "Oh, Raymond's line hit eighty-one
|characters, I'm going to PEP 8 it!". And so, while I'm not
|looking, they come in and reformat my code.
|
|They'll just throw a line break at a really awkward place.
|
|Does that make the code better?
|
|So, to escape that pressure, I think: Maybe I can just commit
|a little atrocity and that way no one will ever come and PEP 8 me.
|I'll just shorten my variable names.
|
|Does that make the code better?
|
freely adapted from Raymond Hettinger
He then goes on to say he uses 90-ish, IIRC: he tries to stay under 
that, but doesn' t mine if a line goes a bit over. Or at least that's 
what I remember from that talk, I might be wrong.


--

"If you don't read the newspaper, you're uninformed. If you read the newspaper,
you're mis-informed."
-― Onbekend (dikwijls toegeschreven aan Mark Twain, waarschijnlijk 
onterecht)

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

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

On Thursday, January 19, 2023 at 12:09:02 AM UTC-5, cameron wrote:

> I know this is vague. Once you find its stalling in a particular 
> function (if it is) you may be able to run that function directly. Also, 
> a print() at the top abd bottom/return of the stalling function. And so 
> on. 


Dan says:

After lots of iterations, I changed one line in a call used to refresh windows 
from .update() to .update_idle_tasks()

Some other dudes were so nice they tested it before that, it worked perfectly 
on their computers anyway.

Now it seems to work 'all the way' too after this change on my favroritish 
computer.

Since a CTRL C often started it going again I had a hint there, reading other 
peoples various troubles all over the web made me think it was 'someplace in 
this part'.

Regards,
Daniel B. Kolis

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

Re: Improvement to imports, what is a better way ?

[Cameron Simpson]

On 18Jan2023 16:10, Dan Kolis  wrote:

I have written a very sizable and elaborate program that uses tKinter for X11 
displays of genomics.
Yet maybe 1 of 6 times it freezes, so I decided to extract the minimum 
that works perfectly and add back big pieces. It does it both running 
.pyc and in VSCode.


The other thing you can do is put in a heap of print() calls in 
strategic places. See if you can get a handle on what its doing when it 
freezes. This might be iterative, zooming in on where this happens, if 
it's a specific thing.


I know this is vague. Once you find its stalling in a particular 
function (if it is) you may be able to run that function directly. Also, 
a print() at the top abd bottom/return of the stalling function. And so 
on.


If the GUI freezes, maybe you're running something time consuming inline 
in the event loop, such that it blocks reaching the "idle" point where 
the tk gui updates widgets and polls for user actions.


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

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

I have written a very sizable and elaborate program that uses tKinter for X11 
displays of genomics.

Yet maybe 1 of 6 times it freezes, so I decided to extract the minimum that 
works perfectly and add back big pieces. It does it both running .pyc and in 
VSCode.

so even the most minor of oddities is suspect. I cant really think of any 
better way to debug it. I see no evidence in WWW searches its a generic 
problem. So tracing the startup and watching it hop all around is about one of 
five lesser problem line items.

Regs
Dan

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

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

Thank you

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

Re: Improvement to imports, what is a better way ?

[Michael Torrie]

On 1/18/23 14:42, Dan Kolis wrote:
> 
>> I don't think you've described this. I don't know what you mean here. 
> 
> When I trace it in VSCode the imports seem like they endlessly suspend 
> scanning and go to other ones over and over. Like "Whats this doing ?"
> 

Nothing to worry about there. Python knows what it's doing! :)  Lots of
modules import other modules, so there will be a spanning tree of sorts.
 Each module will only actually be formally imported once.  The rest is
just setting up name spaces.  Yes it all adds to run time latency, but
it certainly won't lead to any leaks.

Definitely there's no need to import a module's dependencies; it will do
that itself.  Just import what your own module explicitly needs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Greg Ewing]

On 19/01/23 10:40 am, Dan Kolis wrote:

I guess I don't full understand what bothers me about the repetition of the 
imports so much.


It's doubtful that every module uses every one of those imports.
It looks like someone had a standard block of imports that they
blindly pasted at the top of every file, to avoid having to think
about which ones were actually needed.

If you're looking for advice, I would suggest:

* Only import what you use in a particular file (this doesn't
have much effect on efficiency, but there's less clutter for
the reader.)

* Only use short names for modules that are *very* frequently
referenced. Use full unabbreviated names for everything else.

* Don't 'import foo as foo', just 'import foo'.

* Don't try to line the code up in columns, it doesn't really
help readability IMO.

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

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

> I don't think you've described this. I don't know what you mean here. 

When I trace it in VSCode the imports seem like they endlessly suspend scanning 
and go to other ones over and over. Like "Whats this doing ?"

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

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

Most of the time the newbie I visualize adding a function copies and pastes 
maybe a screen of python and changes it a little, maybe 5% of the lines have a 
xx. code so they rarely have to understand it,  thats not the part of the 
program there changing.

Also, I suffered long and hard for extreme uniformity in the names and so on, 
there utterly uniform, so there not so bad to consider, ( I hope ).

I guess I don't full understand what bothers me about the repetition of the 
imports so much. The tracing of it seems so bizarre, it just seems like its 
wrong.

Regs
Dan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Cameron Simpson]

On 18Jan2023 12:57, Dan Kolis  wrote:
I'm not sure what to do. Do either / both know if there is a way to 
make it parse each import list to bytecode in one shot ??


Python usually compiles files to bytecode and leaves those around as 
.pyc files to be used until the original source is modified. And anyway, 
an imported module is only loaded a ready once; imports are kept track 
of in the sys.modules dict, and just pulled directly from there when the 
same module is requests by another import.


The hop around read keeps making me worry it migth leave some memory 
leak or something.


I don't think you've described this. I don't know what you mean here.

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

Re: Improvement to imports, what is a better way ?

[Paul Bryan]

On Thu, 2023-01-19 at 09:47 +1300, dn via Python-list wrote:

> The longer an identifier, the more it 'pushes' code over to the right
> or 
> to expand over multiple screen-lines. Some thoughts on this are
> behind 
> PEP-008 philosophies, eg line-limit.

I sympathize with this issue. I've pushed the line limit to 96, which
in my case removed this pain point. My argument—though subjective—is
that we have wide screens now, and it's quite unlikely production code
will be accessed through a vintage VT-100 terminal or printed on a 80-
column dot-matrix printer. That said, even if you stick to PEP-8
proper, `black` does most of the formatting work, and it seems to do a
reasonable job despite longer module identifiers.

> In the body of the code, if every time an external identifier is used
> it 
> must be prefixed by a full 'path', the cognitive "burden" shifts from
> the aspect highlighted (above), to a reading-burden. Thus, (in
> extreme 
> cases) moving towards a 'wall of text' problem.

I tend to agree this can be a problem in some cases, but I think those
can be made manageable. For brevity's sake, I import often-used data
types directly into the module's name space. It's far more rare that I
try to abbreviate a module name; common ones like importing pandas as
pd is a good counterexample.

> In using TDD, code is constructed module-by-module (not necessarily
> a 
> Python Module). So, when it comes time to call
> avMedia.fetch_the_file() 
> [sic] there is little thinking about the "avMedia" bit. The emphasis
> is 
> on the function-name, and it's parameters. 'I need that file so that
> I 
> can ...'.

I'm not entirely sure what you mean by not a Python module. Even in
test modules, I would only import what's required. If it turns out
`fetch_the_file` is called dozens of times or more, I would have no
qualm about importing it directly into the test module's namespace so
that it doesn't need to be prefixed at all.

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

Re: Improvement to imports, what is a better way ?

[Weatherby,Gerard]

In the body of the code, if every time an external identifier is used it
must be prefixed by a full 'path', the cognitive "burden" shifts from
the aspect highlighted (above), to a reading-burden.

As the fictional Jack McCoy ( https://en.wikipedia.org/wiki/Jack_McCoy) would 
say --

Objection: Assumes facts not in evidence!

If I read A.py:

import …
# many lines of code
x = obscure_module.widget(4)

I know immediately where the function widget is.

If I read B.py
from obscure_module import widget
# many lines of code
x = widget(4)

Now I have to find out where the heck “widget” came from

And C.py

from obscure_module import widget as gadget
# many lines of code
x = gadget(4)

which is actually easier and harder to read.  Personally, I’m much happier with 
A.py than B.py or C.py.







From: Python-list  on 
behalf of dn via Python-list 
Date: Wednesday, January 18, 2023 at 3:49 PM
To: python-list@python.org 
Subject: Re: Improvement to imports, what is a better way ?
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On 19/01/2023 08.56, Mats Wichmann wrote:
> On 1/18/23 12:29, Paul Bryan wrote:
...

>>> import os asos
>>> import sys as   sys
>>> import importlib as importlib
>
> A general comment: there are some very common "import ... as" idioms
> (for example, it seems like *everyone* does "import pandas as pd") and
> those are okay to follow, but in general I would stay away from trying
> to give everything short-names.  Each module imported with a name other
> than their own is a memory burden for the reader (maybe even for you!).
>
>>> import aboutTime as tt  # Time dates timestamps and the
>>> like
>>> import avMedia as   av  # Audio and maybe video 'someday'
>>> well definitely lots of TTS text to speech
>>> import basicSwitchboard as  sc  # First switchboard lurking.
>>> Kickoff to sequence viewers
>
> Any decent editor these days will autocomplete for you, so there's
> really not much if any typing burden in using the full names.

Have vacillated on aspects of this topic, over the years. Currently I'm
in favor of abbreviations and not only the commonly-accepted/-used ones,
eg np for numpy.
(but am keen to learn from your wisdom)

I've argued the auto-complete cf typing point. So, that not at-issue.

The longer an identifier, the more it 'pushes' code over to the right or
to expand over multiple screen-lines. Some thoughts on this are behind
PEP-008 philosophies, eg line-limit.

In the body of the code, if every time an external identifier is used it
must be prefixed by a full 'path', the cognitive "burden" shifts from
the aspect highlighted (above), to a reading-burden. Thus, (in extreme
cases) moving towards a 'wall of text' problem.

The primary interest is to remove "burden" aka complexity.

In using TDD, code is constructed module-by-module (not necessarily a
Python Module). So, when it comes time to call avMedia.fetch_the_file()
[sic] there is little thinking about the "avMedia" bit. The emphasis is
on the function-name, and it's parameters. 'I need that file so that I
can ...'.

Using the IDE-as-a-tool argument (similar to above): if I miss-out,
mistype, use the wrong abbreviation, or otherwise fail to identify where
fetch_the_file() is located, the IDE will immediately tell me.
(dn you're wrong - again!)

Accordingly, the abbreviation/full-module-name is almost taken-on-trust.
(you're going to prove/test the linkage, either way, right?)


Personal Biases:
- TDD
- when starting to write the program[me]-code one of the first steps is
to marshal resources, which includes the question: which functions will
be called and thus which Python-modules should be imported? Thus,
listing all imports 'at the top' is a separable task.
- an early language learned (back-when) was COBOL, which has a formal
structure and separation between elements/phases of a program[me]'s
construction and execution. Some such thinking no doubt lingers...

--
Regards,
=dn
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!nUeLMY3g5EV0oaXoGfknoeDOLU9qMoIxHOe7jhHbHfN1v7-wj17OJCgqL_IyHpAr0EN8gyzj5ZEQZB9_A-rB3A_Q5g$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!nUeLMY3g5EV0oaXoGfknoeDOLU9qMoIxHOe7jhHbHfN1v7-wj17OJCgqL_IyHpAr0EN8gyzj5ZEQZB9_A-rB3A_Q5g$>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

dn and Mats, thanks for your advice.

I'm not sure what to do. Do either / both know if there is a way to make it 
parse each import list to bytecode in one shot ?? The hop around read keeps 
making me worry it migth leave some memory leak or something.

I dont know. 

Thanks though, both your dialog's are very helpful.

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

Re: Improvement to imports, what is a better way ?

[dn via Python-list]

On 19/01/2023 08.56, Mats Wichmann wrote:

On 1/18/23 12:29, Paul Bryan wrote:

...


import os as    os
import sys as   sys
import importlib as importlib


A general comment: there are some very common "import ... as" idioms 
(for example, it seems like *everyone* does "import pandas as pd") and 
those are okay to follow, but in general I would stay away from trying 
to give everything short-names.  Each module imported with a name other 
than their own is a memory burden for the reader (maybe even for you!).



import aboutTime as tt  # Time dates timestamps and the
like
import avMedia as   av  # Audio and maybe video 'someday'
well definitely lots of TTS text to speech
import basicSwitchboard as  sc  # First switchboard lurking.
Kickoff to sequence viewers


Any decent editor these days will autocomplete for you, so there's 
really not much if any typing burden in using the full names.


Have vacillated on aspects of this topic, over the years. Currently I'm 
in favor of abbreviations and not only the commonly-accepted/-used ones, 
eg np for numpy.

(but am keen to learn from your wisdom)

I've argued the auto-complete cf typing point. So, that not at-issue.

The longer an identifier, the more it 'pushes' code over to the right or 
to expand over multiple screen-lines. Some thoughts on this are behind 
PEP-008 philosophies, eg line-limit.


In the body of the code, if every time an external identifier is used it 
must be prefixed by a full 'path', the cognitive "burden" shifts from 
the aspect highlighted (above), to a reading-burden. Thus, (in extreme 
cases) moving towards a 'wall of text' problem.


The primary interest is to remove "burden" aka complexity.

In using TDD, code is constructed module-by-module (not necessarily a 
Python Module). So, when it comes time to call avMedia.fetch_the_file() 
[sic] there is little thinking about the "avMedia" bit. The emphasis is 
on the function-name, and it's parameters. 'I need that file so that I 
can ...'.


Using the IDE-as-a-tool argument (similar to above): if I miss-out, 
mistype, use the wrong abbreviation, or otherwise fail to identify where 
fetch_the_file() is located, the IDE will immediately tell me.

(dn you're wrong - again!)

Accordingly, the abbreviation/full-module-name is almost taken-on-trust. 
(you're going to prove/test the linkage, either way, right?)



Personal Biases:
- TDD
- when starting to write the program[me]-code one of the first steps is 
to marshal resources, which includes the question: which functions will 
be called and thus which Python-modules should be imported? Thus, 
listing all imports 'at the top' is a separable task.
- an early language learned (back-when) was COBOL, which has a formal 
structure and separation between elements/phases of a program[me]'s 
construction and execution. Some such thinking no doubt lingers...


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

Re: Improvement to imports, what is a better way ?

[Mats Wichmann]

On 1/18/23 12:29, Paul Bryan wrote:

I would suggest allowing each module to define its own imports, don't
import what a module doesn't consume, keep them simple, avoid devising
a common namespace for each, and let tools like isort/black work out
how to order/express them in source files.


Indeed.  And various checkers will report on unused imports.

These add no value... why import something "as" and give it its own name?


import os as    os
import sys as   sys
import importlib as importlib


A general comment: there are some very common "import ... as" idioms 
(for example, it seems like *everyone* does "import pandas as pd") and 
those are okay to follow, but in general I would stay away from trying 
to give everything short-names.  Each module imported with a name other 
than their own is a memory burden for the reader (maybe even for you!).



import aboutTime as tt  # Time dates timestamps and the
like
import avMedia as   av  # Audio and maybe video 'someday'
well definitely lots of TTS text to speech
import basicSwitchboard as  sc  # First switchboard lurking.
Kickoff to sequence viewers


Any decent editor these days will autocomplete for you, so there's 
really not much if any typing burden in using the full names.


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

Re: Improvement to imports, what is a better way ?

[Paul Bryan]

I would suggest allowing each module to define its own imports, don't
import what a module doesn't consume, keep them simple, avoid devising
a common namespace for each, and let tools like isort/black work out
how to order/express them in source files.

On Wed, 2023-01-18 at 10:43 -0800, Dan Kolis wrote:
> This program has lots of files and each is well segregated for a
> concept.
> 
> the top of each as a heap of imports, all identical. Well the very
> top has some one of's
> 
> import os as    os
> import sys as   sys
> import importlib as importlib
> import datetime as  dt
> from   tokenize import  maybe
> import signal
> 
> from   tkinter import filedialog as fd
> from   tkinter.messagebox import    showinfo
> import tkinter as   tk  
> from   tkinter import   ttk
> from   tkinter import   font
>  
> from   PIL import Image as  pl
> from   PIL import ImageTk   as  ii
> 
> # Imports part of this program 
> import aboutTime as tt  # Time dates timestamps and the
> like
> import avMedia as   av  # Audio and maybe video 'someday'
> well definitely lots of TTS text to speech
> import basicSwitchboard as  sc  # First switchboard lurking.
> Kickoff to sequence viewers
> import bestNotifications as bn  # Alerts, modals and
> notifications of many kinds including TK windows
> import bitBlitting as   bb  # Help - # A setup window with
> basic facts written into files and the workspace
> import configSetting as cs  # A setup window with basic facts
> written into files and the workspace
> import devPeeks as  dp  # Developments peek assets code
> for adding features and debugging
> import fileIo as    io  # File reads, writes even some of
> the the pickle and unpickling
> import forFun as    ff  # Staging area for uncertian
> features, also some dynamic code inclusion
> import fractionScreens as   fs  # Common window pieces for TK
> windows in sequence viewers
> import genomeDb as  gd  # IO to from databases external
> files gbk and others sure
> import globalIdeas as   gi  # Common code for stuff used
> everywhere and definition of share DOT OBJECTS
> import insertableEditors as ie  # Text editor(s) and support for
> that, some language issues managed too
> import modalSimple as   mo  # Modal windows icp seq ssues,
> not used much currently
> import osDependant as   od  # Operating system dependant
> calls and adaptions
> import pickle as    pk  # Packaging to and from file
> system for objects especially DOT OBJECTS
> import screenBuilder1 as    sb  # Screen maker for TKinter and
> TKinter ++ windows
> import selectViewer as  sv  # Window for picking which
> sequence viewers are enabled
> import sequencesMaintain as sm  # Touching up temporal version
> issues of DOT OBJECTS
> import sequencesOverview as so  # Working with sequences as macro
> facts, lists, see turn off etc
> import serverHttp1 as   sh1 # Servers for HTTP - User Support
> import serverHttp2 as   sh2 # Servers for HTTP - Protein
> viewing
> import specialFour as   sf  # Classes and stuff for viewer
> four, a very complex viewer
> import stagingNow as    sn  # More stabler new ideas getting
> tried out and moved in
> import taskingFunction as   tf  # Tasker for real timeish event
> processor calls. Has two versions both work
> import toastMaker as    tm  # Notifications
> import transFormations as   xf  # Sequence transFormations from
> mother natures ideas like DNA and RNA
> import unlovedMenus as  um  # Pretty rarely used ond
> fashioned menus. A while interface is in here that works
> import wayOffline as    wo  # Code not discarded but just
> studies, etc
> import windowsX as  wx  # Windows Life ! X11 esp TK not
> MS Windoze ...
> 
> So the file for instance fileIo.py has a duplicate of this.
> 
> I want to be able to call any code by using the two char prefix form
> anywhere. ex: io.get_Sequence(  'abc.fa' )
> 
> this seems weirdly disorderly. when it starts it sort of iterates
> down into objects, backs up etc.
> 
> What's the right way to do this ?
> 
> Thank you
> Dan

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

Improvement to imports, what is a better way ?

[Dan Kolis]

This program has lots of files and each is well segregated for a concept.

the top of each as a heap of imports, all identical. Well the very top has some 
one of's

import os asos
import sys as   sys
import importlib as importlib
import datetime as  dt
from   tokenize import  maybe
import signal

from   tkinter import filedialog as fd
from   tkinter.messagebox importshowinfo
import tkinter as   tk  
from   tkinter import   ttk
from   tkinter import   font
 
from   PIL import Image as  pl
from   PIL import ImageTk   as  ii

# Imports part of this program 
import aboutTime as tt  # Time dates timestamps and the like
import avMedia as   av  # Audio and maybe video 'someday' well 
definitely lots of TTS text to speech
import basicSwitchboard as  sc  # First switchboard lurking. Kickoff to 
sequence viewers
import bestNotifications as bn  # Alerts, modals and notifications of many 
kinds including TK windows
import bitBlitting as   bb  # Help - # A setup window with basic facts 
written into files and the workspace
import configSetting as cs  # A setup window with basic facts written 
into files and the workspace
import devPeeks as  dp  # Developments peek assets code for adding 
features and debugging
import fileIo asio  # File reads, writes even some of the the 
pickle and unpickling
import forFun asff  # Staging area for uncertian features, also 
some dynamic code inclusion
import fractionScreens as   fs  # Common window pieces for TK windows in 
sequence viewers
import genomeDb as  gd  # IO to from databases external files gbk 
and others sure
import globalIdeas as   gi  # Common code for stuff used everywhere and 
definition of share DOT OBJECTS
import insertableEditors as ie  # Text editor(s) and support for that, some 
language issues managed too
import modalSimple as   mo  # Modal windows icp seq ssues, not used 
much currently
import osDependant as   od  # Operating system dependant calls and 
adaptions
import pickle aspk  # Packaging to and from file system for 
objects especially DOT OBJECTS
import screenBuilder1 assb  # Screen maker for TKinter and TKinter ++ 
windows
import selectViewer as  sv  # Window for picking which sequence viewers 
are enabled
import sequencesMaintain as sm  # Touching up temporal version issues of 
DOT OBJECTS
import sequencesOverview as so  # Working with sequences as macro facts, 
lists, see turn off etc
import serverHttp1 as   sh1 # Servers for HTTP - User Support
import serverHttp2 as   sh2 # Servers for HTTP - Protein viewing
import specialFour as   sf  # Classes and stuff for viewer four, a very 
complex viewer
import stagingNow assn  # More stabler new ideas getting tried out 
and moved in
import taskingFunction as   tf  # Tasker for real timeish event processor 
calls. Has two versions both work
import toastMaker astm  # Notifications
import transFormations as   xf  # Sequence transFormations from mother 
natures ideas like DNA and RNA
import unlovedMenus as  um  # Pretty rarely used ond fashioned menus. A 
while interface is in here that works
import wayOffline aswo  # Code not discarded but just studies, etc
import windowsX as  wx  # Windows Life ! X11 esp TK not MS Windoze 
...

So the file for instance fileIo.py has a duplicate of this.

I want to be able to call any code by using the two char prefix form anywhere. 
ex: io.get_Sequence(  'abc.fa' )

this seems weirdly disorderly. when it starts it sort of iterates down into 
objects, backs up etc.

What's the right way to do this ?

Thank you
Dan
-- 
https://mail.python.org/mailman/listinfo/python-list