date:20210924



Terry J. Reedy  added the comment:

Antoine, git blame says you added at least many of the lines Thomas proposes to 
remove.

--
nosy: +pitrou, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43914] Highlight invalid ranges in SyntaxErrors



Change by Terry J. Reedy :


--
pull_requests: +26941
pull_request: https://github.com/python/cpython/pull/28558

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: XML Considered Harmful


On 25/09/21 10:51 am, dn wrote:

XML: Originally invented for text markup, and that shows. Can represent
different types (via tags), can define those types (via DTD and/or
schemas), can identify schemas in a globally-unique way and you can mix
them all in a single document (and there are tools available to validate
your files). But those features make it very complex


And for all that complexity, it still doesn't map very well
onto the kinds of data structures used inside programs (lists,
structs, etc.), so you end up having to build those structures
on top of it, and everyone does that in a different way.

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

Re: XML Considered Harmful


On 25/09/21 11:00 am, Chris Angelico wrote:

On Sat, Sep 25, 2021 at 8:53 AM dn via Python-list
 wrote:


and YAML?


Invented because there weren't enough markup languages, so we needed another?


There were *too many* markup languages, so we invented another!

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

Re: XML Considered Harmful


On 25/09/21 6:34 am, Peter J. Holzer wrote:

Several hundred genes were recently renamed because Excel was unable to
read their names as simply strings and insisted on interpreting them as
something else (e.g. dates).


Another fun one I've come across is interpreting phone numbers
as floating point and writing them out again with exponents...

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

Re: XML Considered Harmful


On 25/09/21 6:29 am, Peter J. Holzer wrote:

don't forget that
XML was intended to replace SGML, and that SGML was intended to mark up
text, not represent any data.


And for me this is the number one reason why XML is the wrong
tool for almost everything it's used for nowadays.

It's bizarre. It's as though there were a large community of
professional builders who insisted on using hammers to drive
scews, and extolled the advantages of doing so.

--
Greg

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

[issue45277] typo in codecs documentation



Change by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45277] typo in codecs documentation



miss-islington  added the comment:


New changeset 2a7d985bb3a1d85d63f135956750b330408702e6 by Miss Islington (bot) 
in branch '3.9':
bpo-45277: Fix typo in codecs doc (GH-28555)
https://github.com/python/cpython/commit/2a7d985bb3a1d85d63f135956750b330408702e6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45277] typo in codecs documentation



miss-islington  added the comment:


New changeset 371ca3b54d355476cc735cb932e80f5cd16310da by Miss Islington (bot) 
in branch '3.10':
bpo-45277: Fix typo in codecs doc (GH-28555)
https://github.com/python/cpython/commit/371ca3b54d355476cc735cb932e80f5cd16310da


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45277] typo in codecs documentation



Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +26939
pull_request: https://github.com/python/cpython/pull/28556

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45277] typo in codecs documentation



Change by miss-islington :


--
pull_requests: +26940
pull_request: https://github.com/python/cpython/pull/28557

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45277] typo in codecs documentation



Terry J. Reedy  added the comment:


New changeset 4c0fc65cd8a6d4c18330505576ccd4b46abeec1c by Terry Jan Reedy in 
branch 'main':
bpo-45277: Fix typo in codecs doc (GH-28555)
https://github.com/python/cpython/commit/4c0fc65cd8a6d4c18330505576ccd4b46abeec1c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Different "look and feel" of some built-in functions

On Sat, Sep 25, 2021 at 11:11 AM Oscar Benjamin
 wrote:
>
> On Sat, 25 Sept 2021 at 02:01, Chris Angelico  wrote:
>>
>> On Sat, Sep 25, 2021 at 10:56 AM Oscar Benjamin
>>  wrote:
>> >
>> > On Sat, 25 Sept 2021 at 00:37, Greg Ewing 
>> > wrote:
>> > > I suppose they could be fiddled somehow to make it possible, but
>> > > that would be turning them into special cases that break the rules.
>> > > It would be better to provide separate functions, as was done with
>> > > sum().
>> > >
>> >
>> > A separate union function would be good. Even in a situation where all
>> > inputs are assured to be sets the set.union method fails the base case:
>> >
>> > >>> sets = []
>> > >>> set.union(*sets)
>> > Traceback (most recent call last):
>> >   File "", line 1, in 
>> > TypeError: descriptor 'union' of 'set' object needs an argument
>> >
>> > In the case of intersection perhaps the base case should be undefined.
>> >
>>
>> Rather than calling the unbound method, why not just call it on an
>> empty set? That defines your base case as well.
>>
>> set().union(*sets)
>
>
> That is indeed what I do but it seems unnatural compared to simply 
> union(*sets). It shouldn't be necessary to create a redundant empty set just 
> to compute the union of some other sets. If there was a union function then I 
> don't think I would ever use the union method.
>

Maybe, but if you start with a set, then you define the base case, and
it also is quite happy to take non-set arguments:

>>> set().union([1,2,3], map(int, "234"), {3:"three",4:"four",5:"five"})
{1, 2, 3, 4, 5}

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

Re: Different "look and feel" of some built-in functions

2021-09-24 Thread Oscar Benjamin

On Sat, 25 Sept 2021 at 02:01, Chris Angelico  wrote:

> On Sat, Sep 25, 2021 at 10:56 AM Oscar Benjamin
>  wrote:
> >
> > On Sat, 25 Sept 2021 at 00:37, Greg Ewing 
> > wrote:
> > > I suppose they could be fiddled somehow to make it possible, but
> > > that would be turning them into special cases that break the rules.
> > > It would be better to provide separate functions, as was done with
> > > sum().
> > >
> >
> > A separate union function would be good. Even in a situation where all
> > inputs are assured to be sets the set.union method fails the base case:
> >
> > >>> sets = []
> > >>> set.union(*sets)
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > TypeError: descriptor 'union' of 'set' object needs an argument
> >
> > In the case of intersection perhaps the base case should be undefined.
> >
>
> Rather than calling the unbound method, why not just call it on an
> empty set? That defines your base case as well.
>
> set().union(*sets)
>

That is indeed what I do but it seems unnatural compared to simply
union(*sets). It shouldn't be necessary to create a redundant empty set
just to compute the union of some other sets. If there was a union function
then I don't think I would ever use the union method.


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

Re: Different "look and feel" of some built-in functions

On Sat, Sep 25, 2021 at 10:56 AM Oscar Benjamin
 wrote:
>
> On Sat, 25 Sept 2021 at 00:37, Greg Ewing 
> wrote:
>
> > On 25/09/21 10:15 am, Steve Keller wrote:
> > > BTW, I like how the min() and max() functions allow both ways of being
> > > called.
> >
> > That wouldn't work for set.union and set.intersection, because as
> > was pointed out, they're actually methods, so set.union(some_seq)
> > is a type error:
> >
> >  >>> a = {1, 2}
> >  >>> b = {3, 4}
> >  >>> set.union([a, b])
> > Traceback (most recent call last):
> >File "", line 1, in 
> > TypeError: descriptor 'union' for 'set' objects doesn't apply to a
> > 'list' object
> >
> > I suppose they could be fiddled somehow to make it possible, but
> > that would be turning them into special cases that break the rules.
> > It would be better to provide separate functions, as was done with
> > sum().
> >
>
> A separate union function would be good. Even in a situation where all
> inputs are assured to be sets the set.union method fails the base case:
>
> >>> sets = []
> >>> set.union(*sets)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: descriptor 'union' of 'set' object needs an argument
>
> In the case of intersection perhaps the base case should be undefined.
>

Rather than calling the unbound method, why not just call it on an
empty set? That defines your base case as well.

set().union(*sets)

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

Re: Different "look and feel" of some built-in functions

2021-09-24 Thread Oscar Benjamin

