Re: HTTP server benchmarking/load testing in Python

[Thomas Passin]

On 1/26/2023 6:39 PM, Barry wrote:




On 26 Jan 2023, at 17:32, Thomas Passin  wrote:

On 1/26/2023 11:41 AM, Chris Angelico wrote:

On Fri, 27 Jan 2023 at 03:34, Thomas Passin  wrote:
A nice theory but nothing to do with the real world.  I've had a number
of laptops that overheat (or would, if I let test program continue)
running this test program.

Define "overheat". If all you're saying is "the fan began to whine and
I got annoyed so I shut off the program", that is absolutely NOT
overheating.


CPU core temperatures up to 95 deg C and rising rapidly, as reported by a 
number of utilities including NZXT and CoreTemp.  Max junction temperature is 
given as 100 deg C, and I don't want to risk reducing the lifetime of my  CPU.


Silicon junctions melt something like 400C ish not 100C.
The max you see is the operating temp of the CPU.


Of course I know the junction isn't going to melt at 100 deg C.  We're 
not talking low temperature solder here!



For intel CPU if you go beyond what the slow clocking can deal with the CPU 
turns itself off to prevent damage.

Intel did this to stop people asking for replacement parts when there cooling 
was at fault.

Barry



Maybe five or ten minutes at or above 100 deg C every few months might not make 
a noticeable lifetime difference, who knows?  I don't want to make a habit of 
it.  I wouldn't drive my car very long with a low oil pressure warning active, 
either.
--
https://mail.python.org/mailman/listinfo/python-list





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

Re: HTTP server benchmarking/load testing in Python

[Thomas Passin]

On 1/26/2023 10:32 PM, Chris Angelico wrote:

On Fri, 27 Jan 2023 at 14:21, Thomas Passin  wrote:

2. "What is Tjunction max temperature?"
Tjunction max is the maximum thermal junction temperature that a
processor will allow prior to using internal thermal control mechanisms
to reduce power and limit temperature. Activation of the processor's
thermal control system may cause performance loss as the processor
typically reduces frequency and power to prevent overheating. The
maximum junction temperature limit varies per product and usually is
between 100°C-110°C."

https://www.intel.com/content/www/us/en/support/articles/05597/processors.html

The utilities I used always stated a 100 deg limit for Tj.



Yeah, so "maximum" is "before performance loss", not "before damage".


Yeah, so a dozen years ago, when I first noticed the matter, most 
computers didn't have throttling and power reduction, so I got 
sensitized to it.  Better safe than sorry.  Airliners have safeguards 
against stalling, but it's a lot better not to try to stall them anyway 
(speaking as a (non-airline) pilot).


Let's give this a rest, shall we?

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

Re: HTTP server benchmarking/load testing in Python

[Chris Angelico]

On Fri, 27 Jan 2023 at 14:21, Thomas Passin  wrote:
> 2. "What is Tjunction max temperature?"
> Tjunction max is the maximum thermal junction temperature that a
> processor will allow prior to using internal thermal control mechanisms
> to reduce power and limit temperature. Activation of the processor's
> thermal control system may cause performance loss as the processor
> typically reduces frequency and power to prevent overheating. The
> maximum junction temperature limit varies per product and usually is
> between 100°C-110°C."
>
> https://www.intel.com/content/www/us/en/support/articles/05597/processors.html
>
> The utilities I used always stated a 100 deg limit for Tj.
>

Yeah, so "maximum" is "before performance loss", not "before damage".

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

Re: HTTP server benchmarking/load testing in Python

[Thomas Passin]

On 1/26/2023 5:00 PM, Chris Angelico wrote:

On Fri, 27 Jan 2023 at 06:54, Thomas Passin  wrote:

Did you get a warning, or did you just decide to stop the test?


(At least) one of the utilities, I forget which one, did show the
temperature in a danger zone.


I'm very curious as to which utility, and on what basis it called it
"danger". Notably, whether there's any sort of actual manufacturer
threshold that that was based on.


1. we're talking maybe a dozen years ago, I don't remember every detail 
about wordings.  Coretemp e.g., gives clear warnings (though at what I 
think are lower temperatures than necessary).


2. "What is Tjunction max temperature?"
Tjunction max is the maximum thermal junction temperature that a 
processor will allow prior to using internal thermal control mechanisms 
to reduce power and limit temperature. Activation of the processor's 
thermal control system may cause performance loss as the processor 
typically reduces frequency and power to prevent overheating. The 
maximum junction temperature limit varies per product and usually is 
between 100°C-110°C."


https://www.intel.com/content/www/us/en/support/articles/05597/processors.html

The utilities I used always stated a 100 deg limit for Tj.

3. "Is it bad if my processor frequently approaches or reaches its 
maximum temperature?


Not necessarily. Many Intel® processors make use of Intel® Turbo Boost 
Technology, which allows them to operate at very high frequency for a 
short amount of time. When the processor is operating at or near its 
maximum frequency it's possible for the temperature to climb very 
rapidly and quickly reach its maximum temperature. In sustained 
workloads, it's possible the processor will operate at or near its 
maximum temperature limit. Being at maximum temperature while running a 
workload isn't necessarily cause for concern. Intel processors 
constantly monitor their temperature and can very rapidly adjust their 
frequency and power consumption to prevent overheating and damage."


(same source)

But automatic throttling wasn't common back when I first noticed the 
heating issue.



Personally? Very dubious. Your entire premise is "five degrees MUST be
a problem", without any visible basis.


Bridges are built with 150 - 200 % strength margin.  This doesn't mean 
you should deliberately overload one.


Heat is the enemy of electronics - a very old lesson.  Tj =~ 100 deg C 
for CPUs, a familiar figure.


My premise, to use your word, is not what you say.  It is to avoid 
excessive heat if at all possible, and if the manufacturer says the max 
junction temperature is 100 deg, I'm going to avoid approaching 100 deg 
if possible - or to minimize the stay there.  Most chemical effects are 
exponentially sensitive to temperature and problems with semiconductors 
are likely to be chemical - remember, e.g., the purple plague? A 
chemical problem.


