y 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...
otatochowder.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,
is 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 20
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 stallin
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
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
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
>
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.
Raymo
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 parti
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
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 VSC
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 odditie
Thank you
--
https://mail.python.org/mailman/listinfo/python-list
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. Pyt
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 ever
> 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
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
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.
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 t
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 wr
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 di
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, i
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
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
24 matches
Mail list logo
