[issue42222] Modernize integer test/conversion in randrange()

2020-12-24 Thread Raymond Hettinger


Change by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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



[issue37779] configparser: add documentation about several read() behaviour

2020-12-24 Thread Stéphane Blondon

Stéphane Blondon  added the comment:

Merged by Łukasz Langa in september 2020.
(Thanks Łukasz)

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Paul Sokolovsky


New submission from Paul Sokolovsky :

Currently, it's possible:

* To get from stream-of-characters program representation to AST representation 
(AST.parse()).
* To get from AST to code object (compile()).
* To get from a code object to first-class function to the execute the program.

Python also offers "tokenize" module, but it stands as a disconnected island: 
the only things it allows to do is to get from stream-of-characters program 
representation to stream-of-tokens, and back. At the same time, conceptually, 
tokenization is not a disconnected feature, it's the first stage of language 
processing pipeline. The fact that "tokenize" is disconnected from the rest of 
the pipeline, as listed above, is more an artifact of CPython implementation: 
both "ast" module and compile() module are backed by the underlying bytecode 
compiler implementation written in C, and that's what connects them.

On the other hand, "tokenize" module is pure-Python, while the underlying 
compiler has its own tokenizer implementation (not exposed). That's the likely 
reason of such disconnection between "tokenize" and the rest of the 
infrastructure.

I propose to close that gap, and establish an API which would allow to parse 
token stream (iterable) into an AST. An initial implementation for CPython can 
(and likely should) be naive, making a loop thru surface program 
representation. That's ok, again, the idea is to establish a standard API to be 
able to go tokens -> AST, then individual Python implementation can 
make/optimize it based on their needs.

The proposed name is ast.parse_tokens(). It follows the signature of the 
existing ast.parse(), except that first parameter is "token_stream" instead of 
"source".

Another alternative would be to overload existing ast.parse() to accept token 
iterable. I guess, at the current stage, where we try to tighten up type 
strictness of API, and have clear typing signatures for API functions, this is 
not favored solution.

--
components: Library (Lib)
messages: 383680
nosy: BTaskaya, pablogsal, pfalcon, serhiy.storchaka
priority: normal
severity: normal
status: open
title: tokenize, ast: No direct way to parse tokens into AST, a gap in the 
language processing pipiline
versions: Python 3.10

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Paul Sokolovsky


Change by Paul Sokolovsky :


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

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Batuhan Taskaya


Batuhan Taskaya  added the comment:

> I propose to close that gap, and establish an API which would allow to parse 
> token stream (iterable) into an AST. An initial implementation for CPython 
> can (and likely should) be naive, making a loop thru surface program 
> representation. 

There is different aspects of this problem (like maintenance cost of either 
exposing the underlying tokenizer, or building something like Python-ast.c to 
convert these 2 different token types back and forth which I'm big -1 on both 
of them.) but the thing I don't quite get is the use case. 

What prevents you from using ast.parse(tokenize.untokenize(token_stream))? It 
is guaranteed that you won't miss anything (in terms of the position of tokens) 
(since it almost roundtrips every case). 

Also, tokens -> AST is not the only disconnected part in the underlying 
compiler. Stuff like AST -> Symbol Table / AST -> Optimized AST etc. is also 
not available, and apparently not needed (since nobody else, maybe except me 
[about the AST -> ST conversion], complained about these being missing). 

I'd also suggest moving the discussion to the Python-ideas, for a much greater 
audience.

--
stage: patch review -> 

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Paul Sokolovsky


Paul Sokolovsky  added the comment:

> What prevents you from using ast.parse(tokenize.untokenize(token_stream))?

That's exactly the implementation in the patch now submitted against this 
issue. But that's the patch for CPython, the motive of the proposal here is to 
establish a standard API call for *Python*, which different implementation can 
implement how they like/can/need.

> Also, tokens -> AST is not the only disconnected part in the underlying 
> compiler.

We should address them, one by one.

> Stuff like AST -> Symbol Table 

Kinda yes, again, based on CPython implementation history, we have only source 
-> Symbol table (https://docs.python.org/3/library/symtable.html). Would be 
nice to address that (separately of course).

> AST -> Optimized AST

Yes. PEP511 touched on that, but as it-as-a-whole was rejected, any useful 
sub-ideas from it don't seem to get further progress either (like, being able 
to disable some optimizations, and then maybe even exposing them as standalone 
passes).

> I'd also suggest moving the discussion to the Python-ideas, for a much 
> greater audience.

That's how I usually do, but I posted too much there recently. I wanted to 
submit a patch right away, but noticed that standard commit message format is 
"bpo-X: ...", so I created a ticket here to reference in the commit.