On Sat, 25 Sept 2021 at 00:37, Greg Ewing 
wrote:

> On 25/09/21 10:15 am, Steve Keller wrote:
> > BTW, I like how the min() and max() functions allow both ways of being
> > called.
>
> That wouldn't work for set.union and set.intersection, because as
> was pointed out, they're actually methods, so set.union(some_seq)
> is a type error:
>
>  >>> a = {1, 2}
>  >>> b = {3, 4}
>  >>> set.union([a, b])
> Traceback (most recent call last):
>File "", line 1, in 
> TypeError: descriptor 'union' for 'set' objects doesn't apply to a
> 'list' object
>
> I suppose they could be fiddled somehow to make it possible, but
> that would be turning them into special cases that break the rules.
> It would be better to provide separate functions, as was done with
> sum().
>

A separate union function would be good. Even in a situation where all
inputs are assured to be sets the set.union method fails the base case:

>>> sets = []
>>> set.union(*sets)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: descriptor 'union' of 'set' object needs an argument

In the case of intersection perhaps the base case should be undefined.

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

[issue45277] typo in codecs documentation



Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +26938
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28555

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45277] typo in codecs documentation



Terry J. Reedy  added the comment:

Thanks for the report.  I will fix this.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45275] Make argparse print description of subcommand when invoke help doc on subcommand



Change by Terry J. Reedy :


--
versions:  -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45267] New install Python 3.9.7 install of Sphinx Document Generator fails



Change by Terry J. Reedy :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45020] Freeze all modules imported during startup.

2021-09-24 Thread Eric Snow



Change by Eric Snow :


--
pull_requests: +26937
pull_request: https://github.com/python/cpython/pull/28554

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45274] Race condition in Thread._wait_for_tstate_lock()



STINNER Victor  added the comment:

> I am not sure that it can be solved at Python level.

Right. In pure Python, we cannot write code which works in all cases. My PR 
28532 fix the most common case: application interrupted by a single CTRL+C.

> with suppress_interrupt(): (...)

It's important to be able to interrupt acquire() which can be called in 
blocking mode with no timeout: it's exactly what tox does, and users expect to 
be able to interrupt tox in this case.

> * Add a Lock method (or just a builtin function) which acquires and 
> immediately releases the lock, without possibility to interrupt.

The acquire()+release() sequence can be made atomic in C, but it doesn't solve 
the problem of _stop() which can be interrupted by a second exception.

This bug is likely as old as Python. I don't think that we should attempt to 
design a perfect solution. I only propose to make the race condition (way) less 
likely.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45252] Missing support for Source Specific Multicast



Change by Terry J. Reedy :


--
versions:  -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45254] HAS_SHMEM detection logic is duplicated in implementation and tests



Change by Terry J. Reedy :


--
nosy: +davin, pitrou
versions:  -Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45251] signal.SIGCLD alias is not available on OSX



Change by Terry J. Reedy :


--
versions:  -Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: XML Considered Harmful

2021-09-24 Thread Jon Ribbens via Python-list

On 2021-09-24, Chris Angelico  wrote:
> On Sat, Sep 25, 2021 at 8:53 AM dn via Python-list
> wrote:
>> On 25/09/2021 06.59, Peter J. Holzer wrote:
>> > CSV: Good for tabular data of a single data type (strings). As soon as
>> > there's a second data type (numbers, dates, ...) you leave standard
>> > territory and are into "private agreements".

CSV is not good for strings, as there is no one specification of how to
encode things like newlines and commas within the strings, so you may
find that your CSV data transfer fails or even silently corrupts data.

>> > JSON: Has a few primitive data types (bool, number, string) and a two
>> > compound types (list, dict(string -> any)). Still missing many
>> > frequently used data types (e.g. dates) and has no standard way to
>> > denote composite types. But its simple and if it's sufficient for your
>> > needs, use it.

JSON Schema provides a way to denote composite types.

>> > XML: Originally invented for text markup, and that shows. Can represent
>> > different types (via tags), can define those types (via DTD and/or
>> > schemas), can identify schemas in a globally-unique way and you can mix
>> > them all in a single document (and there are tools available to validate
>> > your files). But those features make it very complex (you almost
>> > certainly don't want to write your own parser) and you really have to
>> > understand the data model (especiall namespaces) to use it.
>>
>> and YAML?
>
> Invented because there weren't enough markup languages, so we needed
> another?

Invented as a drunken bet that got out of hand, and used by people who
don't realise this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Different "look and feel" of some built-in functions

On 25/09/21 10:15 am, Steve Keller wrote:

BTW, I like how the min() and max() functions allow both ways of being
called.

That wouldn't work for set.union and set.intersection, because as
was pointed out, they're actually methods, so set.union(some_seq)
is a type error:

>>> a = {1, 2}
>>> b = {3, 4}
>>> set.union([a, b])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: descriptor 'union' for 'set' objects doesn't apply to a 
'list' object

I suppose they could be fiddled somehow to make it possible, but
that would be turning them into special cases that break the rules.
It would be better to provide separate functions, as was done with
sum().

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

Re: XML Considered Harmful

2021-09-24 Thread David L Neil via Python-list

On 25/09/2021 11.00, Chris Angelico wrote:

> Invented because there weren't enough markup languages, so we needed another?

Anything You Can Do I Can Do Better
https://www.youtube.com/watch?v=_UB1YAsPD6U

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

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



STINNER Victor  added the comment:

I close the issue.

> bpo-41299: Fix EnterNonRecursiveMutex() (GH-28548)

I don't think that it's worth it to backport this change to 3.9 and 3.10. In 
practice, Py_FatalError() will never be called, and _PyTime_GetMonotonicClock() 
result must always be greater than 0.

But I wanted to remove it in the main branch to reduce the number of functions 
calling Py_FatalError().

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



STINNER Victor  added the comment:


New changeset 6bc89116cb121c176453b9745e3daa2cc5df43ab by Victor Stinner in 
branch 'main':
bpo-41299: Mark private thread_nt.h functions as static (GH-28553)
https://github.com/python/cpython/commit/6bc89116cb121c176453b9745e3daa2cc5df43ab


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)



STINNER Victor  added the comment:

Analysis use use_tracing usage in 3rd part code.

I see two main ways to add C API functions covering these use cases:

* Provide high-level functions like "call a trace function" (disable tracing, 
call trace function, reenable tracing, increment/decrement tstate->tracing)
* Provide low-level functions just to control use_tracing: make PyThreadState 
structure opaque, but stil make the assumption that it is possible to disable 
temporarily tracing and profiling (in practice, it's implemented as 
use_tracing=0).



(*) greenlet

greenlet disables temporarily tracing in g_calltrace(), and then restore it, to 
call a "tracing" function:
---
tstate->tracing++;
TSTATE_USE_TRACING(tstate) = 0;
retval = PyObject_CallFunction(tracefunc, "O(OO)", event, origin, target);
tstate->tracing--;
TSTATE_USE_TRACING(tstate) =
(tstate->tracing <= 0 &&
 ((tstate->c_tracefunc != NULL) || (tstate->c_profilefunc != NULL)));
---

It also saves and then restores use_tracing value:
---
ts__g_switchstack_use_tracing = tstate->cframe->use_tracing;
(...)
tstate->cframe->use_tracing = ts__g_switchstack_use_tracing;
---

=> it can use PyThreadState_IsTracing(), PyThreadState_DisableTracing() and 
PyThreadState_ResetTracing().

These functions don't handle "tstate->tracing++;" and "tstate->tracing--;" 
which is also used by greenlet.

greenlet also saves and restores tstate->cframe:
https://github.com/python-greenlet/greenlet/blob/master/src/greenlet/greenlet.c


(*) dipy

Code generated by Cython.


(*) smartcols

Code generated by Cython.


(*) yappi

yappi is Python profiler.