So yes, checking with HWiNFO, my current system is throttling and power 
limiting during this particular test.  That's good.  And I'm still going 
to stay away from the highest temperatures when possible.


Nuff said!

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

RE: RE: bool and int

[avi.e.gross]

[Dino has a deliberately invalid email address so sending him anything
privately is not an option.]

Dino,

I would agree with you that for some purposes, you do NOT need to dig deep
into a language to get fairly routine things done. You can often borrow
ideas and code from an online search and hopefully cobble "a" solution
together that works well enough. Of course it may suddenly fall apart. An
example is code written that assumes 4 specific files exist in the current
directory and unconditionally reads them and does stuff and eventually
overwrites some other file with new data. OOPS, what does the program do it
one or more files do not exist in the current directory under those exact
names? Does it check if they exist and exit gracefully, or start throwing
error messages as the code blindly proceeds on trying to change variables
that were never created and so on, and then end with perhaps an emptied file
and ruin lots of things?

Too many examples you get from the internet are a bit like that. They often
just tell you how to do something specific but leave out lots of details
that are a good idea for many kinds of code. And some adjustments you make
may break things and produce a result you trust but that is actually wrong. 

So if you find something you don't like about the language, guess what. You
have very little standing if you never learned much more than what it took
to copy some code.  You are likely to be told things by others ranging from
suggesting you need to do it another way or that the language is doing
exactly what was designed and suggestions you go back to school and get a
proper education and then the answer may be obvious.

It truly does NOT matter what YOU think should happen unless you point to
documentation that says something else should have happened.

I will skip a lengthier reply but am thinking how some languages use a
boxing/unboxing approach to wrap native "objects" like an integer. In many
cases, your program is allowed to treat this as either a wrapped object or
unboxed as needed and the compiler or interpreter keeps making changes
behind the scenes so you see it as needed. In a sense, Booleans are a
restricted form of integer and are viewed one of several ways. Python goes
many steps further and has a concept of truthy that maps practically
anything to True or False.

The bottom line is not that Python or any language is wrong or right or
great or horrible. It is that based on your own admission, you have not
taken steps to understand more than you have to and thus are in a weak
position to argue anything. Not because any of us are smarter in some sense,
but because some of us do study more intensively and come ready to
re-evaluate our ideas when we encounter others. What Python does in the
situation discussed is pretty much what an assortment of languages include
many C-based ones do. If it happens that your background is limited, fine.
Many of us here have been exposed to the ideas in 5 or a dozen or literally
hundreds of languages and variants and are well aware that some languages
treat Booleans differently. But note we are posting on this forum so we
generally don't find it that objectionable the way Python has chosen. 

We welcome well-intentioned discussions and the question is not at all
stupid. But our answers may not be being seen as reasonable and that can be
of some concern. The answer remains that the language was designed this way
and many are happy with the design. Interestingly, I wonder if anyone has
designed an alternate object type that can be used mostly in place of
Booleans but which imposes changes and restrictions so trying to add a
Boolean to an integer, or vice versa, results in an error. Python is
flexible enough to do that and perhaps there already is a module out there
...


-Original Message-
From: Python-list  On
Behalf Of Dino
Sent: Thursday, January 26, 2023 9:26 AM
To: python-list@python.org
Subject: Re: RE: bool and int