--

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Paul Sokolovsky


Paul Sokolovsky  added the comment:

> but the thing I don't quite get is the use case.

And if that went unanswered: the usecase, how I'd formulate it, is to not 
expose CPython historical implementation detail of "tokenize" being 
disconnected from the rest of the language processing infrastructure, and make 
them learn tricks like needing to go back to character program form if they 
ever start to use "tokenize", but let it all integrate well into single 
processing pipeline.

--

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Batuhan Taskaya


Batuhan Taskaya  added the comment:

> That's exactly the implementation in the patch now submitted against this 
> issue. But that's the patch for CPython, the motive of the proposal here is 
> to establish a standard API call for *Python*, which different implementation 
> can implement how they like/can/need.

I don't feel great about it, but if you are final motive is to address this 
issue for other implementations (like pycopy?), I still think that Python-ideas 
is the best place to discuss it rather than the bugtracker of CPython.

> We should address them, one by one.

I am not sure about that, IIRC @pablogsal and I talked these about a year ago 
and decided that there won't be any clear benefit (since nobody come with a 
need to it) and there will the downside of sometimes limiting ourselves for 
being backward-compatible for an API that ~almost no one will use.

> That's how I usually do, but I posted too much there recently. I wanted to 
> submit a patch right away, but noticed that standard commit message format is 
> "bpo-X: ...", so I created a ticket here to reference in the commit.

What people does in this cases is, they push to their branches with a random 
commit message (Implement blabla) and then share the link to the branch on 
their post in the Python-ideas.

--

___
Python tracker 

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



[issue42643] http.server does not support HTTP range requests

2020-12-24 Thread Stéphane Blondon

Stéphane Blondon  added the comment:

RangeHTTPServer seems to support python3: there is a try-except clause to 
manage the different import of SimpleHTTPServer:
https://github.com/danvk/RangeHTTPServer/blob/master/RangeHTTPServer/__main__.py#L13

The code is under Apache 2.0 licence. I don't know if it can be integrated in 
codebase under the PSF licence.

Another question needs to be answered previously: does the maintainers want to 
add such feature to SimpleHTTPServer (which goal is to be very basic)? They 
could prefer to add a header refusing the Range header:
Accept-Ranges: none

https://tools.ietf.org/id/draft-ietf-httpbis-p5-range-09.html#header.accept-ranges

--
nosy: +sblondon

___
Python tracker 

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



[issue42725] PEP 563: Should the behavior change for yield/yield from's

2020-12-24 Thread Lysandros Nikolaou


Lysandros Nikolaou  added the comment:

I concur with Guido. I feel that making this an error is the best alternative 
we have.

--

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Lysandros Nikolaou


Lysandros Nikolaou  added the comment:

The thing is that the parser itself does not get a stream of tokens as input. 
It only accepts either a file or a string and it lazily converts its input to 
tokens.

As for the PR attached to this patch, I'm -1 on that. I don't think the usecase 
is common enough for us to have another public function, that we need to 
maintain and keep backwards-compatible. I concur with Batuhan that if people 
need this, they can use ast.parse with tokenize.untokenize.

--
nosy: +lys.nikolaou

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

I am with Lysandros and Batuhan. The parser is considerably coupled with the C 
tokenizer and the only way to reuse *the parser* is to make flexible enough to 
receive a token stream of Python objects as input and that can not only have a 
performance impact on normal parsing but also raises the complexity of this 
task considerably, especially taking into account that the use case is quite 
restricted and is something that you can already achieve by transforming the 
token stream into text and using ast.parse.

There is a considerable tension on exposed parts of the compiler pipeline for 
introspection and other capabilities and our ability to do optimizations. Given 
how painful it has been in the past to deal with this, my view is to avoid 
exposing as much as possible anything in the compiler pipeline, so we don't 
shoot ourselves in the foot in the future if we need to change stuff around.

--

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Paul Sokolovsky


Paul Sokolovsky  added the comment:

> There is a considerable tension on exposed parts of the compiler pipeline for 
> introspection and other capabilities and our ability to do optimizations. 
> Given how painful it has been in the past to deal with this, my view is to 
> avoid exposing as much as possible anything in the compiler pipeline, so we 
> don't shoot ourselves in the foot in the future if we need to change stuff 
> around.

That's somewhat extreme outcome when a problem is known and understood, but the 
best solution is deemed not doing anything.

But the problem of "doing it wrong" definitely known and exists. One known way 
to address it is to design generic interfaces and implement them. This ticket 
is exactly about that - defining a missing interface for a parser in Python. 
It's not about *the* CPython's C parser and its peculiarities. (But even it 
fits with the generic interface proposed.)