yappi sets use_tracing to 1 when it sets its profile function: 
"ts->c_profilefunc = _yapp_callback;".

It sets use_tracing to 0 when it clears the profile function: 
"ts->c_profilefunc = NULL;". That's wrong, it ignores the trace function.

PyEval_SetProfile() cannot be used because yappi works on a PyThreadState (ts).

Code: https://github.com/sumerc/yappi/blob/master/yappi/_yappi.c

It can use PyThreadState_DisableTracing() and PyThreadState_ResetTracing(). 
Maybe a PyThreadState_SetProfile(tstate, func) function would fit better 
yappi's use case.


(*) Cython

Cython defines 2 compatibility functions:

* __Pyx_IsTracing(tstate, check_tracing, check_funcs): it can check 
c_profilefunc and c_tracefunc
* __Pyx_SetTracing(tstate, enable)

Code: https://github.com/cython/cython/blob/0.29.x/Cython/Utility/Profile.c

The code is quite complicated. In short, it checks if tracing and/or profiling 
is enabled. If it's enabled, it disables temporarily tracing (use_tracing=0) 
while calling trace and profile functions.

=> it requires PyThreadState_IsTracing(), PyThreadState_DisableTracing() and 
PyThreadState_ResetTracing().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: XML Considered Harmful

On Sat, Sep 25, 2021 at 8:53 AM dn via Python-list
 wrote:
>
> On 25/09/2021 06.59, Peter J. Holzer wrote:
> > There are a gazillion formats and depending on your needs one of them
> > might be perfect. Or you may have to define you own bespoke format (I
> > mean, nobody (except Matt Parker) tries to represent images or videos as
> > CSVs: There's PNG and JPEG and WEBP and H.264 and AV1 and whatever for
> > that).
> >
> > Of the three formats discussed here my take is:
> >
> > CSV: Good for tabular data of a single data type (strings). As soon as
> > there's a second data type (numbers, dates, ...) you leave standard
> > territory and are into "private agreements".
> >
> > JSON: Has a few primitive data types (bool, number, string) and a two
> > compound types (list, dict(string -> any)). Still missing many
> > frequently used data types (e.g. dates) and has no standard way to
> > denote composite types. But its simple and if it's sufficient for your
> > needs, use it.
> >
> > XML: Originally invented for text markup, and that shows. Can represent
> > different types (via tags), can define those types (via DTD and/or
> > schemas), can identify schemas in a globally-unique way and you can mix
> > them all in a single document (and there are tools available to validate
> > your files). But those features make it very complex (you almost
> > certainly don't want to write your own parser) and you really have to
> > understand the data model (especiall namespaces) to use it.
>
> and YAML?

Invented because there weren't enough markup languages, so we needed another?

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

Re: XML Considered Harmful

2021-09-24 Thread dn via Python-list

On 25/09/2021 06.59, Peter J. Holzer wrote:
> There are a gazillion formats and depending on your needs one of them
> might be perfect. Or you may have to define you own bespoke format (I
> mean, nobody (except Matt Parker) tries to represent images or videos as
> CSVs: There's PNG and JPEG and WEBP and H.264 and AV1 and whatever for
> that).
> 
> Of the three formats discussed here my take is:
> 
> CSV: Good for tabular data of a single data type (strings). As soon as
> there's a second data type (numbers, dates, ...) you leave standard
> territory and are into "private agreements".
> 
> JSON: Has a few primitive data types (bool, number, string) and a two
> compound types (list, dict(string -> any)). Still missing many
> frequently used data types (e.g. dates) and has no standard way to
> denote composite types. But its simple and if it's sufficient for your
> needs, use it.
> 
> XML: Originally invented for text markup, and that shows. Can represent
> different types (via tags), can define those types (via DTD and/or
> schemas), can identify schemas in a globally-unique way and you can mix
> them all in a single document (and there are tools available to validate
> your files). But those features make it very complex (you almost
> certainly don't want to write your own parser) and you really have to
> understand the data model (especiall namespaces) to use it.

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

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



STINNER Victor  added the comment:


New changeset d639e3170506a1a80c4b2f1b3a6250bb95ff190a by Victor Stinner in 
branch 'main':
bpo-41299: Fix EnterNonRecursiveMutex() (GH-28548)
https://github.com/python/cpython/commit/d639e3170506a1a80c4b2f1b3a6250bb95ff190a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Different "look and feel" of some built-in functions

2021-09-24 Thread Steve Keller

"Dieter Maurer"  writes:

> Steve Keller wrote at 2021-9-24 11:48 +0200:
> >Why do some built-in Python functions feel so differently:
> 
> Because the typical use cases are different
> 
> [...]
> 
> >while other functions like set.union() and set.intersection() work on
> >a list of arguments but not on a sequence:
> >
> >set.intersection({1,2,3}, {3,4,5})
> 
> Those operations are typically applied to a small number
> of operands. You would need to build an iterator in that
> case should the functions only accept iterators.

In my experience I need intersection and union on a list of sets, set
of sets or a map() returning sets much more often.  E.g. in some
mathematical problems, and in automaton theory (IIRC, computing of LR
or LALR sets, converting NFA to DFA, minimizing DFA), many graph
algorithms traversing the nodes (shortest path, ...), and so on).

Intersection and union of two sets is actually often seen in naïve
programming in loops like

for t in (some_sequence):
s.union(t)

where set.union(*(some_sequence)) would be much more elegant.

BTW, I like how the min() and max() functions allow both ways of being
called.

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

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



STINNER Victor  added the comment:


New changeset f35ddf24227e834c9b6b39ad23a0ec382b4de48b by Victor Stinner in 
branch 'main':
bpo-41299: QueryPerformanceFrequency() cannot fail (GH-28552)
https://github.com/python/cpython/commit/f35ddf24227e834c9b6b39ad23a0ec382b4de48b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44687] io.BufferedReader:peek() closes underlying file, breaking peek/read expectations

2021-09-24 Thread Steve Dower



Steve Dower  added the comment:

That change makes me much happier :)

Do you think we need a specific test added for this case? I'd guess we have 
plenty of coverage for the changed macro already, but clearly nothing that 
showed the issue before.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

2021-09-24 Thread Filipe Laíns


Filipe Laíns  added the comment:

One technical argument on why it would be beneficial to have custom handling 
like this for exit is that exit is a site-builtin, not a builtin.

$ python -S
Python 3.9.7 (default, Aug 31 2021, 13:28:12)
[GCC 11.1.0] on linux
>>> exit()
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'exit' is not defined
>>> import sys
>>> sys.exit()

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



Change by STINNER Victor :


--
pull_requests: +26936
pull_request: https://github.com/python/cpython/pull/28553

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45249] Update doctect SyntaxErrors for location range

Terry J. Reedy added the comment:

In 3.10+, end_lineno and end_offset fields were added to SyntaxError objects
and the args tuple.

>>> try: compile('1 1', '', 'single')
... except SyntaxError as e: print(e.args)
...
('invalid syntax. Perhaps you forgot a comma?', ('', 1, 1, '1 1', 1, 4))

Here, line 1, offset 4 is the first 1-based column not part of the error.

The builtin default sys.excepthook was modified to read and use this new
information and mark (end_offset - offset) columns with '^'s. This default
prints what it does to sys.stderr.

The syntax error formatting in the traceback module was not altered. However,
a new method, TracebackException._format_syntax_error, was extracted from
TracebackException.format_exception_only so that the former could be overridden
by software that simulates interaction.

The printed traceback does not come from line 1348. That *executes* the user
code, but all Exceptions, including SyntaxError, are caught. If the exception
is not expected and the run is not quiet, the exception is output by
report_unexpected_exception(), as seen above as 'OUTPUT' and the lines that
follows.
https://github.com/python/cpython/blob/5846c9b71ee9277fe866b1bdee4cc6702323fe7e/Lib/doctest.py#L1264