Wow. That was quite a message and an interesting read. Tempted to go deep
and say what I agree and what I disagree with, but there are two
issues: 1) time 2) I will soon be at a disadvantage discussing with people
(you or others) who know more than me (which doesn't make them right
necessarily, but certainly they'll have the upper-hand in a discussion).

Personally, in the first part of my career I got into the habit of learning
things fast, sometimes superficially I confess, and then get stuff done
hopefully within time and budget. Not the recommended approach if you need
to build software for a nuclear plant. An OK approach (within reason) if you
build websites or custom solutions for this or that organization and the
budget is what it is. After all, technology moves sooo fast, and what we
learn in detail today is bound to be old and possibly useless 5 years down
the road.

Also, I argue that there is value in having familiarity with lots of
different technologies (front-end and back-end) and knowing (or at 

Re: HTTP server benchmarking/load testing in Python

[Barry]

> On 26 Jan 2023, at 17:32, Thomas Passin  wrote:
> 
> On 1/26/2023 11:41 AM, Chris Angelico wrote:
>>> On Fri, 27 Jan 2023 at 03:34, Thomas Passin  wrote:
>>> A nice theory but nothing to do with the real world.  I've had a number
>>> of laptops that overheat (or would, if I let test program continue)
>>> running this test program.
>> Define "overheat". If all you're saying is "the fan began to whine and
>> I got annoyed so I shut off the program", that is absolutely NOT
>> overheating. 
> 
> CPU core temperatures up to 95 deg C and rising rapidly, as reported by a 
> number of utilities including NZXT and CoreTemp.  Max junction temperature is 
> given as 100 deg C, and I don't want to risk reducing the lifetime of my  CPU.

Silicon junctions melt something like 400C ish not 100C.
The max you see is the operating temp of the CPU.

For intel CPU if you go beyond what the slow clocking can deal with the CPU 
turns itself off to prevent damage.

Intel did this to stop people asking for replacement parts when there cooling 
was at fault.

Barry

> 
> Maybe five or ten minutes at or above 100 deg C every few months might not 
> make a noticeable lifetime difference, who knows?  I don't want to make a 
> habit of it.  I wouldn't drive my car very long with a low oil pressure 
> warning active, either.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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

Re: Module use of python3_d.dll conflicts with this version of Python

[Eryk Sun]

On 1/26/23, Olivier B.  wrote:
>
> Does someone know why it would have been chosen to be different for
> debug builds?

It's assumed that a debug build would normally link with
"pythonXY_d.dll". Maybe it should be more defensive. Refer to the
following setup in PC/pyconfig.h:

/* For an MSVC DLL, we can nominate the .lib files used by extensions */
#ifdef MS_COREDLL
#   if !defined(Py_BUILD_CORE) && !defined(Py_BUILD_CORE_BUILTIN)
/* not building the core - must be an ext */
#   if defined(_MSC_VER)
/* So MSVC users need not specify the .lib
file in their Makefile (other compilers are
generally taken care of by distutils.) */
#   if defined(_DEBUG)
#   pragma comment(lib,"python312_d.lib")
#   elif defined(Py_LIMITED_API)
#   pragma comment(lib,"python3.lib")
#   else
#   pragma comment(lib,"python312.lib")
#   endif /* _DEBUG */
#   endif /* _MSC_VER */
#   endif /* Py_BUILD_CORE */
#endif /* MS_COREDLL */
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python not found

[Eryk Sun]

On 1/26/23, Bela Gesztesi  wrote:
>
> C:\DJI>py comm_og_service_tool.py WM231 --port COM3 GimbalCalib JointCoarse
>
> Python was not found; run without arguments to install from the Microsoft
> Store, or disable this shortcut from Settings > Manage App Execution
> Aliases.

Do what it's telling you to do. Either install the app version of
Python, or disable the "python.exe" and "python3.exe"  app aliases.

The "python.exe" and "python3.exe" app aliases that are distributed
with Windows run a "PythonRedirector" app that just opens the
Microsoft Store to download the latest version of the app version of
Python. When run with command-line arguments, they print the message
that's quoted above.

What's happening here is that the py launcher reads a shebang line
from "comm_og_service_tool.py" of the form "#!/usr/bin/env python3".
It thus searches PATH for "python3.exe" and finds the app alias. We
should probably update the launcher to ignore an alias to the
"PythonRedirector" app.
-- 
https://mail.python.org/mailman/listinfo/python-list

Python not found

[Bela Gesztesi]

I have downloaded python, checking path installation and I receive the 
following:



C:\DJI>py comm_og_service_tool.py WM231 --port COM3 GimbalCalib JointCoarse

Python was not found; run without arguments to install from the Microsoft 
Store, or disable this shortcut from Settings > Manage App Execution Aliases.



Please offer any suggestions,

Thank you,

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

Re: bool and int

[Chris Angelico]

On Fri, 27 Jan 2023 at 06:32, Dino  wrote:
>
> On 1/25/2023 5:42 PM, Chris Angelico wrote:
>
> >
> > Try this (or its equivalent) in as many languages as possible:
> >
> > x = (1 > 2)
> > x == 0
> >
> > You'll find that x (which has effectively been set to False, or its
> > equivalent in any language) will be equal to zero in a very large
> > number of languages. Thus, to an experienced programmer, it would
> > actually be quite the opposite: having it NOT be a number would be the
> > surprising thing!
>
> I thought I had already responded to this, but I can't see it. Weird.
>
> Anyway, straight out of the Chrome DevTools console:
> 
> x = (1>2)
> false
>
> x == 0
> true
>
> typeof(x)
> 'boolean'
>
> typeof(0)
> 'number'
>
> typeof(x) == 'number'
> false
>
> So, you are technically correct, but you can see that JavaScript - which
> comes with many gotchas - does not offer this particular one.
>

That's not what I said, though! What you did in JS was the equivalent of this:

>>> type(True) == type(1)
False

which isn't the same as an isinstance check. Instead, try *exactly
what I said*. You'll find that false is equal to zero and true is
equal to one, just like it is in Python.

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

Re: HTTP server benchmarking/load testing in Python

[Chris Angelico]

On Fri, 27 Jan 2023 at 06:54, Thomas Passin  wrote:
> > Did you get a warning, or did you just decide to stop the test?
>
> (At least) one of the utilities, I forget which one, did show the
> temperature in a danger zone.

I'm very curious as to which utility, and on what basis it called it
"danger". Notably, whether there's any sort of actual manufacturer
threshold that that was based on.

Personally? Very dubious. Your entire premise is "five degrees MUST be
a problem", without any visible basis.

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

Re: bool and int

[Ben Bacarisse]

Chris Angelico  writes:

> On Thu, 26 Jan 2023 at 08:19, Dino  wrote:
>>
>> On 1/23/2023 11:22 PM, Dino wrote:
>> >  >>> b = True
>> >  >>> isinstance(b,bool)
>> > True
>> >  >>> isinstance(b,int)
>> > True
>> >  >>>
>>
>> ok, I read everything you guys wrote. Everyone's got their reasons
>> obviously, but allow me to observe that there's also something called
>> "principle of least surprise".
>>
>> In my case, it took me some time to figure out where a nasty bug was
>> hidden. Letting a bool be a int is quite a gotcha, no matter how hard
>> the benevolent dictator tries to convince me otherwise!
>>
>
> Try this (or its equivalent) in as many languages as possible:
>
> x = (1 > 2)
> x == 0
>
> You'll find that x (which has effectively been set to False, or its
> equivalent in any language) will be equal to zero in a very large
> number of languages. Thus, to an experienced programmer, it would
> actually be quite the opposite: having it NOT be a number would be the
> surprising thing!

I think the programmer's experience would have to have been rather
narrow to be surprised by x not being treated as a number.  I started
with Fortran, Lisp, Pascal and two variants of Algol so I started out
un-surprised by Boolean being a non-arithmetic type.  To be surprised by
x (above) /not/ being treated as a number, an experienced programmer
would have had to have avoided a lot of strictly typed languages.

I've just tried Scheme, Haskell, Common Lisp, Ada, Algol-68, go, ML,
Rust, Ruby, Java, Lua, Prolog and Fortran and they all either say "no
way!" or give false for x == 0.  Of course these are not random choices,
but it shows that Python's design is very far from universal.

But then this is not a numbers game, anyway.  A programmer need only to
have used one or two languages that are rather more strict about types
to find such a thing unsurprising in future.

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

Re: bool and int

[2QdxY4RzWzUUiLuE]

On 2023-01-26 at 12:12:30 -0500,
Dino  wrote:

> On 1/25/2023 5:42 PM, Chris Angelico wrote:
> 
> > 
> > Try this (or its equivalent) in as many languages as possible:
> > 
> > x = (1 > 2)
> > x == 0
> > 
> > You'll find that x (which has effectively been set to False, or its
> > equivalent in any language) will be equal to zero in a very large
> > number of languages. Thus, to an experienced programmer, it would
> > actually be quite the opposite: having it NOT be a number would be the
> > surprising thing!
> 
> I thought I had already responded to this, but I can't see it. Weird.
> 
> Anyway, straight out of the Chrome DevTools console:
> 
> x = (1>2)
> false
> 
> x == 0
> true
> 
> typeof(x)
> 'boolean'
> 
> typeof(0)
> 'number'
> 
> typeof(x) == 'number'
> false
> 
> So, you are technically correct, but you can see that JavaScript - which
> comes with many gotchas - does not offer this particular one.

When you start a new language, try to start from the beginning.  Yes,
you know other languages, to varying degrees, and the language you are
learning is very likely similar, at least superficially, in some way or
another, to one of those other languages.  Use that existing knowledge
to the extent that it is useful; be prepared to forget everything you
know.

Python's choice of type hierarchy is not at all uncommon, and it's only
a gotcha if you come in with a predetermined idea of how certain things
"should" work.  I've already noted that writing FORTRAN in any language
is a meme.

For a completely different take on booleans, take a look at Python's
logical "and" and "or" operators (*not* the arithmetic "|" and "&"
operators), which only sometimes return an actual boolean value.  Then
compare them to the "any" and "all" builtins, which came along much
later.  Idiomatic Python uses the right tool for the job *in Python*,
whether or not that same tool is or isn;'t the right tool for the same
job in some other language.

Python is like Lisp in that it (Python) has strong dynamic typing.  From
my Common Lisp REPL:

CL-USER> (let ((x (< 1 2)))
   (cons x (type-of x)))
(T . BOOLEAN)

CL-USER> (let ((x (> 1 2)))
   (cons x (type-of x)))
(NIL . NULL)

In English, the canonical "true" value in Lisp is T, and its type is
BOOLEAN.  Likewise, the canonical "false" value in Lisp is NIL, and its
type is NULL.  Out of the box, Lisp will not convert T or NIL to a
number.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: HTTP server benchmarking/load testing in Python

[Thomas Passin]

On 1/26/2023 12:57 PM, Chris Angelico wrote:

On Fri, 27 Jan 2023 at 04:31, Thomas Passin  wrote:


On 1/26/2023 11:41 AM, Chris Angelico wrote:

On Fri, 27 Jan 2023 at 03:34, Thomas Passin  wrote:

A nice theory but nothing to do with the real world.  I've had a number
of laptops that overheat (or would, if I let test program continue)
running this test program.


Define "overheat". If all you're saying is "the fan began to whine and
I got annoyed so I shut off the program", that is absolutely NOT
overheating.


CPU core temperatures up to 95 deg C and rising rapidly, as reported by
a number of utilities including NZXT and CoreTemp.  Max junction
temperature is given as 100 deg C, and I don't want to risk reducing the
lifetime of my  CPU.

Maybe five or ten minutes at or above 100 deg C every few months might
not make a noticeable lifetime difference, who knows?  I don't want to
make a habit of it.  I wouldn't drive my car very long with a low oil
pressure warning active, either.


Did you get a warning, or did you just decide to stop the test?


(At least) one of the utilities, I forget which one, did show the 
temperature in a danger zone.



Did you continue the test and see what would happen?


No, why would I?  Would you go up to the edge of a cliff, past the 
warning signs, and when the ground started to crumble take another step 
to see if it would really collapse?



Did you, when the temperature got up to 95°, check what the CPU's
clock frequency was? The easiest way to recognize thermal throttling
is a reduction in frequency while at 100% utilization.


No, there was no point.  Maybe it would have throttled, maybe no damage 
would have occurred.  But doing so would not have accomplished anything, 
since I already had the throughput numbers I needed and the purpose of 
the test was not to see how hard I could drive the system before 
hardware failure.  I'll leave that to Tom's Hardware or some gamers' site.



Or did you just assume that, with a mere five degree buffer and your
own personal analysis, that the CPU was just seconds away from total
destruction?


To quote myself from my last message:

"Maybe five or ten minutes at or above 100 deg C every few months might 
not make a noticeable lifetime difference, who knows?  I don't want to 
make a habit of it.  I wouldn't drive my car very long with a low oil 
pressure warning active, either."


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

Re: HTTP server benchmarking/load testing in Python

[Chris Angelico]

On Fri, 27 Jan 2023 at 04:31, Thomas Passin  wrote:
>
> On 1/26/2023 11:41 AM, Chris Angelico wrote:
> > On Fri, 27 Jan 2023 at 03:34, Thomas Passin  wrote:
> >> A nice theory but nothing to do with the real world.  I've had a number
> >> of laptops that overheat (or would, if I let test program continue)
> >> running this test program.
> >
> > Define "overheat". If all you're saying is "the fan began to whine and
> > I got annoyed so I shut off the program", that is absolutely NOT
> > overheating.
>
> CPU core temperatures up to 95 deg C and rising rapidly, as reported by
> a number of utilities including NZXT and CoreTemp.  Max junction
> temperature is given as 100 deg C, and I don't want to risk reducing the
> lifetime of my  CPU.
>
> Maybe five or ten minutes at or above 100 deg C every few months might
> not make a noticeable lifetime difference, who knows?  I don't want to
> make a habit of it.  I wouldn't drive my car very long with a low oil
> pressure warning active, either.

Did you get a warning, or did you just decide to stop the test?

Did you continue the test and see what would happen?

Did you, when the temperature got up to 95°, check what the CPU's
clock frequency was? The easiest way to recognize thermal throttling
is a reduction in frequency while at 100% utilization.

Or did you just assume that, with a mere five degree buffer and your
own personal analysis, that the CPU was just seconds away from total
destruction?

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

Re: bool and int

[Dino]

On 1/25/2023 5:42 PM, Chris Angelico wrote:



Try this (or its equivalent) in as many languages as possible:

x = (1 > 2)
x == 0

