when it starts it sort of iterates down into objects, backs up etc.
So the file for instance fileIo.py has a duplicate of this.
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.
import os as                       os
import sys as                      sys
import importlib as                importlib
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
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.
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.
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 don't think you've described this. I don't know what you mean here.
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.
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 guess I don't full understand what bothers me about the repetition of the imports so much.
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 ?"
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 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 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.
dn <PythonList@DancesWithMice.info> writes:He then goes on to say he uses 90-ish, IIRC: he tries to stay under
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
Op 19/01/2023 om 11:32 schreef Stefan Ram:[snip]
dn <PythonList@DancesWithMice.info> writes:
The longer an identifier, the more it 'pushes' code over to the rightor >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.
Well, it's an art, not a science [...]
# 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 ....'
)
The PEP-8 rules are good, but they can't cover all cases perfectly.
PEP 8 even covers that: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.)
On 2023-01-19 at 12:59:21 -0500,
Thomas Passin <list1@tompassin.net> 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.)
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'.
Well, it's an art, not a science [...]
# 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 ....'
)
The PEP-8 rules are good, but they can't cover all cases perfectly.
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 <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of 2QdxY4RzWzUUiLuE@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 <list1@tompassin.net> 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
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:with a close parentheses followed by a plus sign.
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
The geom_point() function that follows can be empty and then would askitems.
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
The example chose to include parens around everything so the plusthat.
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
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
<python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of 2QdxY4RzWzUUiLuE@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 <list1@tompassin.net> 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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:36:11 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,570 |