This calls _exception_traceback(exc_info).
https://github.com/python/cpython/blob/5846c9b71ee9277fe866b1bdee4cc6702323fe7e/Lib/doctest.py#L244
This calls traceback.print_exception, which I believe, for syntax errors,
ultimately calls TracebackException._format_syntax_error.

I believe that the options for a fix are either
1. Call default sys.excepthook while capturing its output into a StringIO
instance.
2. Assuming I am correct above about _format_syntax_error being called,
monkeypatch it. In line 779,
https://github.com/python/cpython/blob/5846c9b71ee9277fe866b1bdee4cc6702323fe7e/Lib/traceback.py#L779
replace '^' with a field with a calculated number of ^s.

I need to do one of these two for IDLE, and may try both.

--
components: +Library (Lib) -Interpreter Core, Tests
nosy: +terry.reedy
stage: -> needs patch
title: SyntaxError location range indicator does not work in doctests -> Update
doctect SyntaxErrors for location range

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



Change by STINNER Victor :


--
pull_requests: +26935
pull_request: https://github.com/python/cpython/pull/28552

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35921] Use ccache by default

2021-09-24 Thread Łukasz Langa


Łukasz Langa  added the comment:

It seems to me like the consensus is to not alter CPython's build files because 
ccache is supposed to be used through its `cc`/`gcc` compiler wrappers. Those 
can be provided to a ./configure run either by modifying PATH to include the 
directory with the wrappers or by specifying the CC env var directly to point 
to the ccache wrapper (or "ccache gcc").

Therefore, I'm closing the issue. Antoine, this sat for 2.5 years without 
activity but if you feel strongly about reintroducing the idea, feel free to 
reopen.

--
nosy: +lukasz.langa
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45020] Freeze all modules imported during startup.

2021-09-24 Thread Eric Snow



Eric Snow  added the comment:


New changeset 7c801e0fa603b155eab3fd19698aa90854ac5a7b by Eric Snow in branch 
'main':
bpo-45020: Fix some corner cases for frozen module generation. (gh-28538)
https://github.com/python/cpython/commit/7c801e0fa603b155eab3fd19698aa90854ac5a7b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45244] pip not installed with fresh python3.8.10 installation



Terry J. Reedy  added the comment:

If you installed 'py' (the default), you should be able to install pip with 'py 
-3.8 -m ensurepip'.  (I had to do this once.  I wrote the failure off as a 
random glitch and did not think to open an issue.)

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45285] c_char incorrectly treated as bytes in Structure

2021-09-24 Thread Eryk Sun



Eryk Sun  added the comment:

A simple ctypes type implements a get function that's called when its value is 
returned as an attribute of struct/union, index of an array/pointer, or result 
of a function pointer. For example:

>>> a = (ctypes.c_char * 1)(97)
>>> a[0]
b'a'

>>> p = ctypes.POINTER(ctypes.c_char)(a)
>>> p[0]
b'a'

This behavior can't be changed. However, using a subclass of c_char works 
around it. For example:

>>> class my_char(ctypes.c_char): pass
... 

>>> a = (my_char * 1)(97)
>>> a[0]

>>> a[0].value
b'a'

>>> p = ctypes.POINTER(my_char)(a)
>>> p[0]

>>> p[0].value
b'a'

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41914] test_pdb fails


Terry J. Reedy  added the comment:

Léon's message from #45242, which I closed as a duplicate of this.

Leon: please try with 3.11 (best, repository main), 3.10, or at least 3.9.  3.8 
and before only get security fixes.
---

Building Python 3.7, I ran into the same issue reported [here] (only line 
numbers differ):

==
FAIL: test_errors_in_command (__main__.PdbTestCase)
--
Traceback (most recent call last):
  File "Lib/test/test_pdb.py", line 1535, in test_errors_in_command
'(Pdb) ',
AssertionError: Lists differ: ['(Pd[283 chars]efined", 'LEAVING RECURSIVE 
DEBUGGER', '(Pdb) ', '\x1b[?1034h'] != ['(Pd[283 chars]efined", 'LEAVING 
RECURSIVE DEBUGGER', '(Pdb) ']

First list contains 1 additional elements.
First extra element 9:
'\x1b[?1034h'

  ['(Pdb) *** SyntaxError: unexpected EOF while parsing',
   '(Pdb) ENTERING RECURSIVE DEBUGGER',
   '*** SyntaxError: unexpected EOF while parsing',
   'LEAVING RECURSIVE DEBUGGER',
   '(Pdb) ENTERING RECURSIVE DEBUGGER',
   '> (1)()',
   "((Pdb)) *** NameError: name 'doesnotexist' is not defined",
   'LEAVING RECURSIVE DEBUGGER',
-  '(Pdb) ',
?  ^

+  '(Pdb) ']
?  ^

-  '\x1b[?1034h']

--
Ran 39 tests in 1.024s

FAILED (failures=1)


I have also managed to determine the cause.  As can be seen, the output from 
this pdb invocation contains an extraneous ANSI control sequence ("interpret 
"meta" key, set eighth bit"). This happens when running the test inside the GNU 
`screen` environment.  Run the test outside `screen`, and the problem goes away.

(By the way, this was the only test that failed when running `make test` inside 
the `screen` environment.)

--
nosy: +terry.reedy
resolution: works for me -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45242] test_pdb fails



Change by Terry J. Reedy :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_pdb fails

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45240] Add +REPORT_NDIFF option to pdb tests that use doctest



Terry J. Reedy  added the comment:

Lukasz, there is no current doctest expert and I think that this is something 
you could either accept or reject fairly quickly.  Since the enhancement is to 
the tests, it could be backported.

--
nosy: +lukasz.langa, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45285] c_char incorrectly treated as bytes in Structure

2021-09-24 Thread CireSnave



New submission from CireSnave :

When dealing with a Structure containing c_char variables, the variables are 
incorrectly being typed as bytes.  As a result, a pointer to those c_char 
variables can not be created because bytes is not a ctypes type.

from ctypes import (
Structure,
c_char,
pointer,
)


class MyStruct(Structure):
_fields_ = [("a", c_char), ("b", c_char), ("c", c_char)]


x: MyStruct = MyStruct(98, 99, 100)

print(type(x.a))
# Prints  ???  Both mypy and PyRight agree that x.a is a c_char.

some_variable = pointer(x.a)
# Traceback (most recent call last):
#   File "C:\Users\cires\ctypes_test.py", line 23, in 
# some_variable = pointer(x.a)
# TypeError: _type_ must have storage info

--
components: ctypes
messages: 402582
nosy: ciresnave
priority: normal
severity: normal
status: open
title: c_char incorrectly treated as bytes in Structure
type: behavior
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44687] io.BufferedReader:peek() closes underlying file, breaking peek/read expectations

2021-09-24 Thread Jun De



Jun De  added the comment:

Yeap Steve, I was thinking the same thing. I've taken the buffered data into 
consideration when checking if the file is closed in my fix, feel free to take 
a look and let me know what you think :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: XML Considered Harmful

2021-09-24 Thread Peter J. Holzer

On 2021-09-21 13:12:10 -0500, Michael F. Stemper wrote:
> I read this page right when I was about to write an XML parser
> to get data into the code for a research project I'm working on.
> It seems to me that XML is the right approach for this sort of
> thing, especially since the data is hierarchical in nature.
> 
> Does the advice on that page mean that I should find some other
> way to get data into my programs, or does it refer to some kind
> of misuse/abuse of XML for something that it wasn't designed
> for?
> 
> If XML is not the way to package data, what is the recommended
> approach?