--

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

I concur with other core developers. Seems there is no real need for this 
feature and the idea was proposed purely to "close a gap". Taking into account 
significant cost of implementing and maintaining this feature, I think that it 
should not be added.

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Paul Sokolovsky


Paul Sokolovsky  added the comment:

> the idea was proposed purely to "close a gap"

That pinpoints it well. I was just writing a tutorial on implementing custom 
import hooks, with the idea to show people how easy it to do it in Python. As 
first step, I explained that it's bad idea to do any transformations on surface 
representation of a program. At the very least, it should be converted to token 
stream. But then I found that I need to explain that we need to convert it 
back, which sounds pretty weird and undermines the idea:

def xform(token_stream):
for t in token_stream:
if t[0] == tokenize.NAME and t[1] == "function":
yield (tokenize.NAME, "lambda") + t[2:]
else:
yield t

with open(filename, "rb") as f:
# Fairly speaking, tokenizing just to convert back to string form
# isn't too efficient, but CPython doesn't offer us a way to parse
# token stream so far, so we have no choice.
source = tokenize.untokenize(xform(tokenize.tokenize(f.readline)))
mod = type(imphook)("")
exec(source, vars(mod))
return mod

Having written that comment, I thought I could as well just make one more step 
and monkey-patch "ast" for parse_tokens() function - I'll need to explain that, 
but the explanation probably wouldn't sound worse than the explanation above. 
And then it was just one more step to actually submit patch for 
ast.parse_tokens(), and that's how this ticket was created!

--

___
Python tracker 

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



[issue42729] tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline

2020-12-24 Thread Batuhan Taskaya


Batuhan Taskaya  added the comment:

Thank you for your patch though!

--

___
Python tracker 

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



[issue42725] PEP 563: Should the behavior change for yield/yield from's

2020-12-24 Thread Guido van Rossum


Guido van Rossum  added the comment:

Okay, let's do it. It should probably a post-parse check (before we invoke the 
bytecode compiler but after we have the AST in hand).

--

___
Python tracker 

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



[issue42726] gdb/libpython.py InstanceProxy does not work with py3

2020-12-24 Thread miss-islington


miss-islington  added the comment:


New changeset b57ada98da0d5b0cf1ebc2c9c5502d04aa962042 by Augusto Hack in 
branch 'master':
closes bpo-42726: gdb libpython: InstanceProxy support for py3 (GH-23912)
https://github.com/python/cpython/commit/b57ada98da0d5b0cf1ebc2c9c5502d04aa962042


--
nosy: +miss-islington
resolution:  -> 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



[issue42726] gdb/libpython.py InstanceProxy does not work with py3

2020-12-24 Thread miss-islington


Change by miss-islington :


--
pull_requests: +22775
pull_request: https://github.com/python/cpython/pull/23924

___
Python tracker 

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



[issue42726] gdb/libpython.py InstanceProxy does not work with py3

2020-12-24 Thread miss-islington


Change by miss-islington :


--
pull_requests: +22776
pull_request: https://github.com/python/cpython/pull/23925

___
Python tracker 

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



[issue42730] TypeError in Time.Sleep when invoked from shell script background

2020-12-24 Thread Abdulrahman Alabdulkareem


New submission from Abdulrahman Alabdulkareem :

I get a random TypeError exception thrown whenever I interrupt/kill a sleeping 
parent thread from a child thread but ONLY if the python script was invoked by 
a shell script with an & argument to make it run in the background. (this is in 
vanilla python)

This doesn't happen if invoked 

(1) in command line
(2) in command line with &
(3) in shell script (without &)

Only in shell script with &.

Here is the python script named psc.py https://pastebin.com/raw/KZQptCMr
And here is the shell script named ssc.sh https://pastebin.com/raw/QQzs4Tpz 
that when ran will run the python script and cause the strange behaviour

Here is the output I'm seeing: ---
parent looping
child interrupting parent
why would I ever catch a TypeError?
Traceback (most recent call last):
  File "m.py", line 17, in 
time.sleep(1)
TypeError: 'int' object is not callable

Here is the output I'm expecting: 
parent looping
child interrupting parent
caught interruption raised from user or child thread :)

Another unexpected behaviour might be that python suddenly hangs.

Here is a stackoverflow question raised on this issue with discussion in the 
comments 
https://stackoverflow.com/questions/65440353/python-time-sleep1-raises-typeerror?noredirect=1#comment115697237_65440353

--
messages: 383695
nosy: master3243
priority: normal
severity: normal
status: open
title: TypeError in Time.Sleep when invoked from shell script background
versions: Python 3.7

