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 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: 

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 = ggplot(df2, aes(label, 

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:

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

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

[Python-announce] python-oracledb 1.2.2

[Anthony Tuininga]

What is python-oracledb?

python-oracledb is a Python extension module that enables access to Oracle
Database for Python and conforms to the Python database API 2.0
specifications with a number of enhancements. This module is intended to
eventually replace cx_Oracle.

Where do I get it?

https://pypi.org/project/oracledb/1.2.2/

The easiest method to install/upgrade python-oracledb is via pip as in

python -m pip install oracledb --upgrade

What's new?

This release addresses a number of reported issues.

See the full release notes for all of the details:
https://python-oracledb.readthedocs.io/en/latest/release_notes.html#oracledb-1-2-2-january-2023

Please provide any feedback via GitHub issues: https://github.com/oracle/
python-oracledb/issues or discussions: https://github.com/oracle/python-
oracledb/discussions
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

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: A natural magnet for the craziest TKinter lovers out there

[Thomas Passin]

On 1/19/2023 10:21 AM, Dan Kolis wrote:

Hello !


Works fine on my work machine. (Ubuntu 20.04 / 32 G / 32 CPUS). Scalene 
(https://github.com/plasma-umass/scalene) shows it using 9 MB of memory.



I ran your test program here and it generates 25 windows on my machine,
and I can click "run" at least half a dozen times. I tried closing the
font windows before clicking run again, and also just leaving the
windows up and generating many more windows. 300 windows. No hangs here
at all. Fedora 35 with Mate Desktop on X11 with compositing enabled.



Thanks a lot These reports are very helpful !

I seemed to have 'fixed it' by changing one line, really. I used:

 # Do each thing
..for aWs in workWsL:
aWs.update()


TO:
 # Do each thing
..for aWs in workWsL:
aWs.update_idletasks()


I was going to suggest update_idletasks(), but I forgot to scan your 
code to see it it was already being done.



Dan says:
Thanks a lot ! This helps me visualise this is managed as a problem in a 
technical sense. I mean, there is always a requirement for real integration 
testing of all sorts for an attempt to release a program on a larger scale.

Now I know it works without stopping on 4 computers. Better then yesterday 
hugely.

  Thank you.

Regs
Daniel B. Kolis

my ref: nafl, 19 Jan 2023, 
https://groups.google.com/g/comp.lang.python/c/FNlXg0Od39o/m/9stiUtLSAQAJ










--
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: Python - working with xml/lxml/objectify/schemas, datatypes, and assignments

[Dan Kolis]

Editing text intended primarily for machine reading that involves metadata and 
lower level facts is a horror show.

I sort of worked for a company years ago and a smart ass suggested I was making 
labor for myself by doing changes to a scripting language for db users, maybe a 
few hours a week. He suggested I leave them to do it themselves in XML.

I tried it and the community went ape-shit angry. NONE of the people succeeded 
routinely at all.

Just because machine readable nomenclatures as well known and some s/w edits 
them, doesn't mean there suddenly not mostly mini computer programs.

 I suspect there isn't an easy way out, and probably the thing your making has 
to be 100% usably done before a maintenance tools can be created to make it 
easy, anyway.

Its the way it is, maybe,
Daniel B. Kolis
-- 
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: A natural magnet for the craziest TKinter lovers out there

[Dan Kolis]

Hello !

> Works fine on my work machine. (Ubuntu 20.04 / 32 G / 32 CPUS). Scalene 
> (https://github.com/plasma-umass/scalene) shows it using 9 MB of memory. 

> I ran your test program here and it generates 25 windows on my machine, 
> and I can click "run" at least half a dozen times. I tried closing the 
> font windows before clicking run again, and also just leaving the 
> windows up and generating many more windows. 300 windows. No hangs here 
> at all. Fedora 35 with Mate Desktop on X11 with compositing enabled. 


Thanks a lot These reports are very helpful !

I seemed to have 'fixed it' by changing one line, really. I used:

# Do each thing
..for aWs in workWsL:
aWs.update()


TO:
# Do each thing
..for aWs in workWsL:
aWs.update_idletasks()   


Dan says:
Thanks a lot ! This helps me visualise this is managed as a problem in a 
technical sense. I mean, there is always a requirement for real integration 
testing of all sorts for an attempt to release a program on a larger scale.

Now I know it works without stopping on 4 computers. Better then yesterday 
hugely.

 Thank you.

Regs
Daniel B. Kolis

my ref: nafl, 19 Jan 2023, 
https://groups.google.com/g/comp.lang.python/c/FNlXg0Od39o/m/9stiUtLSAQAJ








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

Re: A natural magnet for the craziest TKinter lovers out there

[Thomas Passin]

Works through 20 presses of the "go" button on a Linux Mint VM.  Because 
of limited RAM allocated for the VM, after some iterations the program 
slowed down because the VM had to start using swap memory.  But there 
did not seem to be any glitches or failures.


Python 3.9.5
Linux Mint 20 Ulyana /Cinnamon 3.07 GB
Linux kernel  5.4.0-137-generic
tk: 0.1.0


On 1/19/2023 10:06 AM, Thomas Passin wrote:
Works fine through 10 "go" button presses on my Windows 10 machine.  You 
might want to run pylint and pyflakes on it


On 1/19/2023 7:34 AM, Weatherby,Gerard wrote:
Works fine on my work machine. (Ubuntu 20.04 / 32 G / 32 CPUS). 
Scalene (https://github.com/plasma-umass/scalene) shows it using 9 MB 
of memory.


From: Python-list  
on behalf of Michael Torrie 

Date: Wednesday, January 18, 2023 at 8:58 PM
To: python-list@python.org 
Subject: Re: A natural magnet for the craziest TKinter lovers out there
*** Attention: This is an external email. Use caution responding, 
opening attachments or clicking on links. ***


On 1/18/23 18:01, Dan Kolis wrote:
Hangs after maybe between 4 and 50 screen rewrites. sometimes CTRL C 
under Ubuntu starts it up again. Click go rewrites al the fonts the 
thing can find in a few windows Repeated.




Not sure what you mean by "screen rewrites."

I ran your test program here and it generates 25 windows on my machine,
and I can click "run" at least half a dozen times. I tried closing the
font windows before clicking run again, and also just leaving the
windows up and generating many more windows.  300 windows. No hangs here
at all. Fedora 35 with Mate Desktop on X11 with compositing enabled.

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iGQaGdd9t2QPVQJDhyDTQmXgCwx4YG7m8jFbRd11dF1BweJHCd0wC4UyZUfQGQjqxeulMYagnDqInfA81A$




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

Re: A natural magnet for the craziest TKinter lovers out there

[Thomas Passin]

Works fine through 10 "go" button presses on my Windows 10 machine.  You 
might want to run pylint and pyflakes on it


On 1/19/2023 7:34 AM, Weatherby,Gerard wrote:

Works fine on my work machine. (Ubuntu 20.04 / 32 G / 32 CPUS). Scalene 
(https://github.com/plasma-umass/scalene) shows it using 9 MB of memory.

From: Python-list  on behalf of 
Michael Torrie 
Date: Wednesday, January 18, 2023 at 8:58 PM
To: python-list@python.org 
Subject: Re: A natural magnet for the craziest TKinter lovers out there
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On 1/18/23 18:01, Dan Kolis wrote:

Hangs after maybe between 4 and 50 screen rewrites. sometimes CTRL C under 
Ubuntu starts it up again. Click go rewrites al the fonts the thing can find in 
a few windows Repeated.



Not sure what you mean by "screen rewrites."

I ran your test program here and it generates 25 windows on my machine,
and I can click "run" at least half a dozen times. I tried closing the
font windows before clicking run again, and also just leaving the
windows up and generating many more windows.  300 windows. No hangs here
at all. Fedora 35 with Mate Desktop on X11 with compositing enabled.

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iGQaGdd9t2QPVQJDhyDTQmXgCwx4YG7m8jFbRd11dF1BweJHCd0wC4UyZUfQGQjqxeulMYagnDqInfA81A$


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

Re: A natural magnet for the craziest TKinter lovers out there

[Weatherby,Gerard]

Works fine on my work machine. (Ubuntu 20.04 / 32 G / 32 CPUS). Scalene 
(https://github.com/plasma-umass/scalene) shows it using 9 MB of memory.

From: Python-list  on 
behalf of Michael Torrie 
Date: Wednesday, January 18, 2023 at 8:58 PM
To: python-list@python.org 
Subject: Re: A natural magnet for the craziest TKinter lovers out there
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On 1/18/23 18:01, Dan Kolis wrote:
> Hangs after maybe between 4 and 50 screen rewrites. sometimes CTRL C under 
> Ubuntu starts it up again. Click go rewrites al the fonts the thing can find 
> in a few windows Repeated.
>

Not sure what you mean by "screen rewrites."

I ran your test program here and it generates 25 windows on my machine,
and I can click "run" at least half a dozen times. I tried closing the
font windows before clicking run again, and also just leaving the
windows up and generating many more windows.  300 windows. No hangs here
at all. Fedora 35 with Mate Desktop on X11 with compositing enabled.

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iGQaGdd9t2QPVQJDhyDTQmXgCwx4YG7m8jFbRd11dF1BweJHCd0wC4UyZUfQGQjqxeulMYagnDqInfA81A$
-- 
https://mail.python.org/mailman/listinfo/python-list