There are a gazillion formats and depending on your needs one of them
might be perfect. Or you may have to define you own bespoke format (I
mean, nobody (except Matt Parker) tries to represent images or videos as
CSVs: There's PNG and JPEG and WEBP and H.264 and AV1 and whatever for
that).

Of the three formats discussed here my take is:

CSV: Good for tabular data of a single data type (strings). As soon as
there's a second data type (numbers, dates, ...) you leave standard
territory and are into "private agreements".

JSON: Has a few primitive data types (bool, number, string) and a two
compound types (list, dict(string -> any)). Still missing many
frequently used data types (e.g. dates) and has no standard way to
denote composite types. But its simple and if it's sufficient for your
needs, use it.

XML: Originally invented for text markup, and that shows. Can represent
different types (via tags), can define those types (via DTD and/or
schemas), can identify schemas in a globally-unique way and you can mix
them all in a single document (and there are tools available to validate
your files). But those features make it very complex (you almost
certainly don't want to write your own parser) and you really have to
understand the data model (especiall namespaces) to use it.

You can of course represent any data in any format if you jump through
enough hoops, but the real question is "does the data I have fit
naturally within the data model of the format I'm trying to use". If it
doesn't, look for something else. For me, CSV, JSON and XML form a
hierarchy where each can naturally represent all the data of its
predecessors, but not vice versa.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

2021-09-24 Thread Peter J. Holzer

On 2021-09-23 06:53:10 -0600, Mats Wichmann wrote:
> The problem with csv is that a substantial chunk of the world seems to
> live inside Excel,

This is made sp much worse by Excel being exceptionally bad at reading
CSV.

Several hundred genes were recently renamed because Excel was unable to
read their names as simply strings and insisted on interpreting them as
something else (e.g. dates).

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

2021-09-24 Thread Peter J. Holzer

On 2021-09-21 19:46:19 -0700, Dan Stromberg wrote:
> On Tue, Sep 21, 2021 at 7:26 PM Michael F. Stemper <
> michael.stem...@gmail.com> wrote:
> > If XML is not the way to package data, what is the recommended
> > approach?
> >
> 
> I prefer both JSON and YAML over XML.
> 
> XML has both elements and tags, but it didn't really need both.

I think you meant "both elements and attributes". Tags are how you
denote elements, so they naturally go together.

I agree that for representing data (especially object-oriented data) the
distiction between (sub-)elements and attributes seems moot (should
represent that field as an attribute or a field?), but don't forget that
XML was intended to replace SGML, and that SGML was intended to mark up
text, not represent any data.

Would you really want to write

Mr. Smiths point was corroborated by
Ms. Jones point that bla, bla, which
seemed more plausibe than Mr. Willam
claim that blub, blub.

as

Mr. Smiths point was corroborated by
Ms. Jones point that bla, bla, which
seemed more plausibe than Mr. Willam
claim that blub, blub.

or

Mr. Smith<(defendant>s point was
corroborated by Ms. Jones point that bla,
bla, which seemed more plausibe than Mr. 
Willam claim that blub,
blub.

?

I probably chose an example (no doubt influenced by the fact that SGML
was originally invented to digitize court decisions) which is too simple
(in HTML I often see many attributes on a single element, even with
CSS), but even here you can see that attributes add clarity.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Different "look and feel" of some built-in functions

On Sat, Sep 25, 2021 at 3:42 AM Stefan Ram  wrote:
>
> "Dieter Maurer"  writes:
> >A list is ordered. Therefore, it is important where
> >in this order an element is added. Thus, for a list,
> >`append` is a better name than `add` -- because it already
> >tells us in the name where it adds the new element.
>
>   In a collection of texts, which is not large but mixed from
>   many different fields and genres, I find (using a Python
>   script, of course) eight hits for "added to the list" :
>
> |s and rock n roll can be added to the list. As - Taylor, 2012
> | of opinion was probably added to the list tow - from a dictionary
> |gg and his wife might be added to the list of  - Sir Walter Scott
> |ships when your name was added to the list. In - Percy Bysshe Shelley
> |em that wealth should be added to the list. No - Henry
> |n was discovered and was added to the list of  - from a dictionary
> |nd said his name must be added to the list, or - Mark Twain
>
>   . There was no hit for "appended to the list".
>
>   When one says "add something to a list", it is usually understood
>   that one adds it at the /end/. In the case of traditional written
>   lists it is not possible in any other way.
>

When I add something to the shopping list, it is not added to the end.
It is added anywhere that there is room. If you care about the
sequence, you would say "add to the end". Or, using the more technical
and briefer word, "append". Most of the lists you're seeing there are
not being added to the end of; for instance, I would guess that quite
a few of them are inherently sorted lists, so you would be adding a
person's name in affabeck lauder, or adding something to a particular
ranked position, or whatever else. This is not the same thing.

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

[issue44019] operator.call/operator.call

2021-09-24 Thread Mark Dickinson



Mark Dickinson  added the comment:


New changeset bfe26bbad787c124f0ce144cff1b513ef9d2dc9c by Terry Jan Reedy in 
branch 'main':
bpo-44019: Add missing comma to operator.call doc (GH-28551)
https://github.com/python/cpython/commit/bfe26bbad787c124f0ce144cff1b513ef9d2dc9c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35077] Make TypeError message less ambiguous

2021-09-24 Thread Karthikeyan Singaravelan



Karthikeyan Singaravelan  added the comment:

https://bugs.python.org/issue44110 did some improvements to error message to 
include type.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45284] Better `TypeError` message when a string is indexed using a non int

2021-09-24 Thread Karthikeyan Singaravelan



Karthikeyan Singaravelan  added the comment:

See also https://bugs.python.org/issue44110 . This looks like a duplicate. Also 
https://bugs.python.org/issue35077

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45284] Better `TypeError` message when a string is indexed using a non int

2021-09-24 Thread Rin RIn



Change by Rin RIn :


--
title: Better `TypeError` message when a string is indexed using a string -> 
Better `TypeError` message when a string is indexed using a non int

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44019] operator.call/operator.call



Change by Terry J. Reedy :


--
nosy: +terry.reedy
nosy_count: 6.0 -> 7.0
pull_requests: +26934
pull_request: https://github.com/python/cpython/pull/28551

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45284] Better `TypeError` message when a string is indexed using a string

2021-09-24 Thread Ganesh Kumar



New submission from Ganesh Kumar :

The `TypeError` message when a string is indexed using a string should be 
similar to the `TypeError` message when a list or tuple is indexed using a 
string.

>>> my_str = 'Rin'
>>> my_str[1:3]  # works
'in'
>>> my_str['no']
Traceback (most recent call last):
  File "", line 1, in 
TypeError: string indices must be integers

>>> my_str[slice(1, 3)]  # works with slices
'in'

Certainly it does work with slice as intended but the error message should 
explain that, as seen in the following

>>> my_list = [1, 2, 3]
>>> my_list['no']
Traceback (most recent call last):
  File "", line 1, in 
TypeError: list indices must be integers or slices, not str

>>> my_tuple = (1, 2, 3)
>>> my_tuple['no']
Traceback (most recent call last):
  File "", line 1, in 
TypeError: tuple indices must be integers or slices, not str

The error message shows `slices` are indeed an option to use when indexing a 
list or tuple.

Would be happy to submit a documentation PR if this minor change would be 
accepted.

--
components: Library (Lib)
messages: 402577
nosy: Rin
priority: normal
severity: normal
status: open
title: Better `TypeError` message when a string is indexed using a string
type: enhancement
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45211] Useful (expensive) information is discarded in getpath.c.

2021-09-24 Thread Eric Snow



Change by Eric Snow :


--
keywords: +patch
pull_requests: +26933
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/28550

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Different "look and feel" of some built-in functions

2021-09-24 Thread Dieter Maurer