___
Python tracker 

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



[issue42726] gdb/libpython.py InstanceProxy does not work with py3

2020-12-24 Thread miss-islington


miss-islington  added the comment:


New changeset efd64c8ea0fed1c13839cec0feea450820da34f8 by Miss Islington (bot) 
in branch '3.8':
closes bpo-42726: gdb libpython: InstanceProxy support for py3 (GH-23912)
https://github.com/python/cpython/commit/efd64c8ea0fed1c13839cec0feea450820da34f8


--

___
Python tracker 

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



[issue42726] gdb/libpython.py InstanceProxy does not work with py3

2020-12-24 Thread miss-islington


miss-islington  added the comment:


New changeset 3bb85672bb894403a787a9c5afc0ca5987d28fe0 by Miss Islington (bot) 
in branch '3.9':
closes bpo-42726: gdb libpython: InstanceProxy support for py3 (GH-23912)
https://github.com/python/cpython/commit/3bb85672bb894403a787a9c5afc0ca5987d28fe0


--

___
Python tracker 

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



[issue36876] [subinterpreters] Global C variables are a problem

2020-12-24 Thread Eric Snow


Eric Snow  added the comment:


New changeset 7ec59d8861ef1104c3028678b2cacde4c5693e19 by Eric Snow in branch 
'master':
bpo-36876: [c-analyzer tool] Add a "capi" subcommand to the c-analyzer tool. 
(gh-23918)
https://github.com/python/cpython/commit/7ec59d8861ef1104c3028678b2cacde4c5693e19


--

___
Python tracker 

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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread Ethan Furman


Change by Ethan Furman :


--
pull_requests: +22777
pull_request: https://github.com/python/cpython/pull/23926

___
Python tracker 

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



[issue42685] Improve placing of simple query windows.

2020-12-24 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:


New changeset c6c43b28746b0642cc3c49dd8138b896bed3028f by Serhiy Storchaka in 
branch 'master':
bpo-42685: Improve placing of simple query windows. (GH-23856)
https://github.com/python/cpython/commit/c6c43b28746b0642cc3c49dd8138b896bed3028f


--

___
Python tracker 

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



[issue35815] Able to instantiate a subclass with abstract methods from __init_subclass__ of the ABC

2020-12-24 Thread Ethan Furman


Ethan Furman  added the comment:

I tried update `abc.py` with the same dance I have to use with `Enum`:

def __new__(mcls, name, bases, namespace, **kwargs):
# remove current __init_subclass__ so previous one can be found with 
getattr
try:
new_init_subclass = namespace.get('__init_subclass__')
del namespace['__init_subclass__']
except KeyError:
pass
# create our new ABC type
if bases:
bases = (_NoInitSubclass, ) + bases
abc_cls = super().__new__(mcls, name, bases, namespace, **kwargs)
abc_cls.__bases__ = abc_cls.__bases__[1:]
else:
abc_cls = super().__new__(mcls, name, bases, namespace, **kwargs)
old_init_subclass = getattr(abc_cls, '__init_subclass__', None)
# restore new __init_subclass__ (if there was one)
if new_init_subclass is not None:
abc_cls.__init_subclass__ = classmethod(new_init_subclass)
_abc_init(abc_cls)
# call parents' __init_subclass__
if old_init_subclass is not None:
old_init_subclass(**kwargs)
return abc_cls

But I get this error:

Fatal Python error: init_import_site: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
  File "/home/ethan/source/python/cpython/Lib/site.py", line 73, in 
import os
  File "/home/ethan/source/python/cpython/Lib/os.py", line 29, in 
from _collections_abc import _check_methods
  File "/home/ethan/source/python/cpython/Lib/_collections_abc.py", line 122, 
in 
class Coroutine(Awaitable):
  File "/home/ethan/source/python/cpython/Lib/abc.py", line 103, in __new__
abc_cls.__bases__ = abc_cls.__bases__[1:]
TypeError: __bases__ assignment: 'Awaitable' object layout differs from 
'_NoInitSubclass'

--

___
Python tracker 

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



[issue42731] Enhancement request for proxying PyString

2020-12-24 Thread Karl Nelson


New submission from Karl Nelson :

When developing with JPype, the largest hole currently is that Java returns a 
string type which cannot be represented as a str.  Java strings are string like 
and immutable and can be pulled to Python when needed, but it is best if they 
remain in Java until Python requests it as pulling all string values through 
the API and pushing them back can result in serious overhead.  Thus they need 
to be represented as a Proxy to a string, which can be accessed as a string at 
anytime.

Throughout the Python API str is treated as a concrete type (though it is 
somewhat polymorphic due to different storage for code points sizes.)  There is 
also handling for an "unready" string which needs additional treatment before 
it can be accessed.  Unfortunately this does not appear to be suitable for 
creating a proxy object which can be pulled from another source to create a 
string on demand.   Having a "__str__()" method is insufficient as that merely 
makes an object able to become a string rather than considered to be a string 
by the rest of the API.

Would it be possible to generalize the concept of an unready string so that 
when Ready is called it fetches the actually string contents, creates a piece 
of memory to store the string contents (outside of the object itself), and sets 
the access flags for so that the code points can be interpreted?   Is this 
already possible in the API?  Are there any other plans to make the str type 
able to operate as a proxy?

--
components: Extension Modules
messages: 383701
nosy: Thrameos
priority: normal
severity: normal
status: open
title: Enhancement request for proxying PyString
versions: Python 3.10

___
Python tracker 

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



[issue42730] TypeError/hang inside of Time.Sleep() when _thread.interrupt_main()

2020-12-24 Thread Abdulrahman Alabdulkareem


Change by Abdulrahman Alabdulkareem :


--
title: TypeError in Time.Sleep when invoked from shell script background -> 
TypeError/hang inside of Time.Sleep() when _thread.interrupt_main()

___
Python tracker 

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



[issue42732] Buildbot s390x Fedora LTO + PGO 3.x fails intermittently

2020-12-24 Thread Ken Jin


New submission from Ken Jin :

Dear core developers, I noticed that for many recent commits, the s390x Fedora 
LTO + PGO 3.x buildbot often fails. Here's an error log::


gcc -pthread   -fno-semantic-interposition -flto -fuse-linker-plugin 
-ffat-lto-objects -flto-partition=none -g  -Xlinker -export-dynamic -o python 
Programs/python.o libpython3.10.a -lcrypt -lpthread -ldl  -lutil -lm   -lm 
gcc -pthread   -fno-semantic-interposition -flto -fuse-linker-plugin 
-ffat-lto-objects -flto-partition=none -g  -Xlinker -export-dynamic -o 
Programs/_testembed Programs/_testembed.o libpython3.10.a -lcrypt -lpthread 
-ldl  -lutil -lm   -lm 
/usr/bin/ld: python.lto.o: in function `run_mod':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/pythonrun.c:1230:
 undefined reference to `PyAST_CompileObject'
/usr/bin/ld: python.lto.o: in function `builtin_compile':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/bltinmodule.c:808:
 undefined reference to `PyAST_CompileObject'
/usr/bin/ld: python.lto.o: in function `Py_CompileStringObject':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/pythonrun.c:1307:
 undefined reference to `PyAST_CompileObject'
/usr/bin/ld: python.lto.o: in function `symtable_lookup':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/symtable.c:1004:
 undefined reference to `_Py_Mangle'
/usr/bin/ld: python.lto.o: in function `symtable_record_directive':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/symtable.c:1161:
 undefined reference to `_Py_Mangle'
/usr/bin/ld: python.lto.o: in function `type_new':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Objects/typeobject.c:2544:
 undefined reference to `_Py_Mangle'
/usr/bin/ld: python.lto.o: in function `symtable_add_def_helper':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/symtable.c:1018:
 undefined reference to `_Py_Mangle'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:592: python] Error 1
make[1]: *** Waiting for unfinished jobs

[.. I truncated the rest]

I have a hunch the error is caused by a lack of the '-fprofile-generate' flag 
for the first two gcc commands. The only issue is that it's sometimes there, 
and sometimes not, and I'm not familiar enough with the buildbot code to find 
out why. Sorry.

Eg. this commit 
https://github.com/python/cpython/commit/cc3467a57b61b0e7ef254b36790a1c44b13f2228
 has s390x Fedora LTO + PGO 3.x succeeding, the 2 gcc lines also have the 
'-fprofile-generate' flag.

This commit 
https://github.com/python/cpython/commit/c6c43b28746b0642cc3c49dd8138b896bed3028f
 has s390x Fedora LTO + PGO 3.x failing, the 2 gcc lines have a blank space in 
place of the '-fprofile-generate' flag.

I could also be completely wrong and off track, so please feel free to correct 
me :), thanks.

--
components: Demos and Tools
messages: 383702
nosy: kj, pablogsal, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Buildbot s390x Fedora LTO + PGO 3.x fails intermittently
versions: Python 3.10, 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



[issue32501] Documentation for dir([object])

2020-12-24 Thread Ethan Furman


Change by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

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



[issue32768] object.__new__ does not accept arguments if __bases__ is changed

2020-12-24 Thread Ethan Furman


Ethan Furman  added the comment:

A use-case for writable bases:

__init_subclass__ is called in type.__new__, which means that for Enum 
__init_subclass__ is called before the members have been added.  To work around 
this I am currently (3.10) adding in a _NoInitSubclass to the bases before 
type.__new__ is called, and then removing it.

A better solution to that problem would be a way to tell type.__new__ /not/ to 
call __init_subclass__, but I don't have that option at this point.

--
nosy: +ethan.furman

___
Python tracker 

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



[issue38397] __init_subclass__ causes TypeError when used with more standard library metaclasses (such as EnumMeta)

2020-12-24 Thread Ethan Furman


Ethan Furman  added the comment:

I just added **kwds to EnumMeta -- can this be closed?

--
nosy: +ethan.furman

___
Python tracker 

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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread Ethan Furman


Ethan Furman  added the comment:


New changeset f7dca9b9c864c1b7807014ea21a30cac76727e8b by Ethan Furman in 
branch '3.9':
[3.9] bpo-42727: [Enum] EnumMeta.__prepare__ now accepts **kwds (GH-23917). 
(GH-23926)
https://github.com/python/cpython/commit/f7dca9b9c864c1b7807014ea21a30cac76727e8b


--

___
Python tracker 

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



[issue42732] Buildbot s390x Fedora LTO + PGO 3.x fails intermittently

2020-12-24 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

Isn't this the same as the problem described in 
https://bugs.python.org/issue42164 ?

--

___
Python tracker 

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



[issue41644] builtin type kwargs

2020-12-24 Thread Ethan Furman


Change by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

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



[issue42674] __init_subclass__ only called for first subclass when class has multiple inheritance

2020-12-24 Thread Ethan Furman


New submission from Ethan Furman :

The two subclasses in the test script are not calling super().  When they do, 
both __init_subclasses__ are called.

--
nosy: +ethan.furman
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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread Ethan Furman


Change by Ethan Furman :


--
pull_requests: +22778
pull_request: https://github.com/python/cpython/pull/23927

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Mark Diekhans


Mark Diekhans  added the comment:

calling setpgid() is a common post-fork task that would need to be an explicit 
parameter to Popen when preexec_fn goes away

--
nosy: +diekhans

___
Python tracker 

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



[issue36876] [subinterpreters] Global C variables are a problem

2020-12-24 Thread Eric Snow


Change by Eric Snow :


--
pull_requests: +22779
pull_request: https://github.com/python/cpython/pull/23929

___
Python tracker 

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



[issue42732] Buildbot s390x Fedora LTO + PGO 3.x fails intermittently

2020-12-24 Thread Ken Jin


Ken Jin  added the comment:

Oops, you're right! Sorry, I'll close this issue. Anyways I realized I had the 
wrong hunch - I was looking at a different part of the logs.

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Change by Gregory P. Smith :


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

___
Python tracker 

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



[issue42733] [issue] io's r+ mode truncate(0)

2020-12-24 Thread 施文峰

New submission from 施文峰 :

happen at io's reading & updating(r+) mode
after read,
file object's postion stay in last if you remove whole content ( truncate(0) ),
postion wil not back to 0 still stay in the last
then you start writing from last position(not 0)
that's why problem happen

test case can check here https://github.com/841020/open_source

--
components: IO
files: Screenshot from 2020-12-25 10-46-42.png
hgrepos: 396
messages: 383710
nosy: ke265379ke
priority: normal
severity: normal
status: open
title: [issue] io's r+ mode truncate(0)
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49697/Screenshot from 2020-12-25 
10-46-42.png

___
Python tracker 

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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread Ethan Furman


Ethan Furman  added the comment:


New changeset 786d97a66cac48e7a933010367b8993a5b3ab85b by Ethan Furman in 
branch 'master':
bpo-42727: [Enum] use super() and include **kwds (GH-23927)
https://github.com/python/cpython/commit/786d97a66cac48e7a933010367b8993a5b3ab85b


--

___
Python tracker 

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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread miss-islington


Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +22781
pull_request: https://github.com/python/cpython/pull/23931

___
Python tracker 

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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread Gregory P. Smith


Change by Gregory P. Smith :


--
nosy: +gregory.p.smith
nosy_count: 2.0 -> 3.0
pull_requests: +22782
pull_request: https://github.com/python/cpython/pull/23932

___
Python tracker 

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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:


New changeset 8badadec53cbf9dc049c5b54198c5689481e3f3f by Gregory P. Smith in 
branch 'master':
bpo-42727: Fix the NEWS entry .rst (GH-23932)
https://github.com/python/cpython/commit/8badadec53cbf9dc049c5b54198c5689481e3f3f


--

___
Python tracker 

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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread miss-islington


Change by miss-islington :


--
pull_requests: +22783
pull_request: https://github.com/python/cpython/pull/23933

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Change by Gregory P. Smith :


--
versions: +Python 3.10 -Python 3.9

___
Python tracker 

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



[issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds

2020-12-24 Thread miss-islington


miss-islington  added the comment:


New changeset 5a6b5d8c392ca7028e7c034710a89492cd704778 by Miss Islington (bot) 
in branch '3.9':
bpo-42727: Fix the NEWS entry .rst (GH-23932)
https://github.com/python/cpython/commit/5a6b5d8c392ca7028e7c034710a89492cd704778


--

___
Python tracker 

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



[issue42388] subprocess.check_output(['echo', 'test'], text=True, input=None) fails

2020-12-24 Thread miss-islington


Change by miss-islington :


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

___
Python tracker 

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



[issue42388] subprocess.check_output(['echo', 'test'], text=True, input=None) fails

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:


New changeset 64abf373444944a240274a9b6d66d1cb01ecfcdd by Gregory P. Smith in 
branch 'master':
bpo-42388: Fix subprocess.check_output input=None when text=True (GH-23467)
https://github.com/python/cpython/commit/64abf373444944a240274a9b6d66d1cb01ecfcdd


--

___
Python tracker 

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



[issue42388] subprocess.check_output(['echo', 'test'], text=True, input=None) fails

2020-12-24 Thread miss-islington


Change by miss-islington :


--
pull_requests: +22785
pull_request: https://github.com/python/cpython/pull/23935

___
Python tracker 

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



[issue42388] subprocess.check_output(['echo', 'test'], text=True, input=None) fails

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

Meta issue behind this one: The input= behavior on check_output is yet another 
unfortunate wart in the subprocess collection of APIs.

PR to the main branch is in, 3.9 and 3.8 will automerge after CI runs.

--
resolution:  -> fixed
stage: patch review -> commit review

___
Python tracker 

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



[issue42730] TypeError/hang inside of Time.Sleep() when _thread.interrupt_main()

2020-12-24 Thread Eryk Sun


Eryk Sun  added the comment:

When a process executes in the background from a non-interactive bash script, 
the initial handler for SIGINT is SIG_IGN (ignore). Prior to 3.7, 
_thread.interrupt_main() tries to trip SIGINT even when the C handler is set to 
SIG_IGN. But Python uses an integer constant for SIG_IGN (named IgnoreHandler 
in Modules/signalmodule.c), and trying to call it is a TypeError. This was 
fixed in 3.7+ to resolve bpo-23395. You've flagged this as an issue with 3.7, 
but the Stack Overflow question is for 3.6. If you're actually using 3.6 
instead of 3.7, this issue should be closed as a duplicate.

To manually enable the normal KeyboardInterrupt exception, call 
signal.signal(signal.SIGINT, signal.default_int_handler).

--
nosy: +eryksun
type:  -> behavior

___
Python tracker 

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



[issue42388] subprocess.check_output(['echo', 'test'], text=True, input=None) fails

2020-12-24 Thread miss-islington


miss-islington  added the comment:


New changeset d5aadb28545fd15cd3517b604a8c7a520abd09c6 by Miss Islington (bot) 
in branch '3.8':
bpo-42388: Fix subprocess.check_output input=None when text=True (GH-23467)
https://github.com/python/cpython/commit/d5aadb28545fd15cd3517b604a8c7a520abd09c6


--

___
Python tracker 

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



[issue42388] subprocess.check_output(['echo', 'test'], text=True, input=None) fails

2020-12-24 Thread miss-islington


miss-islington  added the comment:


New changeset 7acfe4125725e86c982300cf10c0ab791a0783f4 by Miss Islington (bot) 
in branch '3.9':
bpo-42388: Fix subprocess.check_output input=None when text=True (GH-23467)
https://github.com/python/cpython/commit/7acfe4125725e86c982300cf10c0ab791a0783f4


--

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

PR up to add setpgid support.  From what I've come across, some setpgid() users 
can use setsid() already available via start_new_session= instead.  But rather 
than getting into the differences between those, making both available makes 
sense to allow for anyone's case where setsid() isn't desired.

--

___
Python tracker 

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



[issue42734] "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers"

2020-12-24 Thread Xinmeng Xia


New submission from Xinmeng Xia :

In "Python/Lib/test/crashers/README", it said "This directory only contains 
tests for outstanding bugs that cause the
interpreter to segfault. Once the crash is fixed, the test case should be 
moved into an appropriate test." 

The file "bogus_code_obj.py" has been fixed on Python 3.8, 3.9, 3.10. No 
segmentation fault will be caused any more. I think this file should be removed 
from "Python/Lib/test/crashers".

--
components: Library (Lib)
messages: 383721
nosy: xxm
priority: normal
severity: normal
status: open
title: "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers"
type: enhancement
versions: Python 3.10, 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



[issue42735] "trace_at_recursion_limit.py" should be removed from "Python/Lib/test/crashers"

2020-12-24 Thread Xinmeng Xia


New submission from Xinmeng Xia :

In "Python/Lib/test/crashers/", only tests for outstanding bugs that cause the 
interpreter to segfault should be included.

The file "trace_at_recursion_limit.py" has been fixed on Python 3.7, 3.8, 3.9, 
3.10. No segmentation fault will be caused any more. I think this file should 
be removed from "Python/Lib/test/crashers".

--
components: Library (Lib)
messages: 383722
nosy: xxm
priority: normal
severity: normal
status: open
title: "trace_at_recursion_limit.py" should be removed from 
"Python/Lib/test/crashers"
type: enhancement
versions: Python 3.10, 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



[issue42736] Add support for making Linux prctl(...) calls to subprocess

2020-12-24 Thread Gregory P. Smith


New submission from Gregory P. Smith :

Another use of `subprocess preexec_fn=` that I've come across has been to call 
Linux's `prctl` in the child process before the `exec`.

`_libc.prctl(_PR_SET_PDEATHSIG, value)` for example.

Adding a linux_prctl_calls= parameter listing information about which prctl 
call(s) to make in the child before exec would satisfy this needed.

No need to go overboard here, this is a _very_ low level syscall.  users need 
to know what they're doing and will likely abstract use away from actual users 
via a wrapper library.  i.e: Lets not attempt to reinvent the 
https://pythonhosted.org/python-prctl/ interface.

Proposal:

linux_prctl_calls: Sequence[tuple]

Where every tuple indicates one prctl call.  the tuple [0] contains a bool 
indicating if an error returned by that prctl call should be ignored or not.  
the tuple[1:6] contain the five int arguments to be passed to prctl.  If the 
tuple is shorter than 2 elements, the remaining values are assumed 0.

At most, a namedtuple type could be created for this purpose to allow the user 
to use the https://man7.org/linux/man-pages/man2/prctl.2.html argument names 
rather than just blindly listing a tuple.

```
namedtuple('LinuxPrctlDescription',
field_names='check_error, option, arg2, arg3, arg4, arg5',
defaults=(0,0,0,0))
```

This existing helps https://bugs.python.org/issue38435 deprecate preexec_fn.

--
components: Extension Modules, Library (Lib)
messages: 383723
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Add support for making Linux prctl(...) calls to subprocess
type: enhancement
versions: Python 3.10

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

https://bugs.python.org/issue42736 filed to track adding Linux prctl() support.

--

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

Another preexec_fn use to consider:

 resource.setrlimit(resource.RLIMIT_CORE, (XXX, XXX))

Using an intermediate shell script wrapper that changes the rlimit and exec's 
the actual process is also an alternative.

--

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

I'm also seeing a lot of os.setpgrp() calls, though those are more likely able 
to use start_new_session to do setsid() as a dropin replacement.

--

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

signal.signal use case:

Calls to signal.signal(x, y) to sometimes to set a non SIG_DFL behavior on a 
signal.  SIGINT -> SIG_IGN for example.

I see a lot of legacy looking code calling signal.signal in prexec_fn that 
appears to set SIG_DFL for the signals that Python otherwise modifies.  Which 
restore_signals=True should already be doing.

--

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Change by Gregory P. Smith :


--
pull_requests: +22786
pull_request: https://github.com/python/cpython/pull/23936

___
Python tracker 

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



[issue38435] Start the deprecation cycle for subprocess preexec_fn

2020-12-24 Thread Gregory P. Smith


Gregory P. Smith  added the comment:

Doing the code inspection of existing preexec_fn= users within our codebase at 
work is revealing.  But those seem to be the bulk of uses.

I expect this deprecation to take a while.  Ex: if we mark it as 
PendingDeprecationWarning in 3.10, I'd still wait until _at least_ 3.13 to 
remove it.

Code using it often has a long legacy and may be written to run on a wide 
variety of Python versions.  It's painful to do so when features you need in 
order to stop using it are still only in modern versions.

--
components: +Library (Lib)

___
Python tracker 

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