You'll find that x (which has effectively been set to False, or its
equivalent in any language) will be equal to zero in a very large
number of languages. Thus, to an experienced programmer, it would
actually be quite the opposite: having it NOT be a number would be the
surprising thing!


I thought I had already responded to this, but I can't see it. Weird.

Anyway, straight out of the Chrome DevTools console:

x = (1>2)
false

x == 0
true

typeof(x)
'boolean'

typeof(0)
'number'

typeof(x) == 'number'
false

So, you are technically correct, but you can see that JavaScript - which 
comes with many gotchas - does not offer this particular one.



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

Re: HTTP server benchmarking/load testing in Python

[Thomas Passin]

On 1/26/2023 11:41 AM, Chris Angelico wrote:

On Fri, 27 Jan 2023 at 03:34, Thomas Passin  wrote:

A nice theory but nothing to do with the real world.  I've had a number
of laptops that overheat (or would, if I let test program continue)
running this test program.


Define "overheat". If all you're saying is "the fan began to whine and
I got annoyed so I shut off the program", that is absolutely NOT
overheating. 


CPU core temperatures up to 95 deg C and rising rapidly, as reported by 
a number of utilities including NZXT and CoreTemp.  Max junction 
temperature is given as 100 deg C, and I don't want to risk reducing the 
lifetime of my  CPU.


Maybe five or ten minutes at or above 100 deg C every few months might 
not make a noticeable lifetime difference, who knows?  I don't want to 
make a habit of it.  I wouldn't drive my car very long with a low oil 
pressure warning active, either.

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

Re: asyncio questions

[Dieter Maurer]

Frank Millman wrote at 2023-1-26 12:12 +0200:
>I have written a simple HTTP server using asyncio. It works, but I don't
>always understand how it works, so I was pleased that Python 3.11
>introduced some new high-level concepts that hide the gory details. I
>want to refactor my code to use these concepts, but I am not finding it
>easy.
>
>In simple terms my main loop looked like this -
>
>     loop = asyncio.get_event_loop()
>     server = loop.run_until_complete(
>     asyncio.start_server(handle_client, host, port))
>     loop.run_until_complete(setup_companies())
>     session_check = asyncio.ensure_future(
>     check_sessions())  # start background task
>     print('Press Ctrl+C to stop')
>     try:
>     loop.run_forever()
>     except KeyboardInterrupt:
>     print()
>     finally:
>     session_check.cancel()  # tell session_check to stop running
>     loop.run_until_complete(asyncio.wait([session_check]))
>     server.close()
>     loop.stop()

Why does your code uses several `loop.run*` calls?

In fact, I would define a single coroutine and run that
with `asyncio.run`.
This way, the coroutine can use all `asyncio` features,
including `loop.create_task`.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: HTTP server benchmarking/load testing in Python

[Grant Edwards]

On 2023-01-26, Thomas Passin  wrote:
> On 1/26/2023 11:02 AM, Grant Edwards wrote:
>
>[...]
>
>> A properly designed laptop with a non-broken OS will not overheat
>> regardless of the computing load you throw at it. The fan might get
>> annoying loud, but if it overheats either your hardware or OS needs
>> to be fixed.
>
> A nice theory but nothing to do with the real world.  I've had a number 
> of laptops that overheat (or would, if I let test program continue) 
> running this test program.

You mean they actually fail/crash?

Or they just throttle the fans up and the CPU down to keep the core
temperature within limits?

--
Grant



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

Re: HTTP server benchmarking/load testing in Python

[Chris Angelico]

On Fri, 27 Jan 2023 at 03:34, Thomas Passin  wrote:
> A nice theory but nothing to do with the real world.  I've had a number
> of laptops that overheat (or would, if I let test program continue)
> running this test program.

Define "overheat". If all you're saying is "the fan began to whine and
I got annoyed so I shut off the program", that is absolutely NOT
overheating. I would accept "the CPU thermally throttled to the point
where the test was non-indicative" as a form of overheating, though
then the warning should be "be aware that, if your web server is
CPU-limited, this test may result in hard-to-interpret numbers due to
requests per second varying with the change in CPU temperature", which
isn't nearly as punchy.

But unless you have a system where the heat sink isn't attached to the
CPU properly, I'd be very surprised if you were able to actually
damage your CPU this way. Maybe you could reduce the lifetime that way
(the same way that crypto mining can shorten the lifespan of a GPU),
but it shouldn't cause any sort of immediate damage. Even on a laptop.

Feel free to prove me wrong, though.

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

Re: bool and int

[Chris Angelico]

On Fri, 27 Jan 2023 at 03:31, rbowman  wrote:
>
> On Thu, 26 Jan 2023 04:10:30 +1100, Chris Angelico wrote:
>
>
> > BASIC was like that too, although it (at least, the versions I used in
> > my childhood) didn't have "True" and "False", you just got the actual
> > values -1 and 0. They were the other way around compared to what you're
> > saying here though.
>
> I've see header files from people with boolean envy that are something
> like
>
> #define FALSE  0
> #define TRUE ~FALSE
>

Yeah, that's the same logic that BASIC uses: false is zero, and true
is the all-ones integer (which, interpreted as a two's complement
signed number, is -1).

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

Re: RE: bool and int

[Dino]

Wow. That was quite a message and an interesting read. Tempted to go 
deep and say what I agree and what I disagree with, but there are two 
issues: 1) time 2) I will soon be at a disadvantage discussing with 
people (you or others) who know more than me (which doesn't make them 
right necessarily, but certainly they'll have the upper-hand in a 
discussion).


Personally, in the first part of my career I got into the habit of 
learning things fast, sometimes superficially I confess, and then get 
stuff done hopefully within time and budget. Not the recommended 
approach if you need to build software for a nuclear plant. An OK 
approach (within reason) if you build websites or custom solutions for 
this or that organization and the budget is what it is. After all, 
technology moves sooo fast, and what we learn in detail today is bound 
to be old and possibly useless 5 years down the road.


Also, I argue that there is value in having familiarity with lots of 
different technologies (front-end and back-end) and knowing (or at 
lease, having a sense) of how they can all be made play together with an 
appreciation of the different challenges and benefits that each domain 
offers.