Stefan Ram wrote at 2021-9-24 14:53 GMT:
>Steve Keller  writes:
>>Why do some built-in Python functions feel so differently:
>
>|>>> s = set()
>|>>> s.add( 1 )
>|>>>
>
>
>|>>> l = []
>|>>> l.add( 1 )
>
>|
>|Traceback (most recent call last):
>|  File "", line 1, in 
>|AttributeError: 'list' object has no attribute 'add'
>|
>|>>> l.append( 1 )

A list is ordered. Therefore, it is important where
in this order an element is added. Thus, for a list,
`append` is a better name than `add` -- because it already
tells us in the name where it adds the new element.

A set is unordered. Therefore, the name `append` does not make sense
for a set.

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

Re: Different "look and feel" of some built-in functions

2021-09-24 Thread Dieter Maurer

Steve Keller wrote at 2021-9-24 11:48 +0200:
>Why do some built-in Python functions feel so differently:

Because the typical use cases are different

>For example sum(), all(), any() expect exactly one argument which is a
>sequence to operate on, i.e. a list, an iterator or a generator etc.
>
>sum([1,2,3,4])
>sum(range(1, 101))
>sum(2**i for i in range(10))
>all([True, False])
>any(even, {1,2,3,4})

You use those functions typically on a large number
of operands, typically already collected together via some form
of iterator.
If you want to compute the sum of a few operands, you
would usually not use `sum` but `o1 + o2 + ...`.

>while other functions like set.union() and set.intersection() work on
>a list of arguments but not on a sequence:
>
>set.intersection({1,2,3}, {3,4,5})

Those operations are typically applied to a small number
of operands. You would need to build an iterator in that
case should the functions only accept iterators.



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

[issue40699] Memory leak in threading library with Python 3.6-3.8



STINNER Victor  added the comment:

I fail to reproduce the leak using attached script.

I close the issue.

I get constant memory usage on Linux with the main branch of Python (future 
3.11):

(...)
VmRSS: 11344 kB
VmRSS: 11344 kB
VmRSS: 11344 kB
VmRSS: 11344 kB
VmRSS: 11344 kB
VmRSS: 11344 kB
VmRSS: 11344 kB
VmRSS: 11344 kB
VmRSS: 11344 kB
VmRSS: 11344 kB
(...)

--
nosy: +vstinner
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
Added file: https://bugs.python.org/file50304/script.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40657] Resource leaks with threading.Thread



STINNER Victor  added the comment:

You must join thread using thread.join().

If I add .join() calls, threading.active_count() stays around 2, it doesn't 
grow.

It's not a bug in Python.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45218] cmath.log has an invalid signature

2021-09-24 Thread Dong-hee Na



Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45272] 'os.path' should not be a frozen module

2021-09-24 Thread Dong-hee Na



Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43050] threading timer memory leak



STINNER Victor  added the comment:

I cannot reproduce the issue. IMO it has been fixed.

Moreover, you must join timers using timer.join(): a timer remains a thread.

Code:
---
import os
import threading
os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
# warmup
for n in range(10):
timer = threading.Timer(5, None)
timer.start()
timer.cancel()
timer.join()
os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
for n in range(1000):
timer = threading.Timer(5, None)
timer.start()
timer.cancel()
timer.join()
os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")
---

Output on Linux with the main branch of Python (3.11):
---
VmRSS: 10924 kB
VmRSS: 11104 kB
VmRSS: 11104 kB
---

--
nosy: +vstinner
resolution: duplicate -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread



STINNER Victor  added the comment:

I proposed PR 28549 to fix this very old threading issue.

A C extension can spawn threads without using the threading module and then 
then run Python code which imports the threading module. In this case, 
threading._main_thread is the thread which imported first the threading module. 
My PR changes so threading._shutdown() simply ignores _main_thread when it 
happens.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1596321] KeyError at exit after 'import threading' in other thread



Change by STINNER Victor :


--
keywords: +patch
nosy: +vstinner
nosy_count: 14.0 -> 15.0
pull_requests: +26932
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/28549

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44019] operator.call/operator.call

2021-09-24 Thread Mark Dickinson



Mark Dickinson  added the comment:

Thanks for the contribution!

--
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful

2021-09-24 Thread Jeremy Maitin-Shepard



Jeremy Maitin-Shepard  added the comment:

To be clear, the problem I'm trying to address here is not specific to 
embedding Python in a C++ application.  In fact the issue came to my attention 
while using Python directly, but loading an extension module that was written 
in C++ using the popular pybind11 library.

If we continue having Python call `pthread_exit` and `_endthreadex`, we are 
imposing strong constraints on call stacks that call the Python API.  Granted, 
hanging a thread is also not something a well-behaved library should do, but it 
is at least slightly better than killing the thread.  In a sense hanging is 
also logical, since the thread has requested to block until the GIL can be 
acquired, and the GIL cannot be acquired.

I have described a number of problems caused by `pthread_exit`/`_endthreadex` 
that are fixed by hanging.  Can you help me understand what problems caused by 
hanging are fixed by `pthread_exit`/`_endthreadex`, that leads you to think it 
is a better default?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44019] operator.call/operator.call

2021-09-24 Thread Mark Dickinson



Mark Dickinson  added the comment:


New changeset 6587fc60d447603fb8c631d81d9bb379f53c39ab by Antony Lee in branch 
'main':
bpo-44019: Implement operator.call(). (GH-27888)
https://github.com/python/cpython/commit/6587fc60d447603fb8c631d81d9bb379f53c39ab


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20524] format error messages should provide context information

2021-09-24 Thread Eric V. Smith



Eric V. Smith  added the comment:

Thanks for the improvement, @sobolevn!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20524] format error messages should provide context information

2021-09-24 Thread Eric V. Smith



Eric V. Smith  added the comment:


New changeset 8d8729146f21f61af66e70d3ae9501ea6bdccd09 by Nikita Sobolev in 
branch 'main':
bpo-20524: adds better error message for `.format()` (GH-28310)
https://github.com/python/cpython/commit/8d8729146f21f61af66e70d3ae9501ea6bdccd09


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: XML Considered Harmful

2021-09-24 Thread Mostowski Collapse



Or then use cryptographic methods to protect your XML
file when in transit. Like encryption and/or signatures.

Mostowski Collapse schrieb am Freitag, 24. September 2021 um 15:46:27 UTC+2:
> BTW: I think its problematic to associate Java with XML.
> Michael F. Stemper schrieb am Dienstag, 21. September 2021 um 20:12:33 UTC+2: 
> > On the prolog thread, somebody posted a link to: 
> > 
> The above linke is very old, from 2004, and might apply 
> how Java presented itself back in those days. But since 
> the Jigsaw project, XML has practically left Java. 
> 
> Its all not anymore part of the javax.* or java.* namespace, 
> Oracle got rid of XML technologies housing in these 
> namespaces, and there is now the jakarta.* namespace. 
> 
> Example JAXB: 
> Jakarta XML Binding (JAXB; formerly Java Architecture for XML Binding) 
> https://de.wikipedia.org/wiki/Jakarta_XML_Binding 
> 
> If I remember well, also XML never went into the Java 
> Language Specification, unlike the Scala programming 
> language, where you can have XML literals: 
> 
> XML literals in scala 
> https://tuttlem.github.io/2015/02/24/xml-literals-in-scala.html 
> 
> An easy protection against tampered XML data vulnerabilities 
> is DTD or some other XML schema language. It can at least catch 
> problems that are in the scope of the schema language.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45282] isinstance(x, typing.Protocol-class) unexpectedly evaluates properties

2021-09-24 Thread Alex Waygood



Alex Waygood  added the comment:

Related: https://bugs.python.org/issue44904

--
nosy: +AlexWaygood

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45267] New install Python 3.9.7 install of Sphinx Document Generator fails

2021-09-24 Thread Paul Broe



Paul Broe  added the comment:

Good Morning:

I was able to resolve the issue based on your assistance.  I created this
topic at github.com

https://github.com/sphinx-doc/sphinx/issues/9669

Someone answered it and it was simple:

Thank you so much. That was it. I thought it was looking for a package but I
completely missed the fact that the package name was package. I can't
connect to the internet from my machines. So, I have to download everything
manually from PyPI.

I added packages pyparsing and packaging ...
And

Building wheels for collected packages: sphinx
Building wheel for sphinx (setup.py) ... done
Created wheel for sphinx: filename=Sphinx-4.2.0-py3-none-any.whl
size=3061858
sha256=c5b28f87749557dc8c06b9820c748d6c5e764e32f2f25620d08b3259993ea90a
Stored in directory:
/usr/opt/oracle/.cache/pip/wheels/31/d2/bc/aa1cbddf1cd38373f4632ab20b0e3400f
037bcf271b50b2397
Successfully built sphinx
Installing collected packages: sphinx
Successfully installed sphinx-4.2.0

You can close the issue.. It was not a python bug

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: XML Considered Harmful

2021-09-24 Thread Mostowski Collapse

BTW: I think its problematic to associate Java with XML.

Michael F. Stemper schrieb am Dienstag, 21. September 2021 um 20:12:33 UTC+2:
> On the prolog thread, somebody posted a link to: 
>  

The above linke is very old, from 2004, and might apply
how Java presented itself back in those days. But since
the Jigsaw project, XML has practically left Java.

Its all not anymore part of the javax.* or java.* namespace,
Oracle got rid of XML technologies housing in these 
namespaces, and there is now the jakarta.* namespace.

Example JAXB:
Jakarta XML Binding (JAXB; formerly Java Architecture for XML Binding) 
https://de.wikipedia.org/wiki/Jakarta_XML_Binding

If I remember well, also XML never went into the Java
Language Specification, unlike the Scala programming 
language, where you can have XML literals:

XML literals in scala
https://tuttlem.github.io/2015/02/24/xml-literals-in-scala.html
 
An easy protection against tampered XML data vulnerabilities 
is DTD or some other XML schema language. It can at least catch
problems that are in the scope of the schema language.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Different "look and feel" of some built-in functions

On Fri, Sep 24, 2021 at 11:47 PM Steve Keller  wrote:
>
> Why do some built-in Python functions feel so differently:
>
> For example sum(), all(), any() expect exactly one argument which is a
> sequence to operate on, i.e. a list, an iterator or a generator etc.
>
> sum([1,2,3,4])
> sum(range(1, 101))
> sum(2**i for i in range(10))
> all([True, False])
> any(even, {1,2,3,4})
>
> while other functions like set.union() and set.intersection() work on
> a list of arguments but not on a sequence:
>
> set.intersection({1,2,3}, {3,4,5})
>
> but
>
> set.union(map(...))   # does not work
> set.intersection(list(...))   # does not work
>
> and you have to use a * instead
>
> set.union(*map(...))
>
> etc.
>
> Is this just for historical reason?  And wouldn't it be possible and
> desirable to have more consistency?
>

The ones you're calling off the set class are actually meant to be methods.

>>> s = {1,2,3}
>>> s.intersection({3,4,5})
{3}

They expect a set, specifically, as the first argument, because
normally that one goes before the dot. If you want to call the unbound
method with two arguments, that's fine, but it's not the intended use,
so you have to basically fudge it to look like a normal method call :)
That's why it doesn't take a sequence.

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

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



STINNER Victor  added the comment:

Calling Py_FatalError() must be avoided by any mean. I spent significant time 
to remove Py_FatalError() at Python startup in my PEP 587 implementation: 
https://www.python.org/dev/peps/pep-0587/

I also removed Py_FatalError() calls to report errors to the caller: 
https://bugs.python.org/issue38631

Calling Py_FatalError() is really bad when Python is embedded in an 
application. It kills the whole process, the caller has no way to catch the 
error.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



STINNER Victor  added the comment:

I created PR #28548 to remove the Py_FatalError() code path.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27



Change by STINNER Victor :


--
pull_requests: +26931
pull_request: https://github.com/python/cpython/pull/28548

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Type annotation pitfall

On Fri, Sep 24, 2021 at 11:43 PM Peter Saalbrink
 wrote:
>
> I don't think this has anything to do with typing or providing type hints.
> The type hint is the `: set` part, not the `= set()` part.
> You can declare the type without assigning to the variable.
> Indeed, as you already said, `x` is a class property here, and is shared
> amongst instances of the class.
> It might be a good idea to move the attribute assignment to the `__init__`
> method.
>
> In the following way, you can safely provide the type hint:
>
> ```python
> class Foo:
> x: set
>
> def __init__(self, s):
> self.x = set()
> if s:
> self.x.add(s)
> ```
>

To be clear, this isn't a case of "never use mutables as class
attributes"; often you *want* a single mutable object to be shared
among instances of a class (so they can all find each other, perhaps).
If you want each instance to have its own set, you construct a new set
every object initialization; if you want them to all use the same set,
you construct a single set and attach it to the class. Neither is
wrong, they just have different meanings.

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

Re: Flush / update GUIs in PyQt5 during debugging in PyCharm

2021-09-24 Thread DFS


On 9/24/2021 12:46 AM, Mohsen Owzar wrote:

Hi Guys
I've written a GUI using PyQt5 and in there I use StyleSheets (css) for the 
buttons and labels to change their background- and foreground-colors and their 
states as well.
Because my program doesn't function correctly, I try to debug it in my IDE 
(PyCharm).
The problem is that during debugging, when I change some attributes of a button 
or label, let say its background-color, I can not see this modification of the 
color until the whole method or function is completed.
I believe that I have seen somewhere during my searches and googling that one 
can flush or update the GUI after each step/action is done.
But until now I couldn't manage it and I don't know where I have to invoke 
flush/update command in PyCharm.
If anyone has done this before and knows about it, I would very appreciate 
seeing his solution.

Regards
Mohsen



screen:
form.repaint()

individual widgets:
form.widget.repaint()


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

Different "look and feel" of some built-in functions

2021-09-24 Thread Steve Keller

Why do some built-in Python functions feel so differently:

For example sum(), all(), any() expect exactly one argument which is a
sequence to operate on, i.e. a list, an iterator or a generator etc.

sum([1,2,3,4])
sum(range(1, 101))
sum(2**i for i in range(10))
all([True, False])
any(even, {1,2,3,4})

while other functions like set.union() and set.intersection() work on
a list of arguments but not on a sequence:

set.intersection({1,2,3}, {3,4,5})

but

set.union(map(...))   # does not work
set.intersection(list(...))   # does not work

and you have to use a * instead

set.union(*map(...))

etc.

Is this just for historical reason?  And wouldn't it be possible and
desirable to have more consistency?

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

Re: Type annotation pitfall


On 24/09/21 5:48 pm, Robert Latest wrote:

Never use mutable types in type hint,


No, the lesson is: Don't mutate a shared object if you don't want
the changes to be shared.

If you want each instance to have its own set object, you need to
create one for it in the __init__ method, e.g.

class Foo():
 x : set

 def __init__(self, s):
 self.x = set()
 if s:
 self.x.add(s)

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

[issue45283] Top / function argument level ClassVar should not be allowed during `get_type_hints()`

2021-09-24 Thread Nikita Sobolev



New submission from Nikita Sobolev :

This code currently does not raise any issues:

```python
# contents of `ex.py`
from typing import ClassVar

a: ClassVar[int] = 1
def b(c: ClassVar[int]): ...
```

And then: 
1. Module: `python -c 'import ex; from typing import get_type_hints; 
print(get_type_hints(ex))'`
2. Function argument: `python -c 'import ex; from typing import get_type_hints; 
print(get_type_hints(ex.b))'`

