[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread Manfred Kaiser


Manfred Kaiser  added the comment:

RFC-2184 was obsoleted by RFC-2231 (https://www.rfc-editor.org/rfc/rfc2231.html)

There are also no quoted strings, like google uses.

--

___
Python tracker 

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



[issue39045] Segmentation of string

2019-12-13 Thread Lovi


New submission from Lovi <1668151...@qq.com>:

I thought for a long time. I think it's necessary to add a segment method to 
str type or string module. This method is used to split a string into m parts 
and return all cases.

For example:

segment('1234', m=3) -> [('1', '2', '34'), ('1', '23', '4'), ('12', '3', '4')]
segment('12345', m=3) -> [('1', '2', '345'), ('1', '23', '45'), ('1', '234', 
'5'), ('12', '3', '45'), ('12', '34', '5'), ('123', '4', '5')]


I hope this proposal can be adopted.

--
components: Library (Lib)
messages: 358383
nosy: lovi
priority: normal
severity: normal
status: open
title: Segmentation of string
type: enhancement
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



[issue39044] Segfault on build for the master branch

2019-12-13 Thread Joannah Nanjekye


Joannah Nanjekye  added the comment:

Confirmedforgeting to run makedistclean was the problem.

--

___
Python tracker 

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



[issue39044] Segfault on build for the master branch

2019-12-13 Thread Joannah Nanjekye


Joannah Nanjekye  added the comment:

Actually my master had some segfaulting changes that I had moved to it in 
error. Thanks.

Closing this.

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



[issue39044] Segfault on build for the master branch

2019-12-13 Thread Zachary Ware


Zachary Ware  added the comment:

If you updated an unclean checkout, try running `make distclean` before 
configuring and building again; that often clears this kind of thing up.

--
nosy: +zach.ware

___
Python tracker 

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



[issue39044] Segfault on build for the master branch

2019-12-13 Thread Joannah Nanjekye


Change by Joannah Nanjekye :


--
nosy: +pablogsal, vstinner

___
Python tracker 

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



[issue39044] Segfault on build for the master branch

2019-12-13 Thread Joannah Nanjekye


New submission from Joannah Nanjekye :

I just pulled changes from upstream and when I build with:

./configure --with-pydebug && make -j

Am getting a Segmentation fault:

./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
echo "generate-posix-vars failed" ; \
rm -f ./pybuilddir.txt ; \
exit 1 ; \
fi
 CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-g -Og -Wall'   
_TCLTK_INCLUDES='' _TCLTK_LIBS=''   ./python -E ./setup.py  build
Segmentation fault (core dumped)
make: *** [Makefile:614: sharedmods] Error 139

I hope someone else can replicate this on:

o LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 19.04
Release:19.04
Codename:   disco

--
components: Build
messages: 358379
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Segfault on build for the master branch

___
Python tracker 

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



[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread Manfred Kaiser


Manfred Kaiser  added the comment:

thanks for your response. I have found the RFC 
https://tools.ietf.org/html/rfc2184

Gmail creates wrong Headers, which are not rfc-compliant.
The problem is, that many people are using gmail and emails, which were sent 
from Gmail might be wrong.

How can we solve this problem? It is not a Python problem. We can create 
workarrounds. But in my opinion Google has to fix the bug.

--

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-13 Thread Lysandros Nikolaou


Change by Lysandros Nikolaou :


--
pull_requests: +17068
pull_request: https://github.com/python/cpython/pull/17596

___
Python tracker 

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



[issue39043] Add math.fib() generator

2019-12-13 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Sorry, this isn't sufficiently useful or needed to warrant inclusion in the 
standard library.

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-13 Thread Lysandros Nikolaou


Lysandros Nikolaou  added the comment:

There was a bug in my last PR, hopefully I will get a fix some time later today.

The bug is as follows: I only updated the asdl_seq_SET call for an elif without 
an else, if an else is included then the behavior is like before.

After my last PR it looks like this, parsing

2:if a:
3:pass
4:elif b:
5:pass

outputs the following AST:

Module(
body=[
If(
test=Name(id="a", ctx=Load(), lineno=2, col_offset=3, end_lineno=2, 
end_col_offset=4),
body=[Pass(lineno=3, col_offset=4, end_lineno=3, end_col_offset=8)],
orelse=[
If(
test=Name(
id="b", ctx=Load(), lineno=4, col_offset=5, 
end_lineno=4, end_col_offset=6
),
body=[Pass(lineno=5, col_offset=4, end_lineno=5, 
end_col_offset=8)],
orelse=[],
lineno=4,
col_offset=0,
end_lineno=5,
end_col_offset=8,
)
],
lineno=2,
col_offset=0,
end_lineno=5,
end_col_offset=8,
)
],
type_ignores=[],
)

On the other hand parsing

2:if a:
3:pass
4:elif b:
5:pass
6:else:
7:pass

outputs

Module(
body=[
If(
test=Name(
id="a",
ctx=Load(),
lineno=2,
col_offset=3,
end_lineno=2,
end_col_offset=4,
),
body=[Pass(lineno=3, col_offset=4, end_lineno=3, end_col_offset=8)],
orelse=[
If(
test=Name(
id="b",
ctx=Load(),
lineno=4,
col_offset=5,
end_lineno=4,
end_col_offset=6,
),
body=[Pass(lineno=5, col_offset=4, end_lineno=5, 
end_col_offset=8)],
orelse=[
Pass(lineno=7, col_offset=4, end_lineno=7, 
end_col_offset=8)
],
lineno=4,
col_offset=5,
end_lineno=7,
end_col_offset=8,
)
],
lineno=2,
col_offset=0,
end_lineno=7,
end_col_offset=8,
)
],
type_ignores=[],
)

--

___
Python tracker 

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



[issue39043] Add math.fib() generator

2019-12-13 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +mark.dickinson, rhettinger, stutzbach

___
Python tracker 

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



[issue39043] Add math.fib() generator

2019-12-13 Thread Lovi


New submission from Lovi <1668151...@qq.com>:

I think it's appropriate to add the generator fib() to the math module. With 
fib(), some operations will be easier.

The generator is like this:

def fib(count=None):
if count is not None and not isinstance(count, int):
raise ValueError(f"Parameter count has an unexpected type: 
{count.__class__.__name__}.")
a, b = 0, 1
while True:
a, b = b, a + b
if count is not None:
if not count:
return
count -= 1
yield a

--
components: Library (Lib)
messages: 358375
nosy: lovi
priority: normal
severity: normal
status: open
title: Add math.fib() generator
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



[issue21600] mock.patch.stopall doesn't work with patch.dict

2019-12-13 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

Thanks Mario. I think the last patch attached to the issue is complete with 
tests and needs to be updated master. Feel free to raise a PR.

--

___
Python tracker 

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



[issue37224] test__xxsubinterpreters fails randomly

2019-12-13 Thread Kyle Stanley


Kyle Stanley  added the comment:

> Yep, it has to use the public C-API just like any other module.  The
> function has a "_Py" prefix and be defined in Include/cpython, right?

Yeah, I named it "_PyInterpreterIsFinalizing" and it's within Include/cpython. 
Definitely open to suggestions on the name though, it's basically just a 
private getter for interp->finalizing.

> We don't need everything to be fixed in a single PR.  Feel free to
> create a PR just for the "finalizing" fix.

Oh, awesome! In that case, I'll do some more rigorous testing before opening 
the PR then; I'd like to be 99.99% certain that it at least resolves the 
following failure:

FAIL: test_still_running (test.test__xxsubinterpreters.DestroyTests)
--
Traceback (most recent call last):
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test__xxsubinterpreters.py",
 line 765, in test_still_running
interpreters.destroy(interp)
AssertionError: RuntimeError not raised

Especially since it would be adding a new private C-API function, who's primary 
purpose is to address this specific failure.

This might be a bit of a time consuming process, but I should have time in the 
next week or so to work on it.

--

___
Python tracker 

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



[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

2019-12-13 Thread Kyle Stanley


Kyle Stanley  added the comment:

Opened a PR that adds the whatsnew entries to master, 3.8, 3.7, and 3.6: 
GH-17595.

--

___
Python tracker 

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



[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

2019-12-13 Thread Kyle Stanley


Change by Kyle Stanley :


--
pull_requests: +17067
pull_request: https://github.com/python/cpython/pull/17595

___
Python tracker 

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



[issue39036] Add center_char attribute to str type

2019-12-13 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

Thank you for the suggestion, but this proposal isn't broadly useful enough to 
warrant adding a new method.

--
nosy: +rhettinger
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



[issue39036] Add center_char attribute to str type

2019-12-13 Thread Lovi


Lovi <1668151...@qq.com> added the comment:

Sorry, I made a mistake.

The center char of '12345' is '3' and the center char of 'abcd' is '' because 
it doesn't have the most central character.

In my opinion, with center_char, when you need the center character of a string 
you can get it directly with str.center_char instead of tedious index and 
calculation.

--

___
Python tracker 

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



[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.

2019-12-13 Thread AVicennA


AVicennA  added the comment:

@rhettinger, I did not write nowhere in my post that it's a pure bug. I use 
"behaviour" instead of it. And it getting me incorrect results everytime, that 
is why I should wrote it in here for resolving this problem. This is not about 
getting error message, that write to Stackoverflow. I think you were not 
checking this never.

--

___
Python tracker 

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



[issue23930] http.cookies.SimpleCookie doesn't parse comma-only separated cookies correctly

2019-12-13 Thread Cheryl Sabella


Change by Cheryl Sabella :


--
stage: patch review -> resolved
status: pending -> closed

___
Python tracker 

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



[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.

2019-12-13 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

This doesn't seem like an appropriate use of the bug tracker.

Investigating and explaining cProfile results seems better suited for 
StackOverflow or some other forum.  Then if an actual known bug or potential 
optimization arises, the bug tracker can to used to follow-up on a specific 
request.  

Being "surprised" by timing/profling results usually isn't a bug and can 
sometimes be resolved by studying the source to how one's simplified mental 
model differs from the realities faced by a real-world implementation.

I recommend closing this but allowing it to be reopened if specific improvement 
can be proposed.

--
nosy: +rhettinger

___
Python tracker 

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



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

I'm out of time and this deserves some careful discussion.  I'll get to it next 
Friday (or sooner if possible).  Sorry!

--

___
Python tracker 

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



[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)

2019-12-13 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


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



[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)

2019-12-13 Thread Brett Cannon


Brett Cannon  added the comment:


New changeset aa74a53ad61134911ac7904f24fd2630aeaa8ac8 by Brett Cannon (Miss 
Islington (bot)) in branch '3.8':
bpo-36406: Handle namespace packages in doctest (GH-12520) (GH-17591)
https://github.com/python/cpython/commit/aa74a53ad61134911ac7904f24fd2630aeaa8ac8


--

___
Python tracker 

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



[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)

2019-12-13 Thread Brett Cannon


Brett Cannon  added the comment:


New changeset d3212036aa2510b9e133ba4bfaf1262d6bcbe7f0 by Brett Cannon (Miss 
Islington (bot)) in branch '3.7':
bpo-36406: Handle namespace packages in doctest (GH-12520) (GH-17592)
https://github.com/python/cpython/commit/d3212036aa2510b9e133ba4bfaf1262d6bcbe7f0


--

___
Python tracker 

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



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

Sorry for the delay, Phil.  I'll try to take a look in the next couple of hours.

--

___
Python tracker 

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



[issue38904] "signal only works in main thread" in main thread

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

Before 3.8, the "signal" module checked against the thread in which the module 
was initially loaded, treating that thread as the "main" thread.  That same was 
true (and still is) for the "threading" module.  The problem for both modules 
is that the Python runtime may have actually been initialized in a different 
thread, which is the actual "main" thread.

Since Python 3.8 we store the ID of the thread where the runtime is initialized 
and use that in the check the "signal" module does.  However, the "threading" 
module still uses the ID of the thread where it is first imported.  So your 
check against "threading.main_thread()" must be in code that isn't running in 
the same thread where you ran Py_Initialize().  It probably used to work 
because you imported "signal" and "threading" for the first time in the same 
thread.

So what next?

First, I've created issue39042 to address the current different meanings of 
"main thread".  That should resolve the discrepancy between the signal and 
threading modules.

Second, what can we do to help embedders make sure they are running their code 
in the main thread (e.g. when setting signals)?  Is there any C-API we could 
add which would have helped you here?

--
nosy: +eric.snow, vstinner

___
Python tracker 

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



[issue39042] Use the runtime's main thread ID in the threading module.

2019-12-13 Thread Eric Snow


New submission from Eric Snow :

The threading module has a "main_thread()" function that returns a Thread 
instance for the "main" thread.  The main thread is the one running when the 
runtime is initialized and has a specific role in various parts of the runtime. 
 Currently the threading module instead uses the ID of the thread where the 
module is imported for the first time.  Usually this isn't a problem. (perhaps 
only in embedding cases?)

Since 3.8 we store the ID of the thread where the runtime was initialized 
(_PyRuntime.main_thread).  By using this in the threading module we can be 
consistent across the runtime about what the main thread is.

This is particularly significant because in 3.8 we also updated the signal 
module to use _PyRuntime.main_thread (instead of calling 
PyThread_get_thread_ident() when the module is loaded).  See issue38904.

We should also consider backporting this change to 3.8, to resolve the 
difference between the threading and signal modules.

--
components: Library (Lib)
messages: 358362
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: Use the runtime's main thread ID in the threading module.
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



[issue39041] Support GitHub Actions in CI

2019-12-13 Thread Steve Dower


New submission from Steve Dower :

Enable support for GitHub Actions CI to do PR build and test runs.

Once stable, we can deprecate Azure Pipelines PR builds.

The only regression right now is that test results are not collected in a nice 
view like AP has. But I think that view is not widely used, and searching the 
logs on GitHub is probably good enough.

--
assignee: steve.dower
components: Build
messages: 358361
nosy: brett.cannon, steve.dower
priority: normal
pull_requests: 17066
severity: normal
stage: patch review
status: open
title: Support GitHub Actions in CI
versions: 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



[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.

2019-12-13 Thread AVicennA


AVicennA  added the comment:

In official documentation: https://docs.python.org/3/library/profile.html was 
not noted about the difference behaviour of cProfile in command line and into 
the file.

--

___
Python tracker 

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



[issue37224] test__xxsubinterpreters fails randomly

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley  wrote:
> I have a few ideas that I'd like to test out for fixing this failure, and if 
> any of them produce positive results I'll report back.

Sounds good.

> Since the failures are still consistently occurring, I have not yer revised 
> GH-16293. I'll do that when/if I come up with a more thorough solution.

We don't need everything to be fixed in a single PR.  Feel free to
create a PR just for the "finalizing" fix.

--

___
Python tracker 

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



[issue37224] test__xxsubinterpreters fails randomly

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley  wrote:
> Based on the above hint, I was able to make some progress on a potential 
> solution. Thanks Eric.

That's great!

> Instead of only checking "frame->f_executing", I changed "_is_running()" to 
> also check the
> "finalizing" field of PyInterpreterState. The "finalizing" field is set to 1 
> in "Py_EndInterpreter()",
> so this ensures that an interpreter in the process of being destroyed is 
> considered "running",
> so that operations (such as running scripts, destroying the interpreter, etc) 
> can't occur during
> finalization.

Ah, that makes sense.

> I had to add a private function to the C-API in order to access 
> "interp->finalizing" from
> Modules/_xxsubinterpretersmodule.c due to the struct for PyInterpreterState 
> being internal only.

Yep, it has to use the public C-API just like any other module.  The
function has a "_Py" prefix and be defined in Include/cpython, right?

--

___
Python tracker 

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



[issue37776] Test Py_Finalize() from a subinterpreter

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Fri, Dec 13, 2019 at 11:22 AM Lewis Gaul  wrote:
> So it looks like adding a specific testcase for this is likely to weed out an 
> actual issue here!

+1

--

___
Python tracker 

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



[issue38858] new_interpreter() should reuse more Py_InitializeFromConfig() code

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

Thanks for working on this.  It really does have far-reaching benefits, not 
just for the subinterpreter stuff I'm interested in. :)

--

___
Python tracker 

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



[issue36854] GC operates out of global runtime state.

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Wed, Dec 4, 2019 at 4:36 AM STINNER Victor  wrote:
> Each time I tried to fix a bug in the Python finalization, I introduced worse 
> bugs :-D

:)

> We cannot fix all bugs at once, we have to work incrementally.

+1

> I like the idea of introducing workarounds specific to subinterpreters: leave 
> the code path for the main interpreter unchanged. It helps to iterate on the 
> code to slowly fix the code.

+1

> I prefer to not open an issue, since the Python finalization is broken is so 
> many ways :-D Anyway, I'm hitting issues on the finalization each time I'm 
> working on subinterpeter changes, so it's hard to forget about it :-)

Sounds good. :)

On Wed, Dec 4, 2019 at 4:39 AM STINNER Victor  wrote:
> I'm a believer that subinterpreters is one of the most realistic solution to 
> make Python faster. I said it in my EuroPython keynote on CPython performance 
> ;-)

Again, thanks for that!

--

___
Python tracker 

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



[issue38962] Reference leaks in subinterpreters

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

Thanks for all the work on this!

--
nosy: +eric.snow

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-13 Thread Guido van Rossum


Change by Guido van Rossum :


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



[issue13586] IDLE: Replace selected not working/consistent with find

2019-12-13 Thread Zackery Spytz


Zackery Spytz  added the comment:

I've created a pull request for this issue.  Please take a look.

--
nosy: +ZackerySpytz

___
Python tracker 

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



[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread R. David Murray


R. David Murray  added the comment:

That header is *completely* non-RFC compliant.  If gmail generated that header 
there is something very wrong in google-land :(

The RFC compliant formatting for that header looks like this:

Content-Disposition: attachment;
 filename*=utf-8''Schulbesuchsbest%C3%A4ttigung.pdf

You will note that this is nothing like encoded word format.  Encoded words are 
not valid inside quoted strings, and quoted strings can't be used in mime 
header attributes if there are non-ascii characters involved.  Nor can encoded 
words.  

Now, all that said, there is an obvious rule that can be followed to understand 
what that header is trying to convey, and the current parser already implements 
most of it (you will find comments about it in the parser, as well as defects 
being registered).  So, a patch to _header_value_parser to fix the error 
recovery will be accepted.  I've looked at the code to remind myself, but not 
deeply enough to be *sure* where the changes need to be made.  There are two 
possibilities I see off the bat (and both may need fixing): 
get_bare_quoted_string and get_parameter.  Either one or both of those may be 
forgetting that whitespace between encoded words should be dropped.

--

___
Python tracker 

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



[issue13586] IDLE: Replace selected not working/consistent with find

2019-12-13 Thread Zackery Spytz


Change by Zackery Spytz :


--
pull_requests: +17065
pull_request: https://github.com/python/cpython/pull/17593

___
Python tracker 

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



[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread Manfred Kaiser


Change by Manfred Kaiser :


Added file: https://bugs.python.org/file48777/original_mail_from_gmail.eml

___
Python tracker 

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



[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread Manfred Kaiser


Manfred Kaiser  added the comment:

The mail was sent from the GMail web interface

--

___
Python tracker 

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



[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread Manfred Kaiser

Manfred Kaiser  added the comment:

The original filename is "Schulbesuchsbestättigung.pdf", but when I use the 
method "get_filename" I got "Schulbesuchsbestättigung.pdf"

I removed some headers from the mail for privacy reasons

--
Added file: https://bugs.python.org/file48776/error.eml

___
Python tracker 

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



[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread Manfred Kaiser


Change by Manfred Kaiser :


Added file: https://bugs.python.org/file48775/testscript.py

___
Python tracker 

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



[issue37776] Test Py_Finalize() from a subinterpreter

2019-12-13 Thread Lewis Gaul


Lewis Gaul  added the comment:

It seems that test_audit_subinterpreter() in _testembed.c was 
(unintentionally?) doing this already.

After fixing #36225 I found this testcase causes a segfault, but works fine 
when switching back to the main threadstate before calling Py_Finalize().

So it looks like adding a specific testcase for this is likely to weed out an 
actual issue here!

--
nosy: +LewisGaul

___
Python tracker 

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



[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)

2019-12-13 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17064
pull_request: https://github.com/python/cpython/pull/17592

___
Python tracker 

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



[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)

2019-12-13 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17063
pull_request: https://github.com/python/cpython/pull/17591

___
Python tracker 

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



[issue36406] doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)

2019-12-13 Thread Brett Cannon


Brett Cannon  added the comment:


New changeset 8289e27393395ee903bd096d42e07c112d7f15c6 by Brett Cannon (Xtreak) 
in branch 'master':
bpo-36406: Handle namespace packages in doctest (GH-12520)
https://github.com/python/cpython/commit/8289e27393395ee903bd096d42e07c112d7f15c6


--
nosy: +brett.cannon

___
Python tracker 

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



[issue1021318] PyThreadState_Next not thread safe

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Wed, Dec 11, 2019 at 7:02 AM STINNER Victor  wrote:
> We may have to fix this API first, and clarify the scope of the different 
> locks.

+1

--

___
Python tracker 

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



[issue39037] Wrong trial order of __exit__ and __enter__ in the with statement

2019-12-13 Thread Brett Cannon


Brett Cannon  added the comment:

@Gery please do open a documentation PR! :)

--
nosy: +brett.cannon

___
Python tracker 

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



[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread R. David Murray


R. David Murray  added the comment:

Thanks for the report.  Can you provide an example that reproduces the problem? 
 

Per the RFC, lines may be broken before whitespace in certain places in certain 
headers, but that does not make the whitespace go away.  Only the crlf sequence 
is removed when unfolding the header, per the RFC, so your proposed fix is 
incorrect. I suspect your example header is invalid, and the question will then 
become is there some sort of Postel-style error recovery we can and want to do 
in the function that parses the content-disposition header.

--

___
Python tracker 

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



[issue36746] Create test for fcntl.lockf()

2019-12-13 Thread Joannah Nanjekye


Joannah Nanjekye  added the comment:

@victor looks to be the author of the change the introduced the tests that can 
resolve this.

Victor, can we consider this closed. I have no problem closing the issue and 
the related PR.

--
nosy: +vstinner

___
Python tracker 

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



[issue39040] Wrong filename in mail when mime header was too long

2019-12-13 Thread Manfred Kaiser


Change by Manfred Kaiser :


--
title: Wrong filename in when mime header was too long -> Wrong filename in 
mail when mime header was too long

___
Python tracker 

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



[issue39040] Wrong filename in when mime header was too long

2019-12-13 Thread Manfred Kaiser


Change by Manfred Kaiser :


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

___
Python tracker 

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



[issue39037] Wrong trial order of __exit__ and __enter__ in the with statement

2019-12-13 Thread Serhiy Storchaka


Change by Serhiy Storchaka :


--
assignee:  -> docs@python
components: +Documentation -Interpreter Core
keywords: +easy
nosy: +docs@python
stage:  -> needs patch

___
Python tracker 

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



[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread Manfred Kaiser


Change by Manfred Kaiser :


--
title: Wrong filename in mail when mime header was too long -> Wrong 
attachement filename when mail mime header was too long

___
Python tracker 

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



[issue39040] Wrong filename in when mime header was too long

2019-12-13 Thread Manfred Kaiser


New submission from Manfred Kaiser :

I'm working on a mailfilter in python and used the method "get_filename" of the 
"EmailMessage" class.

In some cases a wrong filename was returned. The reason was, that the 
Content-Disposition Header had a line break and the following intention was 
interpreted as part of the filename.

After fixing this bug, I was able to get the right filename.

I had to change "linesep_splitter" in "email.policy" to match the intention.

Old Value:

linesep_splitter = re.compile(r'\n|\r')


New Value:

linesep_splitter = re.compile(r'\n\s+|\r\s+')

--
components: email
messages: 358343
nosy: barry, mkaiser, r.david.murray
priority: normal
severity: normal
status: open
title: Wrong filename in when mime header was too long
type: behavior
versions: Python 3.5, 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



[issue36746] Create test for fcntl.lockf()

2019-12-13 Thread Dong-hee Na


Dong-hee Na  added the comment:

@nanjekyejoannah

IMHO, tests were added through bpo-22367
I think that we can close this issue.
What do you think?

--
nosy: +corona10

___
Python tracker 

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



[issue39039] zlib.error with tarfile.open

2019-12-13 Thread jvoisin


jvoisin  added the comment:

Sure, but as a user, I would expect a better exception, like ValueError or 
ReadError, along with an error message, instead of an unexpected zlib exception.

--

___
Python tracker 

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



[issue39039] zlib.error with tarfile.open

2019-12-13 Thread Christian Heimes


Christian Heimes  added the comment:

This file is also an invalid tar file:

$ tar xf crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82 

gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error is not recoverable: exiting now

--
nosy: +christian.heimes

___
Python tracker 

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



[issue39038] OverflowError in tarfile.open

2019-12-13 Thread Christian Heimes


Christian Heimes  added the comment:

The file is not a valid tar file:

$ tar xf crash-83a6e7d4b810c6a0bd4fd9dfd6a0b36550034ccf

gzip: stdin: invalid compressed data--crc error

gzip: stdin: invalid compressed data--length error
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Child returned status 1
tar: Error is not recoverable: exiting now

--
nosy: +christian.heimes

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-13 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:


New changeset 3b18b17efcee6f968cf85c543254b3611311e9f4 by Pablo Galindo (Miss 
Islington (bot)) in branch '3.8':
bpo-39031: Include elif keyword when producing lineno/col-offset info for 
if_stmt (GH-17582) (GH-17589)
https://github.com/python/cpython/commit/3b18b17efcee6f968cf85c543254b3611311e9f4


--

___
Python tracker 

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



[issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error

2019-12-13 Thread Géry

Change by Géry :


--
nosy: +maggyero

___
Python tracker 

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



[issue39038] OverflowError in tarfile.open

2019-12-13 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +ethan.furman

___
Python tracker 

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



[issue39039] zlib.error with tarfile.open

2019-12-13 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +ethan.furman

___
Python tracker 

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



[issue39039] zlib.error with tarfile.open

2019-12-13 Thread jvoisin


New submission from jvoisin :

The attached file produces the following stacktrace when opened via 
`tarfile.open`, on Python 3.7.5rc1:

```
$ cat test.py 
import sys
import tarfile

tarfile.open(sys.argv[1])
$ python3 test.py ./crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82
Traceback (most recent call last):
  File "test.py", line 4, in 
tarfile.open(sys.argv[1])
  File "/usr/lib/python3.7/tarfile.py", line 1573, in open
return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1645, in gzopen
t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1621, in taropen
return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1484, in __init__
self.firstmember = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2289, in next
tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.7/tarfile.py", line 1094, in fromtarfile
buf = tarfile.fileobj.read(BLOCKSIZE)
  File "/usr/lib/python3.7/gzip.py", line 276, in read
return self._buffer.read(size)
  File "/usr/lib/python3.7/_compression.py", line 68, in readinto
data = self.read(len(byte_view))
  File "/usr/lib/python3.7/gzip.py", line 471, in read
uncompress = self._decompressor.decompress(buf, size)
zlib.error: Error -3 while decompressing data: invalid distances se
```

--
components: Library (Lib)
files: crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82
messages: 358337
nosy: jvoisin
priority: normal
severity: normal
status: open
title: zlib.error with tarfile.open
type: behavior
versions: Python 3.7
Added file: 
https://bugs.python.org/file48774/crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82

___
Python tracker 

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



[issue39038] OverflowError in tarfile.open

2019-12-13 Thread jvoisin


New submission from jvoisin :

The attached file produces the following stacktrace when opened via 
`tarfile.open`, on Python 3.7.5rc1:

```
$ cat test.py 
import sys
import tarfile

tarfile.open(sys.argv[1])
$ python3 test.py ./crash-83a6e7d4b810c6a0bd4fd9dfd6a0b36550034ccf
Traceback (most recent call last):
  File "test.py", line 4, in 
tarfile.open(sys.argv[1])
  File "/usr/lib/python3.7/tarfile.py", line 1573, in open
return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1645, in gzopen
t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1621, in taropen
return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1484, in __init__
self.firstmember = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2289, in next
tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.7/tarfile.py", line 1097, in fromtarfile
return obj._proc_member(tarfile)
  File "/usr/lib/python3.7/tarfile.py", line 1119, in _proc_member
return self._proc_pax(tarfile)
  File "/usr/lib/python3.7/tarfile.py", line 1230, in _proc_pax
match = regex.match(buf, pos)
OverflowError: Python int too large to convert to C ssize
```

--
components: Library (Lib)
files: crash-83a6e7d4b810c6a0bd4fd9dfd6a0b36550034ccf
messages: 358336
nosy: jvoisin
priority: normal
severity: normal
status: open
title: OverflowError in tarfile.open
type: behavior
versions: Python 3.7
Added file: 
https://bugs.python.org/file48773/crash-83a6e7d4b810c6a0bd4fd9dfd6a0b36550034ccf

___
Python tracker 

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



[issue39037] Wrong trial order of __exit__ and __enter__ in the with statement

2019-12-13 Thread Géry

Géry  added the comment:

Thanks @mark.dickinson for the link. Can I open a documentation PR for this?

--

___
Python tracker 

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



[issue27495] Pretty printing sorting for set and frozenset instances

2019-12-13 Thread SilentGhost


Change by SilentGhost :


--
nosy: +SilentGhost
type: enhancement -> behavior
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

___
Python tracker 

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



[issue39037] Wrong trial order of __exit__ and __enter__ in the with statement

2019-12-13 Thread Mark Dickinson


Mark Dickinson  added the comment:

See issue 27100, which led to a deliberate change in behaviour to look up 
__enter__ before __exit__. It looks like the documentation (not the PEP text, 
which shouldn't be considered normative; just the reference manual) needs to be 
adjusted to match the new behaviour.

--
nosy: +mark.dickinson

___
Python tracker 

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



[issue39037] Wrong trial order of __exit__ and __enter__ in the with statement

2019-12-13 Thread Géry

New submission from Géry :

>>> class A: pass
... 
>>> with A(): pass
... 
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: __enter__

I expected `AttributeError: __exit__`, since PEP 343 states 
(https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement):

> The details of the above translation are intended to prescribe the exact 
> semantics. If either of the relevant methods are not found as expected, the 
> interpreter will raise AttributeError, in the order that they are tried 
> (__exit__, __enter__).

and the language documentation states 
(https://docs.python.org/3/reference/compound_stmts.html#the-with-statement):

> The execution of the with statement with one “item” proceeds as follows:
> 1. The context expression (the expression given in the with_item) is 
> evaluated to obtain a context manager.
> 2. The context manager’s __exit__() is loaded for later use.
> 3. The context manager’s __enter__() method is invoked.

--
components: Interpreter Core
messages: 358333
nosy: gvanrossum, maggyero, ncoghlan
priority: normal
severity: normal
status: open
title: Wrong trial order of __exit__ and __enter__ in the with statement
type: behavior
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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-13 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:


New changeset 0ed45d0cbfc7579dfc5527c19aa6e4bb696db2e0 by Pablo Galindo in 
branch '3.7':
[3.7] bpo-39031: Include elif keyword when producing lineno/col-offset info for 
if_stmt (GH-17582) (#17584)
https://github.com/python/cpython/commit/0ed45d0cbfc7579dfc5527c19aa6e4bb696db2e0


--

___
Python tracker 

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



[issue39031] Inconsistency with lineno and col_offset info when parsing elif

2019-12-13 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17061
pull_request: https://github.com/python/cpython/pull/17589

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-13 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


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

___
Python tracker 

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



[issue39036] Add center_char attribute to str type

2019-12-13 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

What you mean by "center_char" is not clear to me.

How is "bc" a character? It looks like two characters to me.

How is "1" the center char of "12345"? It looks like the leftmost character to 
me.

Once you have explained what "center_char" does, could you explain how it will 
be useful?

--
components: +Library (Lib) -Windows
nosy: +steven.daprano

___
Python tracker 

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



[issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled

2019-12-13 Thread Sergei Lebedev


Sergei Lebedev  added the comment:

I know this patch has already been rejected, but I wanted to give another 
potential use-case for accessing GC status from C: JIT compilers.

Imagine a JIT compiler which uses alternative storage for instance attributes. 
In order to maintain correctness, it should "materialize" the stored attributes 
whenever __dict__ (or rather a pointer to __dict__) is accessed. In this 
context materialization means something like:

__dict__ = {}
for key, value in zip(keys, values):
__dict__[key] = value

Now, what if a __dict__ is accessed during a GC collection (which is possible: 
collect->deduce_unreachable->subtract_refs->subtype_traverse via tp_traverse)? 
The JIT compiler should be able to detect such calls and avoid allocating 
anything:

if collecting:
return

__dict__ = {}
# ...

This is possible to implement in pure Python using gc.isenabled and 
gc.callbacks, but there is no existing API to do that in C.

Does this sounds convincing enough to motivate adding

int PyGC_IsEnabled(void)
int PyGC_IsCollecting(void)

to the C API?

--
nosy: +sergei.lebedev

___
Python tracker 

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



[issue39034] Documentation: Coroutines

2019-12-13 Thread Andrew Svetlov


Andrew Svetlov  added the comment:

I suggest thinking that gather() implicitly creates tasks for running 
coroutines.
The documentation is technically correct, enumeration of all potentially 
endless list of things that calls `create_task()` for wrapping passed coroutine 
is not very helpful, especially for the beginning document.

--

___
Python tracker 

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



[issue39036] Add center_char attribute to str type

2019-12-13 Thread Lovi


New submission from Lovi <1668151...@qq.com>:

I think Python3.9 needs to add the center_char attribute which means the center 
character of strings to string type, such as the center_char of '12345' is '1' 
and the center_char of 'abcd' is 'bc'.

--
components: Windows
messages: 358328
nosy: lovi, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add center_char attribute to str type
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



[issue27197] mock.patch interactions with "from" imports

2019-12-13 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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



[issue27341] mock.patch decorating a generator returns a regular function.

2019-12-13 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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



[issue32952] Add __qualname__ for attributes of Mock instances

2019-12-13 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

create_autospec already does recursive spec setting on the class and it has the 
attributes/methods mocked to retain attributes but doesn't copy the metadata of 
the original methods to the mock itself. I am not sure spec_set needs to do 
more stuff than simple attribute level checks making it more heavy to resemble 
autospeccing and there is an issue for that already. Currently we don't copy 
__qualname__ to the mock at [0]. 

The func metadata are copied to checksig and during __call__ checksig is used 
but it's not usable outside and I am not sure we need to do it. The fix to do 
_copy_func_details(func, mock) below that would copy the function attributes to 
the actual mock thus accessing the attributes for the mock making below example 
work.


from unittest.mock import MagicMock, create_autospec, patch

class SomeClass(object):

def some_method(self):
print("Hi!")

if __name__ == "__main__":
ins = SomeClass()
assert ins.some_method.__qualname__ == "SomeClass.some_method"

with patch('__main__.SomeClass', autospec=True) as mocked:
obj = SomeClass()
assert obj.some_method.__qualname__ == "SomeClass.some_method"
obj.some_method()
obj.some_method.assert_called_once()


Copy metadata patch : 

diff --git Lib/unittest/mock.py Lib/unittest/mock.py
index cd5a2aeb60..ea1c6c84ac 100644
--- Lib/unittest/mock.py
+++ Lib/unittest/mock.py
@@ -117,6 +117,7 @@ def _check_signature(func, mock, skipfirst, instance=False):
 def checksig(self, /, *args, **kwargs):
 sig.bind(*args, **kwargs)
 _copy_func_details(func, checksig)
+_copy_func_details(func, mock)
 type(mock)._mock_check_sig = checksig
 type(mock).__signature__ = sig

@@ -127,6 +128,7 @@ def _copy_func_details(func, funcopy):
 for attribute in (
 '__name__', '__doc__', '__text_signature__',
 '__module__', '__defaults__', '__kwdefaults__',
+'__qualname__'
 ):
 try:
 setattr(funcopy, attribute, getattr(func, attribute))

[0] 
https://github.com/python/cpython/blob/025a602af7ee284d8db6955c26016f3f27d35536/Lib/unittest/mock.py#L124
[1] 
https://github.com/python/cpython/blob/025a602af7ee284d8db6955c26016f3f27d35536/Lib/unittest/mock.py#L119

--

___
Python tracker 

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-13 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

Sure Serhiy, I will create one.

--

___
Python tracker 

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



[issue32952] Add __qualname__ for attributes of Mock instances

2019-12-13 Thread Serhiy Storchaka


Change by Serhiy Storchaka :


--
nosy: +michael.foord
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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



[issue39035] Travis CI fail on backports: pyvenv not installed

2019-12-13 Thread STINNER Victor


New submission from STINNER Victor :

Example of failure of a backport from 3.8 to 3.7, PR 17577:
https://github.com/python/cpython/pull/17577

"""
$ python --version

Python 3.6.9

$ pip --version

pip 19.3.1 from 
/home/travis/virtualenv/python3.6.9/lib/python3.6/site-packages/pip (python 3.6)
before_install.1

0.00s$ set -e

$ pyenv global 3.7.1

pyenv: version `3.7.1' not installed
"""

Travis CI logs:
https://travis-ci.org/python/cpython/jobs/624160244

Thread on python-dev:
https://mail.python.org/archives/list/python-...@python.org/thread/YCTLWAYIC44YTVGNN4EDLWKMER2LAPDA/

--
components: Tests
messages: 358325
nosy: inada.naoki, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Travis CI fail on backports: pyvenv not installed
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



[issue32952] Add __qualname__ for attributes of Mock instances

2019-12-13 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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



[issue21600] mock.patch.stopall doesn't work with patch.dict

2019-12-13 Thread Mario Corchero


Mario Corchero  added the comment:

Makes total sense, I think we should get this for 3.9.
Not sure I'll backport this, even if a bugfix it might cause unexpected changes 
(Though I'd be OK with it, given that calling stop twice causes no issue).

I'm happy to push a PR with the proposed change and some tests if you want 
@xtreak. This is quite a simple fix we can get through in a short time.

--

___
Python tracker 

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



[issue21600] mock.patch.stopall doesn't work with patch.dict

2019-12-13 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

This sounds like a good idea given the docs and the general agreement in the 
thread. I would like to target this for 3.9 . Differentiation between the 
normal patches and the ones from patch.dict is nice but given that docstring 
indicates LIFO for all active patches storing patch.dict items also in 
_patch.active_patches ensures we can do LIFO if there is a mixture of normal 
and dictionary patches started with start method. Adding other maintainers for 
thoughts.

diff --git Lib/unittest/mock.py Lib/unittest/mock.py
index cd5a2aeb60..96115e06ba 100644
--- Lib/unittest/mock.py
+++ Lib/unittest/mock.py
@@ -1853,8 +1853,21 @@ class _patch_dict(object):
 self._unpatch_dict()
 return False

-start = __enter__
-stop = __exit__
+def start(self):
+"""Activate a patch, returning any created mock."""
+result = self.__enter__()
+_patch._active_patches.append(self)
+return result
+
+def stop(self):
+"""Stop an active patch."""
+try:
+_patch._active_patches.remove(self)
+except ValueError:
+# If the patch hasn't been started this will fail
+pass
+
+return self.__exit__()

--
components: +Library (Lib) -Tests
nosy: +cjw296, lisroach, mariocj89, xtreak
versions: +Python 3.9 -Python 3.5

___
Python tracker 

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