Anyway, everything is equivalent to a Turing machine and IA will screw 
everyone, including programmers, eventually.


Thanks again and have a great day

Dino

On 1/25/2023 9:14 PM, avi.e.gr...@gmail.com wrote:

Dino,

There is no such things as a "principle of least surprise" or if you insist
there is, I can nominate many more such "rules" such as "the principle of
get out of my way and let me do what I want!"

Computer languages with too many rules are sometimes next to unusable in
practical situations.

I am neither defending or attacking choices Python or other languages have
made. I merely observe and agree to use languages carefully and as
documented.


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

Re: HTTP server benchmarking/load testing in Python

[Thomas Passin]

On 1/26/2023 11:02 AM, Grant Edwards wrote:

On 2023-01-26, Thomas Passin  wrote:

On 1/25/2023 7:38 PM, Peter J. Holzer wrote:

On 2023-01-25 16:30:56 -0500, Thomas Passin wrote:

Great!  Don't forget what I said about potential overheating if you
hit the server with as many requests as it can handle.


Frankly, if you can overheat a server by hitting it with HTTP requests,
get better hardware and/or put it into a place with better airflow.



Frankly, if you have a server-grade machine then well and good but if
you are running a nice quiet consumer grade laptop - my development
machine - you need to be careful.


A properly designed laptop with a non-broken OS will not overheat
regardless of the computing load you throw at it. The fan might get
annoying loud, but if it overheats either your hardware or OS needs
to be fixed.


A nice theory but nothing to do with the real world.  I've had a number 
of laptops that overheat (or would, if I let test program continue) 
running this test program.  They have been different brands, different 
CPUs, different levels of noisy fans.  I don't know how I would find one 
of your "properly designed laptops with a non-broken OS", or what could 
be done to fix it.  Maybe a high-end gaming machine... which I don't 
wish to invest in or hear the fan noise from.


Anyway, the point was to warn other people - who probably also wouldn't 
have a "properly designed laptop with a non-broken OS" - that they 
should keep an eye on their CPU core temperatures.  In my experience, 
that's a real concern, whether or not it "should not" be an issue.



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

Re: HTTP server benchmarking/load testing in Python

[Dino]

On 1/25/2023 4:30 PM, Thomas Passin wrote:

On 1/25/2023 3:29 PM, Dino wrote:
Great!  Don't forget what I said about potential overheating if you hit 
the server with as many requests as it can handle.


Noted. Thank you.




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

Re: bool and int

[rbowman]

On Thu, 26 Jan 2023 04:10:30 +1100, Chris Angelico wrote:


> BASIC was like that too, although it (at least, the versions I used in
> my childhood) didn't have "True" and "False", you just got the actual
> values -1 and 0. They were the other way around compared to what you're
> saying here though.

I've see header files from people with boolean envy that are something 
like

#define FALSE  0
#define TRUE ~FALSE

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

Module use of python3_d.dll conflicts with this version of Python

[Olivier B.]

Hi,I am in the process of trying to make my code (an c++ executable
and swig modules using the Python C API) lose the dependency to python
3.7, to be compatible with all Python 3.2+

I tried linking to python.lib instead of python37.lib. As i am still
using a few things that are not in the limited API, my binaries now
have a dependency to python3.dll for the base stuff, and pyhton37.dll
for the few symbols that are not backwards compatible.

In release, that does not seem to bring issues. In debug (debug build
of my program that uses python debug build) however, when the process
is importing the swig python/c++ module, i get a
"Module use of python3_d.dll conflicts with this version of Python". I
checked that i am properly loading the python3_d.dll of my python37,
and python python37_d.dll too

Looking in dynload_win.c of python sources where the message is
triggered, indeed it is comparing in py case python37_d.dll to
python3_d.dll.
And i guess, in release, it works because in GetPythonModule(), there' is

#ifndef _DEBUG
/* In a release version, don't claim that python3.dll is
a Python DLL. */
if (strcmp(import_name, "python3.dll") == 0) {
import_data += 20;
continue;
}
#endif

Does someone know why it would have been chosen to be different for
debug builds?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: HTTP server benchmarking/load testing in Python

[Benjamin Schollnick]

> On Jan 26, 2023, at 11:02 AM, Grant Edwards  wrote:
> 
> On 2023-01-26, Thomas Passin  wrote:
>> On 1/25/2023 7:38 PM, Peter J. Holzer wrote:
>>> On 2023-01-25 16:30:56 -0500, Thomas Passin wrote:
 Great!  Don't forget what I said about potential overheating if you
 hit the server with as many requests as it can handle.
>>> 
>>> Frankly, if you can overheat a server by hitting it with HTTP requests,
>>> get better hardware and/or put it into a place with better airflow.
>>> 
>> 
>> Frankly, if you have a server-grade machine then well and good but if 
>> you are running a nice quiet consumer grade laptop - my development 
>> machine - you need to be careful.
> 
> A properly designed laptop with a non-broken OS will not overheat
> regardless of the computing load you throw at it. The fan might get
> annoying loud, but if it overheats either your hardware or OS needs
> to be fixed.

Exactly.  

But what he might be thinking about is Thermal Throttling, which I keep seeing 
people attribute
to overheating….  

Overheating is not thermal throttling, it’s the OS and CPU protecting 
themselves from overheating.
Usually because the manufacturer didn’t add enough cooling to keep the system 
cool enough with a continuous load.  (Which to be honest, almost no laptop 
designers do, because they assuming you are going to be having a spiky load 
instead…  

- Benjamin

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

Re: asyncio questions

[Grant Edwards]

On 2023-01-26, Frank Millman  wrote:

> I have written a simple HTTP server using asyncio. It works, but I don't 
> always understand how it works,

I thought that was the rule with asyncio.

;)

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

Re: HTTP server benchmarking/load testing in Python

[Grant Edwards]

On 2023-01-26, Thomas Passin  wrote:
> On 1/25/2023 7:38 PM, Peter J. Holzer wrote:
>> On 2023-01-25 16:30:56 -0500, Thomas Passin wrote:
>>> Great!  Don't forget what I said about potential overheating if you
>>> hit the server with as many requests as it can handle.
>> 
>> Frankly, if you can overheat a server by hitting it with HTTP requests,
>> get better hardware and/or put it into a place with better airflow.
>> 
>
> Frankly, if you have a server-grade machine then well and good but if 
> you are running a nice quiet consumer grade laptop - my development 
> machine - you need to be careful.

A properly designed laptop with a non-broken OS will not overheat
regardless of the computing load you throw at it. The fan might get
annoying loud, but if it overheats either your hardware or OS needs
to be fixed.

--
Grant



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

Re: How to make argparse accept "-4^2+5.3*abs(-2-1)/2" string argument?

[Mats Wichmann]

On 1/24/23 23:28, Jach Feng wrote:

Chris Angelico 在 2023年1月25日 星期三下午1:16:25 [UTC+8] 的信中寫道：

On Wed, 25 Jan 2023 at 14:42, Jach Feng  wrote:

I was happy working with argparse during implement my script. To save the 
typing, I used a default equation for testing.

sample = "-4^2+5.3*abs(-2-1)/2, abs(Abc)*(B+C)/D, (-3) * sqrt(1-(x1/7)*(y1/7)) * 
sqrt(abs((x0-4.5)/(y0-4)))"
parser = argparse.ArgumentParser(description='Convert infix notation to 
postfix')
parser.add_argument('infix', nargs='?', default=sample, help="")


You're still not really using argparse as an argument parser. Why not
just do your own -h checking? Stop trying to use argparse for what
it's not designed for, and then wondering why it isn't doing what you
expect it to magically know.

ChrisA

I just don't get what you mean?


You're still not really using argparse as an argument parser. Why not just do 
your own -h checking?


Is a math equation not qualified as a command line "argument"? What criteria do you use 
when judging the quality of an "argument"?


The ancient UNIX concept, later codified in the POSIX international 
standard, is that if an argument begins with a '-' it specifies an 
option.  The three standard library CLI argument parsers (getopt, 
optparse and argparse) all follow this convention.  You're feeding it 
something that they will conclude is an option, but you have given 
argparse no information how to deal with such an option.  The advice 
you've been given is: this is built in behavior.  You don't want that 
behavior. Either "fool" the module somehow (quoting with leading spaces, 
use the special option identifier of a bare double dash indicating "end 
of options", etc.) - or just don't use a module that behaves in a way 
you don't like.




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

RE: bool and int

[avi.e.gross]

Gerard,

I am sure there is. I have been on many forums that discuss programming
languages and since nothing is perfect and people differ in many ways, there
is always grumbling and comparison.

If we all agreed and there was only one of something, I suspect we still
would complain and that is precisely why there are generally many variations
as others like their own ideas better.

Python remains a quite decent and useful language, warts and especially
imagined warts and all.

Avi

-Original Message-
From: Python-list  On
Behalf Of Weatherby,Gerard
Sent: Thursday, January 26, 2023 5:52 AM
To: python-list@python.org
Subject: Re: bool and int

I can't help but wonder if there exists some Java forum /mailing list going
on about how horrible Python is.

From: Python-list  on
behalf of rbowman 
Date: Wednesday, January 25, 2023 at 12:25 PM
To: python-list@python.org 
Subject: Re: bool and int
*** Attention: This is an external email. Use caution responding, opening
attachments or clicking on links. ***

On Wed, 25 Jan 2023 06:53:44 -0500, 2QdxY4RzWzUUiLuE wrote:


> They used Java at my last job (as in, the last job I had before I 
> retired), and it was absolutely awful, for any number of reasons, the 
> gymnastics (on many levels) required to support "primitive types" 
> being one of them.

My first brush with Java was around '98 when it was first becoming popular.
To familiarize myself with the AWT I decided to write a simple IDE for the
AVR microcontrollers. What a disaster. The UI wasn't bad but the
instructions for 8-bit processors require a lot of bit fiddling that was
extraordinarily difficult in Java.

Then they came out with Swing and the assumption if the app ran with glacial
slowness you should get a faster machine.

The company I work for has one Java app created around 2000 as a cross
platform solution as people moved to Windows. Originally it ran as an applet
but when that window was slammed shut it became increasingly unwieldy.

For what I'm developing today I used either .NET C# or Python3. The .NET
UI's on Linux aren't quite there yet but back end applications are fine.
PyQt (PySide actually. If there is a way to screw up commercial licensing Qt
will find it) is fine.
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-
list__;!!Cn_UX_p3!iVrdROvxcoNV-GhzezJe8fJSLSAUoPkZHaXF58tWtyogy37PB6b9DH-gIN
gbVLuU64V4RovArDpnC5jjiQ$
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: HTTP server benchmarking/load testing in Python

[Thomas Passin]

On 1/25/2023 11:23 PM, Dino wrote:

On 1/25/2023 3:27 PM, Dino wrote:

On 1/25/2023 1:33 PM, orzodk wrote:


I have used locust with success in the past.

https://locust.io


First impression, exactly what I need. Thank you Orzo!


the more I learn about Locust and I tinker with it, the more I love it. 
Thanks again.


That's the one I was trying to remember!  I think it was in in its early 
days when I tried it out.


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

Re: bool and int

[Chris Angelico]

On Thu, 26 Jan 2023 at 21:53, Weatherby,Gerard  wrote:
>
> I can’t help but wonder if there exists some Java forum /mailing list going 
> on about how horrible Python is.

Try https://www.reddit.com/r/ProgrammerHumor/ for plenty of people
whining about how horrible Python is.

But along the way, you'll also find people whining about ChatGPT,
reposting memes with minor updates, and sharing the very best (worst?)
of dad jokes.

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

Flamebait (was: Re: bool and int)

[2QdxY4RzWzUUiLuE]

On 2023-01-26 at 10:52:06 +,
"Weatherby,Gerard"  wrote:

> I can’t help but wonder if there exists some Java forum /mailing list
> going on about how horrible Python is.

Not some of them.  *All* of them.  Here's the summary:

  - Dynamic Typing causes defects and makes non-toy software projects
impossible.

  - Python is slow.

  - Significant Whitespace [insert pejorative here].

  - Python allows code to exist outside of methods, and methods to exist
outside of classes.  What's a function?

  - There is no backwards compatibility.

Many, if not most, languages are created as improvements over others,
because those others have serious flaws (whether those flaws are real or
perceived).  And even at that, the earliest languages were created
because cores, wires, and machine languages were extremely painful.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bool and int

[Weatherby,Gerard]

I can’t help but wonder if there exists some Java forum /mailing list going on 
about how horrible Python is.

From: Python-list  on 
behalf of rbowman 
Date: Wednesday, January 25, 2023 at 12:25 PM
To: python-list@python.org 
Subject: Re: bool and int
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On Wed, 25 Jan 2023 06:53:44 -0500, 2QdxY4RzWzUUiLuE wrote:


> They used Java at my last job (as in, the last job I had before I
> retired), and it was absolutely awful, for any number of reasons, the
> gymnastics (on many levels) required to support "primitive types" being
> one of them.

My first brush with Java was around '98 when it was first becoming
popular. To familiarize myself with the AWT I decided to write a simple
IDE for the AVR microcontrollers. What a disaster. The UI wasn't bad but
the instructions for 8-bit processors require a lot of bit fiddling that
was extraordinarily difficult in Java.

Then they came out with Swing and the assumption if the app ran with
glacial slowness you should get a faster machine.

The company I work for has one Java app created around 2000 as a cross
platform solution as people moved to Windows. Originally it ran as an
applet but when that window was slammed shut it became increasingly
unwieldy.

For what I'm developing today I used either .NET C# or Python3. The .NET
UI's on Linux aren't quite there yet but back end applications are fine.
PyQt (PySide actually. If there is a way to screw up commercial licensing
Qt will find it) is fine.
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iVrdROvxcoNV-GhzezJe8fJSLSAUoPkZHaXF58tWtyogy37PB6b9DH-gINgbVLuU64V4RovArDpnC5jjiQ$
-- 
https://mail.python.org/mailman/listinfo/python-list

asyncio questions

[Frank Millman]

Hi all

I have written a simple HTTP server using asyncio. It works, but I don't 
always understand how it works, so I was pleased that Python 3.11 
introduced some new high-level concepts that hide the gory details. I 
want to refactor my code to use these concepts, but I am not finding it 
easy.


In simple terms my main loop looked like this -

    loop = asyncio.get_event_loop()
    server = loop.run_until_complete(
    asyncio.start_server(handle_client, host, port))
    loop.run_until_complete(setup_companies())
    session_check = asyncio.ensure_future(
    check_sessions())  # start background task
    print('Press Ctrl+C to stop')
    try:
    loop.run_forever()
    except KeyboardInterrupt:
    print()
    finally:
    session_check.cancel()  # tell session_check to stop running
    loop.run_until_complete(asyncio.wait([session_check]))
    server.close()
    loop.stop()

Using 3.11 it now looks like this -

    with asyncio.Runner() as runner:
    server = runner.run(asyncio.start_server(
    handle_client, host, port)
    runner.run(setup_companies())
    session_check = asyncio.ensure_future(
    check_sessions())  # start background task
    print('Press Ctrl+C to stop')
    try:
    runner.run(server.serve_forever())
    except KeyboardInterrupt:
    print()
    finally:
    session_check.cancel()  # tell session_check to stop running
    runner.run(asyncio.wait([session_check]))
    server.close()

It works, and I guess it looks a bit neater.

Problem 1.

The docs to 'asyncio.ensure_future' state 'See also the create_task() 
function which is the preferred way for creating new Tasks'


If I change 'ensure_future' to 'create_task', I get
    RuntimeError: no running event loop

I don't know how to fix this.

Problem 2.

The docs have a section on 'Handling Keyboard Interruption'

https://docs.python.org/3.11/library/asyncio-runner.html#asyncio.Runner

I have not figured out how to adapt my code to use this new approach.

Any suggestions appreciated.

Frank Millman

P.S. Might it be better to ask these questions on the Async_SIG 
Discussion Forum?

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

Re: [Help Request] Embedding Python in a CPP Application Responsibly & Functionally

[Dieter Maurer]

John McCardle wrote at 2023-1-25 22:31 -0500:
> ...
>1) To get the compiled Python to run independently, I have to hack
>LD_LIBRARY_PATH to get it to execute. `LD_LIBRARY_PATH=./Python-3.11.1
>./Python-3.11.1/python` .

The need to set `LD_LIBRARY_PATH` usually can be avoided via
a link time option: it tells the linker to add library path
information into the created shared object.

Read the docs to find out which option this is (I think it
was `-r` but I am not sure).

>Even when trying to execute from the same
>directory as the binary & executable, I get an error, `/python: error
>while loading shared libraries: libpython3.11.so.1.0: cannot open shared
>object file: No such file or directory`.

It might be necessary, to provide the option mentioned above
for all shared libraries involved in your final application.

Alternatively, you could try to put the shared objects
into a stadard place (searched by default).

>2) When running the C++ program that embeds Python, I see these messages
>after initializing:
>`Could not find platform independent libraries 
>Could not find platform dependent libraries `

Again: either put your installation in a standard place
or tell the Python generation process about your non-standard place.


>This is seemingly connected to some issues regarding libraries: When I
>run the Python interpreter directly, I can get some of the way through
>the process of creating a virtual environment, but it doesn't seem to
>leave me with a working pip:
>
>`$ LD_LIBRARY_PATH=./Python-3.11.1 ./Python-3.11.1/python
> >>> import venv
> >>> venv.create("./venv", with_pip=True)
>subprocess.CalledProcessError: Command
>'['/home/john/Development/7DRL/cpp_embedded_python/venv/bin/python',
>'-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit
>status 127.`

Run the command manually and see what errors this gives.

> ...

>3) I'm not sure I even need to be statically linking the interpreter.

There should be no need (if all you want in the embedding).
-- 
https://mail.python.org/mailman/listinfo/python-list