It should not be allowed. Currently, the same with `from __future__ import 
annotations` does correctly raise `TypeError: typing.ClassVar[int] is not valid 
as type argument`

Related: https://github.com/python/cpython/pull/28279

I will send a PR with the fix shortly.

--
components: Library (Lib)
messages: 402563
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Top / function argument level ClassVar should not be allowed during 
`get_type_hints()`
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Type annotation pitfall

2021-09-24 Thread Peter Saalbrink

I don't think this has anything to do with typing or providing type hints.
The type hint is the `: set` part, not the `= set()` part.
You can declare the type without assigning to the variable.
Indeed, as you already said, `x` is a class property here, and is shared
amongst instances of the class.
It might be a good idea to move the attribute assignment to the `__init__`
method.

In the following way, you can safely provide the type hint:

```python
class Foo:
x: set

def __init__(self, s):
self.x = set()
if s:
self.x.add(s)
```

Or, even shorter:

```python
class Foo:
def __init__(self, s: str):
self.x: set[str] = {s} if s else set()

print(reveal_type(Foo.x))  # mypy only
```

On Fri, Sep 24, 2021 at 7:58 AM Robert Latest via Python-list <
python-list@python.org> wrote:

> Hi all,
>
> this just caused me several hours of my life until I could whittle it down
> to
> this minimal example. Simple question: Why is the x member of object "foo"
> modified by initializing "bar"?
>
> Obviously, initializing foo with None doesn't set foo.x at all. So I guess
> x
> stays a class property, not an instance property. And instantiating bar
> just
> added an item to the class property but didn't instantiate a new set. So
> basically, neither foo nor bar ever had their "own" x, right?
>
> Oooohh, dangerous! Never use mutable types in type hint, unless it's in
> explicit dataclasses (which automatically add an appropriate __init__()?)
>
> Now I must fine-comb all my code for more of these.
>
> class Foo():
> x : set = set()
>
> def __init__(self, s):
> if s:
> self.x.add(s)
>
> foo = Foo(None)
> print(foo.x) # prints 'set()'
> bar = Foo('abc')
> print(foo.x) # prints '{'abc'}
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45282] isinstance(x, typing.Protocol-class) unexpectedly evaluates properties

2021-09-24 Thread Daisuke Takahashi



New submission from Daisuke Takahashi :

Because __instancecheck__ of _ProtocolMeta uses hasattr() and getattr(), both 
of which evaluate property attributes, calling isinstance() with an object and 
a class that inherits typing.Protocol evaluates the input object's properties 
in some cases.

The attached testcases include three cases of checking subtype relationship of 
an instance (having a property "x" that may raise RuntimeError on evaluation) 
and following three protocol classes;
  (1) a protocol class having "x" as a property,
  (2) a protocol class having "x" as a data attribute, and
  (3) a protocol class having "x" as a class property that raises
   RuntimeError on evaluation (>= python 3.9 only).

Expected behavior:
1. The isinstance(obj, Protocol_class) does not evaluate anything but just 
checks existence of attribute names.
2. All cases in the attached testcases run without any error

Thank you very much in advance.

--
files: test_protocol_property.py
messages: 402562
nosy: daitakahashi
priority: normal
severity: normal
status: open
title: isinstance(x, typing.Protocol-class) unexpectedly evaluates properties
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50303/test_protocol_property.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45281] Make `is_attribute` and `module` arguments to `ForwardRef` kw-only

2021-09-24 Thread Nikita Sobolev



New submission from Nikita Sobolev :

After https://github.com/python/cpython/pull/28279 and 
https://bugs.python.org/issue45166 `ForwardRef` and `_type_check` now have 
`is_class` kw-only argument.

It is now inconsistent with `is_argument` and `module` arguments.
It would be quite nice to make them all kw-only.

Quoting @ambv:

> _type_check we can just change in Python 3.11 without any further ado. 
> ForwardRef() will need a deprecation period when the users is calling 
> is_argument= and module= as non-keyword arguments

--
components: Library (Lib)
messages: 402561
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Make `is_attribute` and `module` arguments to `ForwardRef` kw-only
type: behavior
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful



STINNER Victor  added the comment:

Jeremy Maitin-Shepard: "In general, I view hanging threads as the least bad 
thing to do when faced with either acquiring the GIL or not returning at all.  
There is a lot of existing usage of Python that currently poses a risk of 
random crashes and memory corruption while Python is exiting, and I would like 
to fix that."

Showing warnings by default or not was discussed many times in Python. It was 
decided to *hide* DeprecationWarning by default. The PEP 565 is a minor 
trade-off to show them in the __main__ module.

For me, more generally, Python default behavior is designed for *users* who 
don't want to be annoyed by warnings or anything which would make sense for 
*developers*. That's why I designed a new "Python Development Mode" (-X dev):
https://docs.python.org/dev/library/devmode.html

Maybe in development mode, the behavior could be changed to call abort(). But 
honestly, I'm not really excited by that. I'm not embedding Python in a C++ 
application. I'm almot only use Python directly: the Unix command "python3". 
For this use case, IMO it's fine to call pthread_exit() by default.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful



STINNER Victor  added the comment:

Another example where a developer asks to call abort() to notice bugs, whereas 
Python previously silently ignored it: bpo-36829. Calling abort() is a legit 
use case, but not really the best default behavior. Again, the problem was 
solved by letting developers setting their own callback: sys.unraisablehook.

If I understood correctly, pytest doesn't override it but "took" into the 
default implementation: it chains its own code with the default implementation. 
It's possible because there is a way to "get" the current hook: just read 
sys.unraisablehook ;-)

Another argument in favor of also adding Py_GetThreadExitCallback() ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful



STINNER Victor  added the comment:

Gregory P. Smith: Python has many API using callbacks:

PEP 445 added PyMem_SetAllocator() to set memory allocator. Adding 
PyMem_GetAllocator() also made possible to chain allocators and to "hook" into 
an existing allocator to execute code before and after it's called (the PEP 
contains an example).

I'm not sure if it's important or useless to chain callbacks with 
Py_SetThreadExitCallback(). I suggest to always override the previously set 
callback.

It would matter if library A sets a callback to emit log and library B sets a 
callback to hang threads. It maybe be nice to first emit a log and then hang 
the thread. But then the order in which callbacks are set starts to matter a 
lot :-)

I'm fine with adding Py_GetThreadExitCallback() if you consider that it matters.


> If someone passes nullptr does that undo it (please no!).

I don't think that we should bother with adding a special case. I prefer to 
consider developers as adults and let them make their own mistakes if they 
consider that they understand the code well enough ;-)

_PyEval_SetTrace() allows to remove the current trace function. It's a legit 
use case.

If library C is annoyed by library A and library B installed annoying 
callbacks, IMO it's also ok to let it "remove" the previously set callback, no?

IMO Py_SetThreadExitCallback(NULL) should simply set the callback to NULL, so 
restore the default behavior: call pthread_exit().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45280] Empty typing.NamedTuple creation is not tested

2021-09-24 Thread Nikita Sobolev



New submission from Nikita Sobolev :

While working on `mypy` support of `NamedTuple`s 
(https://github.com/python/mypy/issues/11047), I've noticed that currently when 
testing `typing.NamedTuple` cases like:

1. `N = NamedTuple('N')`

and

2.

```python
class N(NamedTuple):
...
```

are ignored. 

However, this is an important corner-cases, we need to be sure that use can 
create empty named tuples if needed.

Related position in code: 
https://github.com/python/cpython/blob/3f8b23f8ddab75d9b77a3997d54e663187e12cc8/Lib/test/test_typing.py#L4102-L4114

I will send a PR add these two cases.

--
components: Tests
messages: 402557
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Empty typing.NamedTuple creation is not tested
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful