From report at bugs.python.org  Fri Nov  1 00:37:05 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Nov 2019 04:37:05 +0000
Subject: [issue38658] Python Program crashes when running in fore and back
 ground
In-Reply-To: <1572557933.17.0.948616559199.issue38658@roundup.psfhosted.org>
Message-ID: <1572583025.36.0.964733389942.issue38658@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report.  This appears to be another instance of a long-standing unresolved problem when using networks functions in a thread application on macOS that invoke Python's _scproxy helper module to obtain possible network proxy configuration info from macOS. For more details see, for example, Issue13829. Assuming your application does not need to connect through a network proxy, suggest trying the workaround in https://bugs.python.org/issue30385#msg293958 which avoids the call to _scproxy by defining the no_proxy environment variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38658>
_______________________________________

From report at bugs.python.org  Fri Nov  1 00:57:17 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Nov 2019 04:57:17 +0000
Subject: [issue37607] segfault running code in jupyter on macOS 10.14.5 -
 crashed on child side of fork pre-exec
In-Reply-To: <1563296203.64.0.981111226039.issue37607@roundup.psfhosted.org>
Message-ID: <1572584237.46.0.0685485759749.issue37607@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Looking at the macOS crash report you supplied (thanks!), the crash is occurring below libcurl which is called by the third-party pycurl module, so not in Python Standard Library code. And the crash appears to another of macOS's attempts to catch doing unsafe calls to system frameorks when forking withing an exec: note the "crashed on child side of fork pre-exec" message.  This is a well-know pitfall particularly on macOS which is why we changed the default for the multiprocessing module on macOS as Victor noted above.  There are various articles out there about the general problem, like https://www.evanjones.ca/fork-is-dangerous.html.  If you are still seeing the problem, you may need to restructure your application to avoid fork without exec.  Good luck!

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37607>
_______________________________________

From report at bugs.python.org  Fri Nov  1 02:22:35 2019
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Fri, 01 Nov 2019 06:22:35 +0000
Subject: [issue38660] Checking if two regexes are equal should test if they
 are functionally equivalent
Message-ID: <1572589355.53.0.484947747448.issue38660@roundup.psfhosted.org>


New submission from ????? ?????????? <boris.verk at gmail.com>:

re.compile('([-_.a-zA-Z0-9]+)') == re.compile(r'([-\w.]+)') 

should return True because those are the same regex (\w is a-z, A-Z, 0-9 and the underscore). 

If you want to check if two regexes are identical you would compare the original strings, before re.compile.

----------
components: Regular Expressions
messages: 355791
nosy: boris, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Checking if two regexes are equal should test if they are functionally equivalent
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38660>
_______________________________________

From report at bugs.python.org  Fri Nov  1 02:24:09 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 01 Nov 2019 06:24:09 +0000
Subject: [issue33187] Document ElementInclude (XInclude) support in ElementTree
In-Reply-To: <1522427694.7.0.467229070634.issue33187@psf.upfronthosting.co.za>
Message-ID: <1572589449.17.0.31414282543.issue33187@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33187>
_______________________________________

From report at bugs.python.org  Fri Nov  1 03:07:07 2019
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 01 Nov 2019 07:07:07 +0000
Subject: [issue38660] Checking if two regexes are equal should test if they
 are functionally equivalent
In-Reply-To: <1572589355.53.0.484947747448.issue38660@roundup.psfhosted.org>
Message-ID: <1572592027.47.0.0748173265407.issue38660@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

The notion of equivalent regular expressions does exist but is way more complicated than the simple example you described.

For example:

r"a|b" is the same as r"[ab]",
r"^aa*$" is the same as r"^a+$"

Implementing this properly would probably require a significant amount of effort, and just implementing simple equivalence for character classes would be really surprising.

Could you explain the use case and motivation behind this request?

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38660>
_______________________________________

From report at bugs.python.org  Fri Nov  1 03:20:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Nov 2019 07:20:02 +0000
Subject: [issue38660] Checking if two regexes are equal should test if they
 are functionally equivalent
In-Reply-To: <1572589355.53.0.484947747448.issue38660@roundup.psfhosted.org>
Message-ID: <1572592802.62.0.672249649115.issue38660@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

These two regexes are not the same.

>>> re.compile('([-_.a-zA-Z0-9]+)').match('?')
>>> re.compile(r'([-\w.]+)').match('?')
<re.Match object; span=(0, 1), match='?'>

As Ammar said checking that two regexes always matches the same is very difficult problem. It is the problem of determining if two programs are the same.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38660>
_______________________________________

From report at bugs.python.org  Fri Nov  1 03:22:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Nov 2019 07:22:19 +0000
Subject: [issue38657] String format for hexadecimal notation breaks padding
 with alternative form
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572592939.74.0.0771053009331.issue38657@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, the width is the width of the formatted value, not the number of digits.

What is your proposition?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Nov  1 04:16:40 2019
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Fri, 01 Nov 2019 08:16:40 +0000
Subject: [issue38660] Checking if two regexes are equal should test if they
 are functionally equivalent
In-Reply-To: <1572589355.53.0.484947747448.issue38660@roundup.psfhosted.org>
Message-ID: <1572596200.39.0.539233725219.issue38660@roundup.psfhosted.org>


????? ?????????? <boris.verk at gmail.com> added the comment:

I saw two Python regexes, one derived from a regex in the standard library. There was a comment saying that they're interchangeable and I wanted to check if they were actually the same without having to read what all the regex symbols mean. Plus a true comparison would be more correct.

Besides that I don't have a real use case. There's a few people asking about doing this if you Google for "check if two regexes are equivalent". Some for Python specifically.

@serhiy I read what \w meant from the first Google result and got it wrong. Sounds like a good argument for why Python should be able to do this for me :)

Regexes are not Turing complete, so not quite. If I understand it correctly, comparing them is somewhere between comparing two graphs and comparing two programs (which is generally impossible). Theoretically it's a decidable problem, but the extra logic that Python's implementation has (for dealing with unicode and whatever) makes it hard, but it should still be theoretically possible, unless Python's regexes are somehow Turing complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38660>
_______________________________________

From report at bugs.python.org  Fri Nov  1 04:19:56 2019
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Fri, 01 Nov 2019 08:19:56 +0000
Subject: [issue38226] pickle.dump and load error message when file isn't
 opened in binary mode are not useful
In-Reply-To: <1568925061.22.0.28448935108.issue38226@roundup.psfhosted.org>
Message-ID: <1572596396.74.0.351898175875.issue38226@roundup.psfhosted.org>


Change by ????? ?????????? <boris.verk at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38226>
_______________________________________

From report at bugs.python.org  Fri Nov  1 04:24:20 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 01 Nov 2019 08:24:20 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572596659.99.0.156241503321.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

So, here's a prototype implementation of asyncio.ThreadPool that would function exactly as Yury described, but I'm not convinced about the design. Usually, it seems preferred to separate the context manager from the rest of the class (as was done with asyncio.Lock), but I think this one might be simple enough to be a single class:

class ThreadPool:
    def __init__(self, timeout=None):
        self.timeout = timeout
        self._loop = None
    
    async def __aenter__(self):
        self._loop = asyncio.get_running_loop()
        # Ensure that ThreadPoolExecutor is being used
        self._loop.default_executor = concurrent.futures.ThreadPoolExecutor()
        return self

    async def __aexit__(self, *args):
        await self._loop.shutdown_default_executor(timeout=self.timeout)

    def run(self, func, *args, **kwargs):
        call = functools.partial(func, *args, **kwargs)
        return self._loop.run_in_executor(None, call)

It utilizes the existing lower level event loop API to provide an asynchronous context manager. I'd say the main advantage is that it's significantly more user friendly, as there's no loop or executor argument to be specified, and users can freely pass kwargs to run() thanks to functools.partial().

Additionally, I also included a timeout parameter for shutting down the ThreadPoolExecutor, which will depend upon GH-16360. This can be used as such:

async def main():
    async with asyncio.ThreadPool(timeout=600) as pool:
        fut1 = pool.run(func)
        fut2 = pool.run(func, arg1, arg2)
        fut2 = pool.run(func, arg1, kwarg1=True)
    print(await asyncio.gather(fut1, fut2, fut3))

asyncio.run(main())

I don't expect that this would be the final design, but I think it's a decent prototype to demonstrate the functionality. Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 04:43:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Nov 2019 08:43:53 +0000
Subject: [issue38660] Checking if two regexes are equal should test if they
 are functionally equivalent
In-Reply-To: <1572589355.53.0.484947747448.issue38660@roundup.psfhosted.org>
Message-ID: <1572597833.23.0.843219422835.issue38660@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Python's regular expressions are not actually regular. Lookarounds and groups make things more complex. Even it it is possible to build an ambiguous graph, its size and the time of building can be too large for practical use. Dealing with unicode is only minor part of the problem.

I suggest you first to implement this feature as a third-party module on PyPI. After this we can consider including it in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38660>
_______________________________________

From report at bugs.python.org  Fri Nov  1 05:34:19 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 01 Nov 2019 09:34:19 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572600859.09.0.368245644223.issue32309@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

`run` should be awaitable method, see #38430

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 05:35:53 2019
From: report at bugs.python.org (Paul Martin)
Date: Fri, 01 Nov 2019 09:35:53 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572600953.17.0.227970841584.issue32309@roundup.psfhosted.org>


Paul Martin <greatestloginnameever at gmail.com> added the comment:

I don't think changing the default executor is a good approach. What happens, if two or more thread pools are running at the same time? In that case they will use the same default executor anyway, so creating a new executor each time seems like a waste. 

Shutting down the default executor seems unnecessary and could impact lower level code which is using it. The default executor is shutdown at the end of asyncio.run anyway.

I also think it would be good to have a synchronous entry point, and not require a context manager. Having a ThreadPool per class instance would be a common pattern.


class ThreadPool:
    def __init__(self, timeout=None):
        self.timeout = timeout
        self._loop = asyncio.get_event_loop()
        self._executor = concurrent.futures.ThreadPoolExecutor()

    async def close(self): 
        await self._executor.shutdown(timeout=self.timeout)  
        
    async def __aenter__(self):
        return self

    async def __aexit__(self, *args):
        await self.close()

    def run(self, func, *args, **kwargs):
        call = functools.partial(func, *args, **kwargs)
        return self._loop.run_in_executor(self._executor, call)


I'm not sure if a new ThreadPoolExecutor really needs to be created for each ThreadPool though.

----------
nosy: +primal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 05:36:46 2019
From: report at bugs.python.org (Paul Martin)
Date: Fri, 01 Nov 2019 09:36:46 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572601006.29.0.83835312286.issue32309@roundup.psfhosted.org>


Paul Martin <greatestloginnameever at gmail.com> added the comment:

Run method should be:

    async def run(self, func, *args, **kwargs):
        call = functools.partial(func, *args, **kwargs)
        return await self._loop.run_in_executor(None, call)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 05:43:04 2019
From: report at bugs.python.org (alclarks)
Date: Fri, 01 Nov 2019 09:43:04 +0000
Subject: [issue9495] argparse unittest tracebacks are confusing if an error is
 raised when not expected
In-Reply-To: <1280852518.56.0.709280463518.issue9495@psf.upfronthosting.co.za>
Message-ID: <1572601384.49.0.360739535359.issue9495@roundup.psfhosted.org>


alclarks <alexpclarkson at gmail.com> added the comment:

I'm a newcomer looking to contribute - would it be a good idea for me to update one of the attached diffs and raise a pull request?

----------
nosy: +alclarks

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9495>
_______________________________________

From report at bugs.python.org  Fri Nov  1 05:52:18 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 01 Nov 2019 09:52:18 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572601938.7.0.522645024923.issue32309@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Paul's version looks better.

Two notes: 
1. get_running_loop() should be used instead of get_event_loop()
2. There is no `await executer.shutdown()` API, the method is synchronous.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:07:44 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 01 Nov 2019 11:07:44 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572606464.1.0.216674238787.issue37903@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Stephen, perhaps what you're suggesting is out of context for this issue? This issue is about removing prompts from the shell window's text widget, replacing them with a separate sidebar showing where prompts and user input were. This will make IDLE's shell less similar to the basic command line shell, not more similar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:09:01 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 01 Nov 2019 11:09:01 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572606541.89.0.153583932708.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I don't think changing the default executor is a good approach. What happens, if two or more thread pools are running at the same time? In that case they will use the same default executor anyway, so creating a new executor each time seems like a waste. 

I agree that it would be better to have ThreadPool use an internal executor rather than relying on the event loop's default executor. The main reason I hadn't was because we hadn't implemented an asynchronous executor shutdown outside of loop.shutdown_default_executor(), but we could potentially move the functionality to a private function (in Lib/asyncio/base_events.py) so it's reusable for ThreadPool. It could be something like this:

    async def _shutdown_executor(executor, loop):
        future = loop.create_future()
        thread = threading.Thread(target=loop._do_shutdown, args=(executor,future))
        thread.start()
        try:
            await future
        finally:
            thread.join()

    def _do_shutdown(loop, executor, future):
        try:
            executor.shutdown(wait=True)
            loop.call_soon_threadsafe(future.set_result, None)
        except Exception as ex:
            loop.call_soon_threadsafe(future.set_exception, ex)

Note that the above would be for internal use only, for the existing loop.shutdown_default_executor() and the new asyncio.ThreadPool. For it to support both, it would have to accept an explicit loop argument. It also does not need a robust API, since it's private. 

> Shutting down the default executor seems unnecessary and could impact lower level code which is using it. The default executor is shutdown at the end of asyncio.run anyway.

I agree with your point regarding the shutdown of the default executor one. But I think we should shutdown the internal executor for the ThreadPool, as a main point context managers is to start and clean up their own resources. Also, I'm aware that asyncio.run() shuts down the default executor, I implemented that fairly recently in GH-15735. ;)

Another substantial concern is in the case of a coroutine that contains asyncio.ThreadPool being executed without asyncio.run(). There are still use cases for using the lower level loop.run_until_complete() for more complex asyncio programs. I don't think we should make asyncio.ThreadPool dependent on the coroutine being executed with asyncio.run(). Thus, it makes sense that ThreadPool should create a new instance of ThreadPoolExecutor upon entry of the context manager and then shut it down upon exit. 

> I'm not sure if a new ThreadPoolExecutor really needs to be created for each ThreadPool though.

IMO, a context manager should create and then finalize it's own resources, rather than sharing the same executor across contexts. Sharing the same one seems to defeat the purpose of using a context manager in the first place, no?

> Run method should be:

    async def run(self, func, *args, **kwargs):
        call = functools.partial(func, *args, **kwargs)
        return await self._loop.run_in_executor(None, call)

Correction: if we're using an internal executor now, this should instead be self._loop.run_in_executor(self._executor, call). With `None`, it will simply use the event loop's default executor rather the context manager's ThreadPoolExecutor.

> `run` should be awaitable method, see #38430

Agreed, good point. 

> Paul's version looks better.

I think he had some good points, particularly around using an internal executor instead the event loop's default executor; but there's some parts that I disagree with, see above reasons.

> 1. get_running_loop() should be used instead of get_event_loop()

Note: If get_running_loop() is used instead, it has to set self._loop within a coroutine (since get_running_loop() can only be used within coroutines), that's why in my version it was within __aenter__. I think this would make the most sense. 

> 2. There is no `await executer.shutdown()` API, the method is synchronous.

That's why in my version I was using the existing event loop API, since we had already implemented an asynchronous loop.shutdown_default_executor() method that calls executor.shutdown(). However, if we added a private _shutdown_executor() and _do_shutdown() as I mentioned above, that wouldn't be an issue. 

Thanks for the feedback on the prototype Paul and Andrew, both of you brought up some good points. I'll start working on a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:17:32 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 01 Nov 2019 11:17:32 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572607052.58.0.520789748468.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Also, I agree with Paul's idea of initializing the ThreadPoolExecutor in the __init__ instead of __aenter__, that makes more sense now that I think about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:21:05 2019
From: report at bugs.python.org (ThePokestarFan)
Date: Fri, 01 Nov 2019 11:21:05 +0000
Subject: [issue38658] Python Program crashes when running in fore and back
 ground
In-Reply-To: <1572557933.17.0.948616559199.issue38658@roundup.psfhosted.org>
Message-ID: <1572607265.69.0.503234717295.issue38658@roundup.psfhosted.org>


ThePokestarFan <sarkaraoyan at gmail.com> added the comment:

Thank you. Closing this issue.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38658>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:23:44 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 01 Nov 2019 11:23:44 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572607424.61.0.149350637335.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> thread = threading.Thread(target=loop._do_shutdown, args=(executor,future))

Correction:

> thread = threading.Thread(target=_do_shutdown, args=(loop, executor,future))

Also, it might make more sense to rename _do_shutdown() to _do_executor_shutdown() to give the function's name more context; renaming shouldn't be an issue since it's private. Plus, it was just added recently in 3.9, so there's even less backwards compatibility to be concerned with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:28:17 2019
From: report at bugs.python.org (ThePokestarFan)
Date: Fri, 01 Nov 2019 11:28:17 +0000
Subject: [issue13829] exception error in _scproxy.so when called after fork
In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za>
Message-ID: <1572607697.59.0.400694039329.issue13829@roundup.psfhosted.org>


ThePokestarFan <sarkaraoyan at gmail.com> added the comment:

Still present in python 3.8 and issue 38658. Another workaround is in https://bugs.python.org/issue30385#msg293958

----------
nosy: +ThePokestarFan
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13829>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:33:00 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 01 Nov 2019 11:33:00 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572607980.23.0.32837958185.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Actually, I think it would be better to move the functionality of loop.shutdown_default_executor() to a new private method loop._shutdown_executor() that takes an executor argument rather than shutting down the default one. This could be used in both loop.shutdown_default_executor() and ThreadPool. There's no need to move it to function instead of being a method of BaseEventLoop though, that doesn't make sense now that I think about it more. 

Sorry if my thoughts are a bit disorganized, I think I need to get some sleep. (:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:41:59 2019
From: report at bugs.python.org (ThePokestarFan)
Date: Fri, 01 Nov 2019 11:41:59 +0000
Subject: [issue30385] Segfault on OSX with 3.6.1
In-Reply-To: <1495024855.04.0.697140063474.issue30385@psf.upfronthosting.co.za>
Message-ID: <1572608519.33.0.0689718543954.issue30385@roundup.psfhosted.org>


ThePokestarFan <sarkaraoyan at gmail.com> added the comment:

A pythonic way to do it is `os.environ[?no_proxy?]=?*?`

----------
nosy: +ThePokestarFan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30385>
_______________________________________

From report at bugs.python.org  Fri Nov  1 07:45:59 2019
From: report at bugs.python.org (Paul Martin)
Date: Fri, 01 Nov 2019 11:45:59 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572608759.25.0.415713676345.issue32309@roundup.psfhosted.org>


Paul Martin <greatestloginnameever at gmail.com> added the comment:

Good points. I made a mistake in run

Should be:

    async def run(self, func, *args, **kwargs):
        call = functools.partial(func, *args, **kwargs)
        return await self._loop.run_in_executor(self._executor, call)

Also in this case run awaits and returns the result. Yury suggested earlier just to return the future and not await. I have no strong opinion either way. The above example does seem more higher level but Yury's example is more flexible.

I agree that shutdown_default_executor and _do_shutdown should be changed to accept an executor argument so that any executor can be shutdown asynchronously. So the loop API would have a shutdown_executor method. shutdown_default_executor would just call shutdown_executor with the default executor as argument. That would be a good first step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 08:12:38 2019
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Fri, 01 Nov 2019 12:12:38 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572610358.79.0.827555034416.issue37903@roundup.psfhosted.org>


Stephen Paul Chappell <Noctis.Skytower at gmail.com> added the comment:

Zero:     "not to have them added as text as is usual in a terminal window"
taleinat: "removing prompts from the shell window's text widget"

Zero:     "print the values of ps1 and ps2 in the proposed ShellIO subclass"
taleinat: "separate sidebar showing where prompts and user input were"

We appear to be in agreement.

terry.reedy: "Labels, such as '>>>', 'Out', 'Inp', and 'Err' would be used"
Zero:        "Having IDLE react to sys.ps1 and sys.ps2"

My suggestion is to take those labels terry.reedy talks about from the values of ps1 and ps2 since they are already documented and standard for "the interpreter ... in interactive mode." If psX needs to introduced for other prompts that may be needed ("Maybe use 'Con', maybe use Dbg and Wrn."), it would provide a sensible way to customize those labels as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 08:18:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Nov 2019 12:18:36 +0000
Subject: [issue38226] pickle.dump and load error message when file isn't
 opened in binary mode are not useful
In-Reply-To: <1568925061.22.0.28448935108.issue38226@roundup.psfhosted.org>
Message-ID: <1572610716.06.0.246273464022.issue38226@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This looks like a duplicate of issue24159.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38226>
_______________________________________

From report at bugs.python.org  Fri Nov  1 08:20:17 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 01 Nov 2019 12:20:17 +0000
Subject: [issue38657] String format for hexadecimal notation breaks padding
 with alternative form
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572610817.73.0.740845543016.issue38657@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

int.__format__ inherits this from %-formatting, which inherits it from C's printf.

There's no way we're going to change this at this point: the breakage would be too great. So, I'm going to reject this.

----------
assignee:  -> eric.smith
nosy: +eric.smith
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Nov  1 09:22:54 2019
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 01 Nov 2019 13:22:54 +0000
Subject: [issue38659] enum classes cause slow startup time
In-Reply-To: <1572570768.69.0.355804772721.issue38659@roundup.psfhosted.org>
Message-ID: <1572614574.68.0.150933938588.issue38659@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I was just looking at this problem, and creating a bare-bones, no safety belts version for use in the stdlib (no patch yet) which decreases Enum creation from 14x slower to only 6x slower.  (Comparing to a class with simple attributes.)

Not sure if that's enough improvement, though.

If it needs to be even faster, a C version of that simplified Enum shouldn't be too hard.  Anyone that uses the _simple_enum, though, should have a test that uses the full Enum and compares the two to make sure nothing got lost in translation.

----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38659>
_______________________________________

From report at bugs.python.org  Fri Nov  1 09:38:36 2019
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Fri, 01 Nov 2019 13:38:36 +0000
Subject: [issue24159] Misleading TypeError when pickling bytes to a file
 opened as text
In-Reply-To: <1431268460.0.0.240754621807.issue24159@psf.upfronthosting.co.za>
Message-ID: <1572615516.87.0.219055443574.issue24159@roundup.psfhosted.org>


????? ?????????? <boris.verk at gmail.com> added the comment:

As I said in issue38226, the error message you get when you try to pickle.load() a file opened in "r" mode instead of "rb" mode,

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte

is also confusing and can be improved.

----------
nosy: +boris

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24159>
_______________________________________

From report at bugs.python.org  Fri Nov  1 09:39:00 2019
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Fri, 01 Nov 2019 13:39:00 +0000
Subject: [issue38226] pickle.dump and load error message when file isn't
 opened in binary mode are not useful
In-Reply-To: <1568925061.22.0.28448935108.issue38226@roundup.psfhosted.org>
Message-ID: <1572615540.43.0.1691328995.issue38226@roundup.psfhosted.org>


Change by ????? ?????????? <boris.verk at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38226>
_______________________________________

From report at bugs.python.org  Fri Nov  1 09:58:36 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 01 Nov 2019 13:58:36 +0000
Subject: [issue38654] `urllib.request.Request` uses mutable value as default
 value
In-Reply-To: <1572572804.38.0.904283083718.issue38654@roundup.psfhosted.org>
Message-ID: <20191101135827.GV3574@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Also, if some new Python coders saw `[]` or `{}` being used as default 
> values in the standard library, they might think ?I?ll do it too since 
> the standard library does it?.

Great! Having Python coders learn good progamming skills from the 
standard library is a *good* thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38654>
_______________________________________

From report at bugs.python.org  Fri Nov  1 10:32:27 2019
From: report at bugs.python.org (Jose Salvatierra)
Date: Fri, 01 Nov 2019 14:32:27 +0000
Subject: [issue38661] Changes to tkinter result in (unexpected) widget map
 call return changes wrt. 3.7
Message-ID: <1572618747.95.0.320564330748.issue38661@roundup.psfhosted.org>


New submission from Jose Salvatierra <jose at tecladocode.com>:

Hello!

I've encountered what might be a bug.

Up till now we had some working code that did this:

```
maps = self.style.map('TCombobox')
if maps:
    self.style.map('DateEntry', **maps)
```

Modifying a custom style to mimic the map of another. This has worked fine until Python 3.7, because the return value of `.map` is something that you can pass to `.map` as kw and it'll process it fine.

The return value of `.map` in Python 3.7 is something like this, for the `TCombobox`:

```
<class 'dict'>: {'focusfill': [('readonly', 'focus', 'SystemHighlight')], 'foreground': [('disabled', 'SystemGrayText'), ('readonly', 'focus', 'SystemHighlightText')], 'selectforeground': [('!focus', 'SystemWindowText')], 'selectbackground': [('!focus', 'SystemWindow')]}
```

Which is as you'd expect (and the docs say): a dictionary of properties to lists, where each list can contain multiple tuples describing the required state and final value of the property.

However in Python 3.8, the value returned by `.map` is this:

```
<class 'dict'>: {'focusfill': ['readonly focus', 'SystemHighlight'], 'foreground': ['disabled', 'SystemGrayText', 'readonly focus', 'SystemHighlightText'], 'selectforeground': ['!focus', 'SystemWindowText'], 'selectbackground': ['!focus', 'SystemWindow']}
```

The tuples are missing. This then causes a number of problems downstream, such as the final property values being split into the constituent letters instead of the values within each tuple.

----------
components: Tkinter, Windows
messages: 355818
nosy: jslvtr, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Changes to tkinter result in (unexpected) widget map call return changes wrt. 3.7
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38661>
_______________________________________

From report at bugs.python.org  Fri Nov  1 10:38:58 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 01 Nov 2019 14:38:58 +0000
Subject: [issue37527] Timestamp conversion on windows fails with timestamps
 close to EPOCH
In-Reply-To: <1562668345.09.0.775729583969.issue37527@roundup.psfhosted.org>
Message-ID: <1572619138.74.0.952870586565.issue37527@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

This indeed seems to be a duplicate of 29097, which is fixed in Python 3.7, so we can close this bug. Thank you for your report Dschoni, and thank you for finding the duplicate Ma Lin!

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37527>
_______________________________________

From report at bugs.python.org  Fri Nov  1 10:40:49 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 01 Nov 2019 14:40:49 +0000
Subject: [issue38233] datetime.datetime.fromtimestamp have different behaviour
 on windows and mac
In-Reply-To: <1568991316.62.0.929906860007.issue38233@roundup.psfhosted.org>
Message-ID: <1572619249.37.0.385039208129.issue38233@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Changing the superceder here as I think #36439 matches better than #37527.

----------
nosy: +p-ganssle
resolution: duplicate -> 
status: closed -> open
superseder: Timestamp conversion on windows fails with timestamps close to EPOCH -> Inconsistencies with datetime.fromtimestamp(t) when t < 0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38233>
_______________________________________

From report at bugs.python.org  Fri Nov  1 10:54:38 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Nov 2019 14:54:38 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1572620078.51.0.587692564109.issue38631@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FWIW, I agree. :)

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Fri Nov  1 10:54:46 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 01 Nov 2019 14:54:46 +0000
Subject: [issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1572620086.44.0.449374666296.issue36439@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

This has been coming up in a few different contexts lately, so I think it would be really good if we could get some sort of fix for it.

One option is to implement our own versions of these APIs for use in Windows, but a thought occurred to me recently: we have not investigated the possibility of seeing if Microsoft would be willing to either add support for negative timestamps in their localtime() or gmtime() implementations or add a new API that *does* support negative timestamps. It would also be good to rule out the possibility that such APIs already exist but we just don't know about them (preliminary googling doesn't show anything, though possibly something can be done with the Win32 APIs? Not sure how or if those work in C and how big a lift it would be to maintain compatibility if can switch: https://docs.microsoft.com/en-us/windows/win32/sysinfo/time-functions?redirectedfrom=MSDN ).

Adding Steve Dower to the nosy list in case he can shed some light onto the possibility of native support.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Fri Nov  1 11:31:56 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Nov 2019 15:31:56 +0000
Subject: [issue38661] Changes to tkinter result in (unexpected) widget map
 call return changes wrt. 3.7
In-Reply-To: <1572618747.95.0.320564330748.issue38661@roundup.psfhosted.org>
Message-ID: <1572622316.57.0.0337298593305.issue38661@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38661>
_______________________________________

From report at bugs.python.org  Fri Nov  1 11:47:23 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 01 Nov 2019 15:47:23 +0000
Subject: [issue38159] PyState_AddModule docs should say that it's not
 necessary to call it.
In-Reply-To: <1568381139.47.0.152206625825.issue38159@roundup.psfhosted.org>
Message-ID: <1572623243.12.0.118859289394.issue38159@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 9bc94eca0c69a551f928692364a99e9b67c4a45b by Petr Viktorin in branch 'master':
bpo-38159: Clarify documentation of PyState_AddModule (GH-16101)
https://github.com/python/cpython/commit/9bc94eca0c69a551f928692364a99e9b67c4a45b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38159>
_______________________________________

From report at bugs.python.org  Fri Nov  1 11:47:43 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Nov 2019 15:47:43 +0000
Subject: [issue38159] PyState_AddModule docs should say that it's not
 necessary to call it.
In-Reply-To: <1568381139.47.0.152206625825.issue38159@roundup.psfhosted.org>
Message-ID: <1572623263.1.0.498943138063.issue38159@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16541
pull_request: https://github.com/python/cpython/pull/17026

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38159>
_______________________________________

From report at bugs.python.org  Fri Nov  1 11:47:49 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Nov 2019 15:47:49 +0000
Subject: [issue38159] PyState_AddModule docs should say that it's not
 necessary to call it.
In-Reply-To: <1568381139.47.0.152206625825.issue38159@roundup.psfhosted.org>
Message-ID: <1572623269.01.0.363267984222.issue38159@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16542
pull_request: https://github.com/python/cpython/pull/17027

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38159>
_______________________________________

From report at bugs.python.org  Fri Nov  1 12:09:01 2019
From: report at bugs.python.org (Ma Lin)
Date: Fri, 01 Nov 2019 16:09:01 +0000
Subject: [issue37527] Timestamp conversion on windows fails with timestamps
 close to EPOCH
In-Reply-To: <1562668345.09.0.775729583969.issue37527@roundup.psfhosted.org>
Message-ID: <1572624541.25.0.199227259761.issue37527@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

issue29097 fixed bug in `datetime.fromtimestamp()`.
But this issue is about `datetime.timestamp()`, not fixed yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37527>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:21:07 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 01 Nov 2019 17:21:07 +0000
Subject: [issue38657] String format for hexadecimal notation breaks padding
 with alternative form
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572628867.71.0.87166907389.issue38657@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Now that I re-read this, maybe it was a documentation request, not a functional change? I'd be okay with documenting the existing behavior, so I'll re-open this and change the type. Patches welcome.

----------
components: +Documentation
resolution: rejected -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:24:24 2019
From: report at bugs.python.org (Pradyun Gedam)
Date: Fri, 01 Nov 2019 17:24:24 +0000
Subject: [issue38662] Decouple ensurepip from pip's internals using runpy
Message-ID: <1572629064.24.0.519341934772.issue38662@roundup.psfhosted.org>


New submission from Pradyun Gedam <pradyunsg at gmail.com>:

Inspired by https://github.com/python/cpython/pull/16782#discussion_r335285656

This changes ensurepip's current assumption that pip would expose a "main" function, which can be invoked to run pip.

I've selected all actively supported Python versions for this ticket, since this patch should be backported to all Python versions, to make it robust to internal changes within pip.

----------
messages: 355826
nosy: Marcus.Smith, dstufft, ncoghlan, paul.moore, pradyunsg
priority: normal
severity: normal
status: open
title: Decouple ensurepip from pip's internals using runpy
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38662>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:25:39 2019
From: report at bugs.python.org (Pradyun Gedam)
Date: Fri, 01 Nov 2019 17:25:39 +0000
Subject: [issue38662] Decouple ensurepip from pip's internals using runpy
In-Reply-To: <1572629064.24.0.519341934772.issue38662@roundup.psfhosted.org>
Message-ID: <1572629139.29.0.0513709379367.issue38662@roundup.psfhosted.org>


Change by Pradyun Gedam <pradyunsg at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38662>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:31:35 2019
From: report at bugs.python.org (Edward K Ream)
Date: Fri, 01 Nov 2019 17:31:35 +0000
Subject: [issue38663] Untokenize does not round-trip ws before bs-nl
Message-ID: <1572629495.93.0.152221972505.issue38663@roundup.psfhosted.org>


New submission from Edward K Ream <edreamleo at gmail.com>:

Tested on 3.6.

tokenize.untokenize does not round-trip whitespace before backslash-newlines outside of strings:

from io import BytesIO
import tokenize

# Round tripping fails on the second string.
table = (
r'''
print\
    ("abc")
''',
r'''
print \
    ("abc")
''',
)
for s in table:
    tokens = list(tokenize.tokenize(
        BytesIO(s.encode('utf-8')).readline))
    result = g.toUnicode(tokenize.untokenize(tokens))
    print(result==s)

I have an important use case that would benefit from a proper untokenize. After considerable study, I have not found a proper fix for tokenize.add_whitespace.

I would be happy to work with anyone to rewrite tokenize.untokenize so that unit tests pass without fudges in TestRoundtrip.check_roundtrip.

----------
messages: 355827
nosy: edreamleo
priority: normal
severity: normal
status: open
title: Untokenize does not round-trip ws before bs-nl
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38663>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:38:26 2019
From: report at bugs.python.org (Pradyun Gedam)
Date: Fri, 01 Nov 2019 17:38:26 +0000
Subject: [issue38662] Decouple ensurepip from pip's internals using runpy
In-Reply-To: <1572629064.24.0.519341934772.issue38662@roundup.psfhosted.org>
Message-ID: <1572629906.25.0.808619272253.issue38662@roundup.psfhosted.org>


Pradyun Gedam <pradyunsg at gmail.com> added the comment:

Note that the patch uses the fact that:


```
def foo():
    try:
        raise Exception("returned")
    except Exception as e:
        print("except")
        return e.args[0]
    finally:
        print("finally")


print(foo())
```

will print:

```
except
finally
returned
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38662>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:49:13 2019
From: report at bugs.python.org (rmlibre)
Date: Fri, 01 Nov 2019 17:49:13 +0000
Subject: [issue38664] await execution order leads to throw or bad syntax
Message-ID: <1572630553.03.0.31312836907.issue38664@roundup.psfhosted.org>


New submission from rmlibre <rmlibre at riseup.net>:

If a coroutine returns a sequence, a user cannot write this clean code:

>>> await coro()[index]
Or,
>>> await coro()[slice]
Or,
>>> await coro()[key]

This raises a TypeError("'coroutine' object is not subscriptable"). To
solve this on the user side, one must add parentheses, leading to a 
convention of ugly syntax:

>>> (await coro())[...]

Or, hiding the parentesis away in a function

>>> async def index_coroutine(coro=None, index=None):
>>>     return (await coro)[index]
>>> await index_coroutine(coro(), slice(1, 5))

This is gross. It's a bug since it unnecessarily requires unpythonic 
code and throws pythonic code. My suggested patch would be to move the 
evaluation of the await statement higher up on the execution order so 
the former snippets would be valid python syntax. The await statement 
should imply parentheses when square brackets are used, since there is 
no other use case for indexing or subscripting a coroutine. This will
lead to more beautiful code.

----------
components: asyncio
messages: 355829
nosy: asvetlov, rmlibre, yselivanov
priority: normal
severity: normal
status: open
title: await execution order leads to throw or bad syntax
type: crash
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38664>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:56:46 2019
From: report at bugs.python.org (Dave Johansen)
Date: Fri, 01 Nov 2019 17:56:46 +0000
Subject: [issue38665] Crash when running SQLAlchemy with pyodbc
Message-ID: <1572631006.11.0.3731179051.issue38665@roundup.psfhosted.org>


New submission from Dave Johansen <davejohansen at gmail.com>:

We're using SQLAlchemy 1.3.10 with pyodbc 4.0.27 in the python:3.7.5-alpine docker image to connect to a MySQL 13.0.5026.0 database and it's crashing with the following error:
python: malloc.c:2406: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

----------
messages: 355830
nosy: Dave Johansen
priority: normal
severity: normal
status: open
title: Crash when running SQLAlchemy with pyodbc
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38665>
_______________________________________

From report at bugs.python.org  Fri Nov  1 14:11:39 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 01 Nov 2019 18:11:39 +0000
Subject: [issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1572631899.79.0.41194084773.issue36439@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I've emailed some colleagues to see what they can add here.

Ultimately, the Windows CRT is just doing arithmetic, since POSIX time formats do not resemble Windows time formats at all, so it's all emulation. So if we replaced it with our own calculation I don't think that would be the worst possible outcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Fri Nov  1 14:21:41 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Nov 2019 18:21:41 +0000
Subject: [issue38657] String format for hexadecimal notation breaks padding
 with alternative form
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572632501.18.0.397799604891.issue38657@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Nov  1 14:22:28 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 01 Nov 2019 18:22:28 +0000
Subject: [issue37527] Timestamp conversion on windows fails with timestamps
 close to EPOCH
In-Reply-To: <1562668345.09.0.775729583969.issue37527@roundup.psfhosted.org>
Message-ID: <1572632548.24.0.816344475222.issue37527@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Ah, my mistake. The examples all use `datetime.fromtimestamp`, so I didn't notice that it was failing only on the `timestamp` side. Re-opening, thanks!

----------
resolution: duplicate -> 
status: closed -> open
superseder: [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6 -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37527>
_______________________________________

From report at bugs.python.org  Fri Nov  1 14:40:07 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 01 Nov 2019 18:40:07 +0000
Subject: [issue38664] await execution order leads to throw or bad syntax
In-Reply-To: <1572630553.03.0.31312836907.issue38664@roundup.psfhosted.org>
Message-ID: <1572633607.46.0.329116090637.issue38664@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

What patch are you talking about?
For me, patch means something special; e.g. working fork of CPython where the proposed idea is implemented.

I read await coro()[key] as 
1. Function named coro() returns a dict-like object
2. An element under key is selected from dict, which is expected to be an awaitable.
3. The awaitable is awaited.

Pretty clear and unambiguous.

Changing await priority depending on the presence or absence of brackets on the right makes Python syntax very complex if possible at all.

Sorry, the proposal has zero chance to be accepted.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38664>
_______________________________________

From report at bugs.python.org  Fri Nov  1 14:42:10 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 01 Nov 2019 18:42:10 +0000
Subject: [issue38657] String format for hexadecimal notation breaks padding
 with alternative form
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572633730.95.0.506026804221.issue38657@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

The width doesn't mean "the number of bits", it means "the width of the field". In every other case too:

* when we format negative numbers, width includes the minus sign
* when we format decimal numbers, width includes decimal point (or comma)
* when we format strings with !r, width includes the quotes

So, not only would it break too much code, but it would actually be inconsistent to formatting all other types currently.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Nov  1 15:08:11 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 01 Nov 2019 19:08:11 +0000
Subject: [issue38430] Memory leak in ThreadPoolExecutor + run_in_executor
In-Reply-To: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>
Message-ID: <1572635291.11.0.0346324622384.issue38430@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> The change is slightly not backward compatible but

Yeah, that's my main problem with converting `loop.run_in_executor()` to a coroutine. When I attempted doing that I discovered that there's code that expects the method to return a Future, and so expects it have the `cancel()` method.

If we convert it to a coroutine a lot of code will break, which might be OK if it's really necessary. Is it though? Can we return a special Future subclass that complains if it's not awaited?  Would that fix the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38430>
_______________________________________

From report at bugs.python.org  Fri Nov  1 15:18:48 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 01 Nov 2019 19:18:48 +0000
Subject: [issue38430] Memory leak in ThreadPoolExecutor + run_in_executor
In-Reply-To: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>
Message-ID: <1572635928.4.0.350050499338.issue38430@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I thought about returning a special subclass.
Future has too rich API: get_loop(), done(), result() etc.

What's about returning the proxy object with future instance embedded; the object raises DeprecationWarning for everythin except __repr__, __del__ and __await__, __getattr__ redirects to getattr(self._fut, name) for all other attributes access. 

It is a more complex solution but definitely 100% backward compatible; plus the solution we can prepare people for removing the deprecated code eventually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38430>
_______________________________________

From report at bugs.python.org  Fri Nov  1 16:05:11 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Nov 2019 20:05:11 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572638711.59.0.724938350405.issue37903@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

After the PR, can someone easily  reproduce the interactive prompt sessions in the tutorial and maindocs.  Will it look the same?  Would they be able to build doctest examples in the IDLE shell?

This is marked for 3.7 through 3.9.  Do you intend to backport this PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 16:34:56 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 01 Nov 2019 20:34:56 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572640496.96.0.201956452555.issue37903@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

> After the PR, can someone easily  reproduce the interactive prompt sessions in the tutorial and maindocs.

Yes, except with prompts (both >>> and ...) in the sidebar rather than inline.

> Will it look the same?

No, see above.

> Would they be able to build doctest examples in the IDLE shell?

That's a good thought. It should be rather simple to add a context menu option to "copy for doctest" which would add the prompts to the copied text.

(By the way, how popular are doctests these days? My impression is that they've completely fallen out of style, but I'm sure that could vary between different areas and industries.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 16:38:45 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 01 Nov 2019 20:38:45 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572640725.96.0.375949080065.issue37903@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Stephen (Zero), thanks for the clarification.

FWIW I'm -1 on the ability to customize the prompts in the sidebar. It would complicate the implementation while reducing the straightforwardness and simplicity of IDLE.

Also, anyone who *really* wants to customize them could just change the hard-coded values in the code in their own copy of IDLE. I don't think it's worth the effort to make it more easily configurable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 16:41:04 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 01 Nov 2019 20:41:04 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572640864.95.0.27000019297.issue37903@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

> This is marked for 3.7 through 3.9.  Do you intend to backport this PR?

IDLE generally has a different backporting policy: We generally backport all IDLE development to all versions of Python that aren't in security-only or unmaintained status, except for 2.7. Currently, that means 3.7 and above.

There is always room for exceptions, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 16:44:53 2019
From: report at bugs.python.org (toonn)
Date: Fri, 01 Nov 2019 20:44:53 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1572641093.28.0.0656703608596.issue38656@roundup.psfhosted.org>


toonn <python at toonn.io> added the comment:

The result is the same for 3.7.4, on my mac.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Fri Nov  1 17:10:00 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 01 Nov 2019 21:10:00 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572642600.2.0.249055147792.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Also in this case run awaits and returns the result. Yury suggested earlier just to return the future and not await.

Yeah that's roughly what my initial version was doing. I'm personally leaning a bit more towards returning the future rather than the result, but I'm okay with either option. What are your thoughts on this Yury and Andrew?

> I agree that shutdown_default_executor and _do_shutdown should be changed to accept an executor argument so that any executor can be shutdown asynchronously

We could potentially add an internal method _shutdown_executor, but this would also require modification of _do_shutdown (so that it shuts down the executor passed, rather than the default one). I mentioned this in an earlier example, but this one shows all three together and changes _shutdown_executor to a method of BaseEventLoop:
        
    async def shutdown_default_executor(self):
        """Schedule the shutdown of the default executor."""
        self._executor_shutdown_called = True
        executor = self._default_executor
        await self._shutdown_executor(executor)

    async def _shutdown_executor(self, executor):
        if executor is None:
            return
        future = self.create_future()
        thread = threading.Thread(target=self._do_shutdown, args=(executor,future))
        thread.start()
        try:
            await future
        finally:
            thread.join()

    def _do_shutdown(self, executor, future):
        try:
            executor.shutdown(wait=True)
            self.call_soon_threadsafe(future.set_result, None)
        except Exception as ex:
            self.call_soon_threadsafe(future.set_exception, ex)

Functionally, it works the same for shutdown_default_executor(), but allows _shutdown_executor to be used for asyncio.ThreadPool as well. Since GH-16360 (adding timeout param) also makes changes to shutdown_default_executor(), it will be blocking this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 17:12:46 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 01 Nov 2019 21:12:46 +0000
Subject: [issue38430] Memory leak in ThreadPoolExecutor + run_in_executor
In-Reply-To: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>
Message-ID: <1572642766.35.0.101843755335.issue38430@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> It is a more complex solution but definitely 100% backward compatible; plus the solution we can prepare people for removing the deprecated code eventually.

Yeah.  Do you think it's worth it bothering with this old low-level API instead of making a new high-level one?  I don't, but if you do the feel free to change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38430>
_______________________________________

From report at bugs.python.org  Fri Nov  1 17:14:36 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Nov 2019 21:14:36 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572642876.98.0.783483375313.issue37903@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> By the way, how popular are doctests these days?

Arguably, Sphinx has made them more popular than ever.  For me, they are essential.  And as long as doctest remains a non-deprecated module, we have to retain support.

For the record, I'm opposed to backporting this to 3.8 and 3.7.  If this PR ends-up killing our teaching workflow, we need something to fallback to.  Also, you don't want to immediately invalidate every video or written tutorial that uses IDLE for demonstrations.

> Raymond, with the current PR, this replaces the inline prompts. 
> Making it toggle-able could be very awkward. Is this a 
> deal-breaker in your opinion?

I can't tell for sure because I'm having a hard time building with Tkinter support, so I can't easily try out the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 17:24:45 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Nov 2019 21:24:45 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1572643485.5.0.637909748902.issue38500@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

It depends on how you look at the degree to which you are interacting with the runtime.  This is a fairly low-level hook into the runtime.  So arguably if you are using this API then you should specify being a "core" extension.  That said, getting that clever about it is a bit too much.  The authors or PEP 523 can correct me if I'm wrong, but it seems like there isn't a good reason to restrict access.

So basically, I agree with you. :)

How about one of the following?

* _PyInterpreterState_SetEvalFrame(_PyFrameEvalFunction eval_frame)
* _PyInterpreterState_SetFrameEval(_PyFrameEvalFunction eval_frame)

The underscore basically says "don't use this unless you know what you are doing".  Or perhaps that is overkill too?  "_PyFrameEvalFunction" has an underscore, so perhaps not.

Also, it would make sense to have a matching getter.

----------
nosy: +brett.cannon, dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov  1 17:38:43 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 01 Nov 2019 21:38:43 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572644323.03.0.953214640452.issue32309@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Few thoughts:

1. I like the idea of having a context manager to create a thread pool. It should be initialized in a top-level coroutine and the passed down to other code, as in:

  async def main():
    async with asyncio.ThreadPool(concurrency=10) as pool:
      await something(pool)
      await something_else(pool)

      await pool.run(callable, *args)

  asyncio.run(main())

2. It should be the "async with".

3. We should not reuse the default executor. The default executor is used for things like DNS resolution.  We don't want network activity to pause just because some task offloaded some blocking computation to its pool.

4. I think it's OK to initialize the thread pool in `ThreadPool.__init__`.  `ThreadPool.__aenter__` would simply return `self` then.

5. `await ThreadPool.aclose()` would close the loop gracefully (awaiting for all submitted and still running callables) in cases when people use the threadpool without 'async with'.

6. I think we should aim for shipping a replacement for `loop.run_in_executor` in 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 17:50:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Nov 2019 21:50:54 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572645054.59.0.295802192812.issue37903@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As stated in my second opening sentence, this issue "implements the first phase of #37892", which gives the context and specific rationale.

There are 3 separate parts to a Python Shell.

1. Code entry, indentation, display, and copying.  This issue fixes Shell design flaws that have been recognized as such for at least 15 years.  In the process, it makes Shell *more similar* to the standard REPL in important respects.  In particular, by default, compound statements will look the same in Shell as the same code entered into REPL with 4-space indents.  It will also be possible to cut and paste into an editor have it look right.

Raymond: I do not plan to retain a buggy shell mode that in #7676 you called a "major PITA" (msg215288) and "a continual source of frustration for students in my Python courses" that you were "looking forward to it being fixed."

2. Code execution.  IDLE executes syntactically correct user code so that, to the extent possible and sensible, the result is the same as if executed directly with python.  Not an issue here.

3. Everything else.  Alternate shells are intentionally difference from and hopefully improve upon the interactive python.exe REPL.

Paul: The existence of two prompts, sys.ps1 and sys.ps2 in python.exe interactive mode is a kludge needed to interface nested multiline statement Python with *single text line entry* system terminals.  I believe that most beginners never fiddle with them.

IDLE's Shell is a GUI-based python-statement-aware interface.  The python.exe executing user code from shell or editor is never in interactive mode.  For statements entered and executed, '>>>' is quite sufficient to mark code.  The sidebar should be minimal and unobtrusive and 3 columns is sufficient.  So I reject the idea of expanding it.

#37892 mentions the possibility of later adding an expanded full-line prompt for the code entry area, such as "Enter below a complete Python statement."  When we get to that, we can consider an option (for non-beginners) to customize it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 18:10:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Nov 2019 22:10:08 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1572646208.31.0.300698841537.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

(I have a few more functions that I would like to patch, so I keep the issue open as place holder.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Fri Nov  1 18:17:57 2019
From: report at bugs.python.org (Dino Viehland)
Date: Fri, 01 Nov 2019 22:17:57 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1572646677.63.0.18481302039.issue38500@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

Adding the getter/setters seems perfectly reasonable to me, and I agree they should be underscore prefixed as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov  1 18:30:10 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 01 Nov 2019 22:30:10 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572647410.03.0.553910578438.issue37903@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

To help get a feel for what the current PR looks like, I'm attaching a screenshot (taken on Windows 10).

----------
Added file: https://bugs.python.org/file48690/screenshot.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 18:50:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Nov 2019 22:50:51 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572648651.68.0.459310107653.issue37903@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks.  Can you also show a script running with F5 showing a restart, the output from the script and a subsequent interactive session that shows the inspecting variables.  Also show what an exception and SyntaxError looks like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Fri Nov  1 20:57:57 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 02 Nov 2019 00:57:57 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572656277.92.0.719838239937.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> async with asyncio.ThreadPool(concurrency=10) as pool:

I'm definitely on board with the usage of an async context manager and the functionality shown in the example, but I'm not sure that I entirely understand what the "concurrency" kwarg in "concurrency=10" is supposed to represent in this case. Could you elaborate on what that would do functionally?

> It should be the "async with".

> We should not reuse the default executor.

> I think it's OK to initialize the thread pool in `ThreadPool.__init__`.  `ThreadPool.__aenter__` would simply return `self` then.

> I think we should aim for shipping a replacement for `loop.run_in_executor` in 3.9.

Strong +1 on all of those points, I agree. 

> `await ThreadPool.aclose()` would close the loop gracefully (awaiting for all submitted and still running callables) in cases when people use the threadpool without 'async with'.

I believe behavior occurs within shutdown_default_executor(), correct? Specifically, within for ThreadPoolExecutor when executor.shutdown(wait=True) is called and all of the threads are joined without a timeout, it simply waits for each thread to terminate gracefully. 

So if we moved that functionality to a private coroutine method _shutdown_executor() as suggested in my above example, this could also be done for ThreadPool. Unless you want ThreadPool to be it's own entirely separate implementation that doesn't depend at all on ThreadPoolExecutor. 

Personally I think we can use ThreadPoolExecutor in the internal details; it seems that the main issue with it isn't the functionality, but rather the low level API offered with loop.run_in_executor().

Also another point to consider is if we should have users explicitly call pool.aclose() or if this should be done automatically when exiting the context manager through the __aexit__. I prefer the latter myself for similar reasons to what I previously mentioned, with a context manager initializing it's own resources on entry and finalizing them upon exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 21:03:14 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Nov 2019 01:03:14 +0000
Subject: [issue37892] IDLE Shell: isolate user code input
In-Reply-To: <1566301123.94.0.491748175182.issue37892@roundup.psfhosted.org>
Message-ID: <1572656594.4.0.933047171799.issue37892@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

One of the related changes is to add multiple options for saving the shell history.  For editing, one wants code without prompts and output either omitting or commented out.  For doctests, one wants code with '>>> ' and '... ' prompts and unmarked output.

A second would be to *not* print SyntaxError and a new prompt, but to otherwise indicate 'error' and put the cursor after the already highlighted error, as done in the editor.

A third would being able to submit multiline statements for execution with with F5 instead of having to go to the end of the last line and enter a blank line.  This would be especially useful after correcting a syntax error or other typo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37892>
_______________________________________

From report at bugs.python.org  Fri Nov  1 21:16:41 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 02 Nov 2019 01:16:41 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572657401.72.0.585416912541.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I believe behavior occurs within shutdown_default_executor(), correct? Specifically, within for ThreadPoolExecutor when executor.shutdown(wait=True) is called and all of the threads are joined without a timeout, it simply waits for each thread to terminate gracefully.
 
Correction, I phrased this poorly:

I believe this behavior occurs within shutdown_default_executor(), correct? Specifically, when executor.shutdown(wait=True) is called within _do_shutdown() and ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 21:16:45 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 02 Nov 2019 01:16:45 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572657405.46.0.488393675269.issue32309@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

>> async with asyncio.ThreadPool(concurrency=10) as pool:

> I'm definitely on board with the usage of an async context manager and the functionality shown in the example, but I'm not sure that I entirely understand what the "concurrency" kwarg in "concurrency=10" is supposed to represent in this case. Could you elaborate on what that would do functionally?

Number of OS threads to spawn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 21:50:25 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 02 Nov 2019 01:50:25 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572659425.26.0.273053171266.issue38630@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

-1 about the PR solution to suppress ProcessLookupError in case the process is gone. In psutil I solved the ?pid reused problem? by using process creation time to identify a process uniquely (on start). 
A decorator can be used to protect the sensibile methods interacting with the PID/handle (communicate(), send_signal(), terminate(), kill()) and raise an exception (maybe ProcessLooKupError(?PID has been reused?)?).

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Fri Nov  1 22:48:35 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 02 Nov 2019 02:48:35 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572662915.79.0.149351431281.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Number of OS threads to spawn.

Ah I see, so this would correspond with the "max_workers" argument of ThreadPoolExecutor then, correct? If so, we could pass this in the __init__ for ThreadPool:

def __init__(self, concurrency):
    ...
    self._executor = concurrent.futures.ThreadPoolExecutor(max_workers=concurrency)

IMO, I think it would be a bit more clear to just explicitly call it "threads" or "max_threads", as that explains what it's effectively doing. While "concurrency" is still a perfectly correct way of describing the behavior, I think it might be a little too abstract for an argument name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 22:51:05 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 02 Nov 2019 02:51:05 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572663065.67.0.0260276318216.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> def __init__(self, concurrency=None):

Minor clarification: the default should probably be None, which would effectively set the default maximum number of threads to min(32, os.cpu_count() + 4), once it's passed to ThreadPoolExecutor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  1 22:59:23 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Nov 2019 02:59:23 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572663563.28.0.316098473504.issue37903@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My previous response was to comments up to msg355812.

To answer Raymond's subsequent questions: The user will enter python code the same as before.  Currently, the indents and resulting appearance of the code on Shell screen is different from (and worse, sometimes far worse, than) the appearance of the same code in the REPL.  After this patch *and* a required immediate follow-up to replace tab indents with, by default, 4-space indents, the code on the screen *and in saved sessions* will appear the same as in the REPL (when 4-space indents are used).

In Tal's screenshot, the appearance is better, but the indents are still tabs.  Because of the regression being fixed by #38636, PR 17008, he could not manually switch with alt-T and alt-U.

(The current sidebar patch is also missing output markers.  Also, for my custom dark theme, I colored the sidebar dark blue on light bluish gray and the result, to me, is aesthetically much more pleasing than in the screenshot.)

The improvement is, to me, even more evident in the following pair of examples -- first REPL and improved IDLE, second current IDLE. 

>>> if True:
...     print('true')
... else:
...     print('false')

versus

>>> if True:
        print('true')
else:
        print('false')

#7676 was marked as a bugfix issue and I regard changing examples like the above to be a long-overdue and badly needed fix.  Any version that does not get this fix will also not get followup changes.  I just added msg355853 to #37892 to list some I have thought of.

One of my intended followups is to add multiple ways of saving a shell session.  IDLE can juggle prompts/markers, code, and output to match 'templates' much easier than users can.  I had not thought about doctests, but saving shell interaction in the proper format should be an easy addition.

SyntaxErrors aside, output will be the same as it is in IDLE now, with 'Out', 'Err', and maybe 'Inp' markers ('Imp' for user code input(prompt) lines) planned for the sidebar.

IDLE already handles syntax errors in the code being entered differently from the REPL by replacing the caret line with an error highlight, as in the editor.  I would like it follow the logic of not imitating dumb terminals by putting the cursor at the marked spot, as in the editor, and letting the user directly correct the problem.  Messing up the input with a usually useless traceback and a new prompt and requiring retrieval of the statement with the marker removed and the cursor in the wrong place is a nuisance.  I also don't see any reason to burden the session history with bad code that was never submitted for execution.  (Note that IDLE does not RESTART when code in the editor has syntax errors.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 00:01:37 2019
From: report at bugs.python.org (wesinator)
Date: Sat, 02 Nov 2019 04:01:37 +0000
Subject: [issue37607] segfault running code in jupyter on macOS 10.14.5 -
 crashed on child side of fork pre-exec
In-Reply-To: <1563296203.64.0.981111226039.issue37607@roundup.psfhosted.org>
Message-ID: <1572667297.72.0.972525823396.issue37607@roundup.psfhosted.org>


wesinator <13hurdw at gmail.com> added the comment:

Thanks ned - should I report issue to libcurl ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37607>
_______________________________________

From report at bugs.python.org  Sat Nov  2 01:02:04 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 02 Nov 2019 05:02:04 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572670924.04.0.432690901478.issue37903@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Strong +1. I should have done this 20 years ago.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 01:19:56 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 02 Nov 2019 05:19:56 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1572662915.79.0.149351431281.issue32309@roundup.psfhosted.org>
Message-ID: <k2h45y0o.80268357-4593-4fe5-a38a-2f34de495e64@we.are.superhuman.com>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> 
> 
> 
> IMO, I think it would be a bit more clear to just explicitly call it
> "threads" or "max_threads", as that explains what it's effectively doing.
> While "concurrency" is still a perfectly correct way of describing the
> behavior, I think it might be a little too abstract for an argument name.
> 
> 
> 

> 
> 
> 
> 
> 
> 
> 

And that's why I like it. If we add ProcessPool it will have the same argument: concurrency.

max_workers isn't correct, as we want to spawn all threads and all processes when we start. Thus btw makes me think that initializing threads/processes in __init__ is a bad idea, as spawning can be asynchronous.

> 
> 
> 
> 
> 
> 
> 
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Sat Nov  2 02:30:56 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 02 Nov 2019 06:30:56 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572676256.75.0.635023305072.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> And that's why I like it. If we add ProcessPool it will have the same argument: concurrency.

> max_workers isn't correct, as we want to spawn all threads and all processes when we start. Thus btw makes me think that initializing threads/processes in __init__ is a bad idea, as spawning can be asynchronous.

Ah, I see, that would make sense then if we're considering adding a ProcessPool at some point and want to make the argument name the same. Based on your ideas so far, it seems that it will likely not be compatible with the existing ThreadPoolExecutor. 

>From my understanding, the executor classes are designed around spawning the threads (or processes in the case of ProcessPoolExecutor) as needed up to max_workers, rather than spawning them upon startup. The asynchronous spawning of threads or processes would also not be compatible with the executor subclasses as far as I can tell. 

I can start working on a draft/prototype for a design. It will likely take more time to implement this, but it will give us the chance to have a native asyncio ThreadPool that doesn't directly rely upon the API in concurrent.futures. 

Also, would you prefer for there to be an abstract asyncio.AbstractPool class that ThreadPool inherits from? I think this would make it more streamlined to implement a similar ProcessPool at some point in the future. This would be similar to the relationship between the Executor class and ThreadPoolExecutor, or AbstractEventLoop and BaseEventLoop.

Let me know if you approve of this idea Yury and Andrew. It's quite a bit more involved than implementing a simple high level version of loop.run_in_executor(), but I think it would prove to be worthwhile in the long term.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Sat Nov  2 05:15:48 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Nov 2019 09:15:48 +0000
Subject: [issue38601] Couldn't able to install multiple python minor version
 in windows due to EXE script
In-Reply-To: <1572178164.18.0.338058343246.issue38601@roundup.psfhosted.org>
Message-ID: <1572686148.95.0.768076283458.issue38601@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38601>
_______________________________________

From report at bugs.python.org  Sat Nov  2 05:55:09 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 02 Nov 2019 09:55:09 +0000
Subject: [issue38430] Memory leak in ThreadPoolExecutor + run_in_executor
In-Reply-To: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>
Message-ID: <1572688509.05.0.338520541532.issue38430@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The API exists, people use it and get the memory leak.
We should either remove the API (not realistic dream at least for many years) or fix it.  There is no choice actually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38430>
_______________________________________

From report at bugs.python.org  Sat Nov  2 06:35:17 2019
From: report at bugs.python.org (Tal Einat)
Date: Sat, 02 Nov 2019 10:35:17 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572690917.03.0.231428734443.issue37903@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

With the support from Guido and others here and on idle-dev, Terry and I will be moving forward with this change.

However, I take Raymond's concern about this "killing our teaching workflow" seriously. Raymond, let's please work to figure out how to make sure this improves, rather than degrades, the teaching of Python with IDLE. I'd be happy to work on features, updating documentation, outreach, or anything else that this would require.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 07:26:40 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Sat, 02 Nov 2019 11:26:40 +0000
Subject: [issue36490] Modernize function signature in Archiving section of
 shutil doc
In-Reply-To: <1554005288.19.0.789880523073.issue36490@roundup.psfhosted.org>
Message-ID: <1572694000.41.0.379636027258.issue36490@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

Sorry for the lack of response on this one; it just slipped off my radar. It seems quite clear that my understanding was incomplete as to why the signatures were expressed this way. As such, I presume this can just be closed as NOTABUG? I'll close in a week (assuming I remember) if I don't hear otherwise or someone else doesn't first. Thanks and sorry for bothering folks on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36490>
_______________________________________

From report at bugs.python.org  Sat Nov  2 08:52:53 2019
From: report at bugs.python.org (sattari)
Date: Sat, 02 Nov 2019 12:52:53 +0000
Subject: [issue38666] is for tuples
Message-ID: <1572699173.61.0.959561207452.issue38666@roundup.psfhosted.org>


New submission from sattari <sattar.sattari at gmail.com>:

The following code gives different results interactive and script mode:

e = (1, 2)
f = (1, 2)
print(e is f)

----------
messages: 355867
nosy: sattari
priority: normal
severity: normal
status: open
title: is for tuples
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38666>
_______________________________________

From report at bugs.python.org  Sat Nov  2 09:14:24 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Sat, 02 Nov 2019 13:14:24 +0000
Subject: [issue38667] PYTHONCOERCECLOCALE=0 ignored
Message-ID: <1572700464.48.0.125378742934.issue38667@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

Python 3.7.5rc1 and 3.8.0 on Ubuntu 19.10

$ LC_CTYPE=C PYTHONCOERCECLOCALE=warn python3 -c "import sys; print(sys.getfilesystemencoding())"
Python detected LC_CTYPE=C: LC_CTYPE coerced to C.UTF-8 (set another locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behavior).
utf-8

$ LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -c "import sys; print(sys.getfilesystemencoding())"   
utf-8

The warning states that passing PYTHONCOERCECLOCALE=0 disables the coercion, but it doesn't change anything in 3.7 and 3.8.

What am I missing?

----------
messages: 355868
nosy: lazka
priority: normal
severity: normal
status: open
title: PYTHONCOERCECLOCALE=0 ignored
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38667>
_______________________________________

From report at bugs.python.org  Sat Nov  2 10:05:58 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Nov 2019 14:05:58 +0000
Subject: [issue38666] is for tuples
In-Reply-To: <1572699173.61.0.959561207452.issue38666@roundup.psfhosted.org>
Message-ID: <1572703558.32.0.753629658318.issue38666@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

"is" compares by identity not equality. Since tuples are immutable, the interpreter is free to reuse or not reuse the same tuple instance when it appears multiple times in a program. This is an implementation detail not a bug.

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38666>
_______________________________________

From report at bugs.python.org  Sat Nov  2 10:10:21 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 02 Nov 2019 14:10:21 +0000
Subject: [issue38667] PYTHONCOERCECLOCALE=0 ignored
In-Reply-To: <1572700464.48.0.125378742934.issue38667@roundup.psfhosted.org>
Message-ID: <1572703821.14.0.480522524641.issue38667@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38667>
_______________________________________

From report at bugs.python.org  Sat Nov  2 10:23:44 2019
From: report at bugs.python.org (Pete Wicken)
Date: Sat, 02 Nov 2019 14:23:44 +0000
Subject: [issue38657] String format for hexadecimal notation breaks padding
 with alternative form
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572704624.25.0.877687961818.issue38657@roundup.psfhosted.org>


Pete Wicken <petewicken at gmail.com> added the comment:

Given the comments above I appreciate that this is actually due to the padding being the total field width rather than the padding of the digits themselves. Having revised the documentation again, I believe this following line is explaining it:

"When no explicit alignment is given, preceding the width field by a zero ('0') character enables sign-aware zero-padding for numeric types. This is equivalent to a fill character of '0' with an alignment type of '='."

(https://docs.python.org/3.8/library/string.html)

I initially read "sign-aware zero-padding for numeric types" to mean the padding would not blindly prepend, and would take into account any signs and pad after (hence initially making this a bug). So maybe as suggested above we should explicitly mention the padding is the total number of characters in the field, rather than just the numbers.

I can look into adding this soon and see what you all think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Sat Nov  2 10:45:15 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Nov 2019 14:45:15 +0000
Subject: [issue37607] segfault running code in jupyter on macOS 10.14.5 -
 crashed on child side of fork pre-exec
In-Reply-To: <1563296203.64.0.981111226039.issue37607@roundup.psfhosted.org>
Message-ID: <1572705915.41.0.267610145307.issue37607@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> should I report issue to libcurl

It wouldn't hurt although they probably are aware of the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37607>
_______________________________________

From report at bugs.python.org  Sat Nov  2 11:18:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Nov 2019 15:18:39 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572707919.19.0.0993123885329.issue37903@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Do you still plan to backport to 3.7 and 3.8?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 12:41:06 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Nov 2019 16:41:06 +0000
Subject: [issue38279] multiprocessing example enhancement
In-Reply-To: <1569433034.47.0.652580755416.issue38279@roundup.psfhosted.org>
Message-ID: <1572712866.73.0.992002249322.issue38279@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I rejected the accompanying PR and the changes it proposed, therefore it seems reasonable to close this issue as well.

----------
nosy: +pitrou
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38279>
_______________________________________

From report at bugs.python.org  Sat Nov  2 12:46:50 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 02 Nov 2019 16:46:50 +0000
Subject: [issue38422] Clarify docstrings of pathlib suffix(es)
In-Reply-To: <1570634139.23.0.159522926495.issue38422@roundup.psfhosted.org>
Message-ID: <1572713210.28.0.860659922997.issue38422@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16544
pull_request: https://github.com/python/cpython/pull/17031

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38422>
_______________________________________

From report at bugs.python.org  Sat Nov  2 12:47:00 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 02 Nov 2019 16:47:00 +0000
Subject: [issue38422] Clarify docstrings of pathlib suffix(es)
In-Reply-To: <1570634139.23.0.159522926495.issue38422@roundup.psfhosted.org>
Message-ID: <1572713220.08.0.167583583051.issue38422@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8d4fef4ee2a318097f429cf6cbd4fb2e430bb9da by Miss Skeleton (bot) (Ram Rachum) in branch 'master':
bpo-38422: Clarify docstrings of pathlib suffix(es) (GH-16679)
https://github.com/python/cpython/commit/8d4fef4ee2a318097f429cf6cbd4fb2e430bb9da


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38422>
_______________________________________

From report at bugs.python.org  Sat Nov  2 12:47:00 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 02 Nov 2019 16:47:00 +0000
Subject: [issue38422] Clarify docstrings of pathlib suffix(es)
In-Reply-To: <1570634139.23.0.159522926495.issue38422@roundup.psfhosted.org>
Message-ID: <1572713220.9.0.309743139452.issue38422@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16545
pull_request: https://github.com/python/cpython/pull/17032

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38422>
_______________________________________

From report at bugs.python.org  Sat Nov  2 12:47:18 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Nov 2019 16:47:18 +0000
Subject: [issue38422] Clarify docstrings of pathlib suffix(es)
In-Reply-To: <1570634139.23.0.159522926495.issue38422@roundup.psfhosted.org>
Message-ID: <1572713238.33.0.608809764314.issue38422@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -miss-islington
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38422>
_______________________________________

From report at bugs.python.org  Sat Nov  2 13:04:13 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 02 Nov 2019 17:04:13 +0000
Subject: [issue38422] Clarify docstrings of pathlib suffix(es)
In-Reply-To: <1570634139.23.0.159522926495.issue38422@roundup.psfhosted.org>
Message-ID: <1572714253.46.0.561649975951.issue38422@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset aa1fee8ffb0fb77a873c69d311759081346f8f4a by Miss Skeleton (bot) in branch '3.8':
bpo-38422: Clarify docstrings of pathlib suffix(es) (GH-16679)
https://github.com/python/cpython/commit/aa1fee8ffb0fb77a873c69d311759081346f8f4a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38422>
_______________________________________

From report at bugs.python.org  Sat Nov  2 13:04:21 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 02 Nov 2019 17:04:21 +0000
Subject: [issue38422] Clarify docstrings of pathlib suffix(es)
In-Reply-To: <1570634139.23.0.159522926495.issue38422@roundup.psfhosted.org>
Message-ID: <1572714261.22.0.853435360843.issue38422@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 72b874a2ac6a7c1931e8b60fb865dc57adb441ee by Miss Skeleton (bot) in branch '3.7':
bpo-38422: Clarify docstrings of pathlib suffix(es) (GH-16679)
https://github.com/python/cpython/commit/72b874a2ac6a7c1931e8b60fb865dc57adb441ee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38422>
_______________________________________

From report at bugs.python.org  Sat Nov  2 13:05:34 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Nov 2019 17:05:34 +0000
Subject: [issue38422] Clarify docstrings of pathlib suffix(es)
In-Reply-To: <1570634139.23.0.159522926495.issue38422@roundup.psfhosted.org>
Message-ID: <1572714334.47.0.444763466899.issue38422@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38422>
_______________________________________

From report at bugs.python.org  Sat Nov  2 13:27:53 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Nov 2019 17:27:53 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572715673.78.0.190965301791.issue37903@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 13:41:04 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Sat, 02 Nov 2019 17:41:04 +0000
Subject: [issue38668] Update os.path documentation regarding recommended types
Message-ID: <1572716464.69.0.00560937952319.issue38668@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

At the very top of https://docs.python.org/3.9/library/os.path.html there is this section regarding str and bytes:

> The path parameters can be passed as either strings, or bytes.

They also accept path-like since Python 3.6, see https://www.python.org/dev/peps/pep-0519/ (Adding a file system path protocol). I'd add path-like to the list.

> Unfortunately, some file names may not be representable as strings on Unix, so applications that need to support arbitrary file names on Unix should use bytes objects to represent path names.

This is no longer true since Python 3.1 and https://www.python.org/dev/peps/pep-0383/ (Non-decodable Bytes in System Character Interfaces). I'd suggest to delete this.

> Vice versa, using bytes objects cannot represent all file names on Windows (in the standard mbcs encoding), hence Windows applications should use string objects to access all files.

This is no longer true since Python 3.6 and https://www.python.org/dev/peps/pep-0529/ (Change Windows filesystem encoding to UTF-8). I'd suggest to delete this as well.

----------
assignee: docs at python
components: Documentation
messages: 355878
nosy: docs at python, lazka
priority: normal
severity: normal
status: open
title: Update os.path documentation regarding recommended types
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38668>
_______________________________________

From report at bugs.python.org  Sat Nov  2 14:16:57 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Nov 2019 18:16:57 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572718617.88.0.482982863093.issue37903@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy:  -rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 14:29:01 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Nov 2019 18:29:01 +0000
Subject: [issue38382] statistics.harmonic_mean fails to raise error with
 negative input that follows a 0
In-Reply-To: <1570326378.93.0.0728676630318.issue38382@roundup.psfhosted.org>
Message-ID: <1572719341.07.0.484302357292.issue38382@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Can we go back to the original issue? Should we just 
> document the "early out" behaviour on hitting zero,
> or should we follow the suggestion to check for bad 
> data and raise?

I would follow Tim's recommendation to document it and be done with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38382>
_______________________________________

From report at bugs.python.org  Sat Nov  2 14:33:35 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 02 Nov 2019 18:33:35 +0000
Subject: [issue38657] String format for hexadecimal notation breaks padding
 with alternative form
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572719615.9.0.394687570323.issue38657@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

It seems that you're confusing two things that really don't have much in common.

* (field) width is a _number_, saying how many characters (at least) should the formatted output take.
* padding is a bool (or maybe a char), saying what should be put inside the leftover space if the default formatted output is shorter than the width

The padding is not the width, and the width is not the padding. Once you start to differentiate those two things, I'm convinced all your confusions will disappear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Sat Nov  2 15:19:37 2019
From: report at bugs.python.org (Marco Rougeth)
Date: Sat, 02 Nov 2019 19:19:37 +0000
Subject: [issue38592] Add pt-br to the language switcher at the Python docs
 website
In-Reply-To: <1572034700.82.0.68590075216.issue38592@roundup.psfhosted.org>
Message-ID: <1572722377.28.0.385659087414.issue38592@roundup.psfhosted.org>


Change by Marco Rougeth <marco at rougeth.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38592>
_______________________________________

From report at bugs.python.org  Sat Nov  2 16:54:29 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 02 Nov 2019 20:54:29 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572728069.97.0.103098961811.issue32309@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

>  From my understanding, the executor classes are designed around spawning the threads (or processes in the case of ProcessPoolExecutor) as needed up to max_workers, rather than spawning them upon startup. The asynchronous spawning of threads or processes would also not be compatible with the executor subclasses as far as I can tell. 

> I can start working on a draft/prototype for a design. It will likely take more time to implement this, but it will give us the chance to have a native asyncio ThreadPool that doesn't directly rely upon the API in concurrent.futures. 

No, that would be too much work. Writing a thread pool or process pool from scratch is an extremely tedious task and it will take us years to stabilize the code. It's not simple.

We should design *our* API correctly though. And that means that we can't initialize our pools in __init__.

Something along these lines would work:

    class ThreadPool:
      async def start(): ...
      async def __aenter__(self): 
        await self.start()
        return self
      
      async def aclose(): ...
      async def __aexit__(self, *exc):
        await self.aclose()


> Let me know if you approve of this idea Yury and Andrew. It's quite a bit more involved than implementing a simple high level version of loop.run_in_executor(), but I think it would prove to be worthwhile in the long term.

It shouldn't be much harder than run_in_executor() as we continue to rely on concurrent.future (at least for the first version).

We need to start the discussion about this API on discourse.  Please give me a few days to organize that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Sat Nov  2 17:26:06 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 02 Nov 2019 21:26:06 +0000
Subject: [issue38430] Memory leak in ThreadPoolExecutor + run_in_executor
In-Reply-To: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>
Message-ID: <1572729966.89.0.629014254881.issue38430@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> We should either remove the API (not realistic dream at least for many years) or fix it.  There is no choice actually.

I don't understand. What happens if we don't await the future that run_in_executor returns? Does it get GCed eventually? Why is memory leaking?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38430>
_______________________________________

From report at bugs.python.org  Sat Nov  2 17:39:44 2019
From: report at bugs.python.org (stein-k)
Date: Sat, 02 Nov 2019 21:39:44 +0000
Subject: [issue24159] Misleading TypeError when pickling bytes to a file
 opened as text
In-Reply-To: <1431268460.0.0.240754621807.issue24159@psf.upfronthosting.co.za>
Message-ID: <1572730784.51.0.214109395619.issue24159@roundup.psfhosted.org>


Change by stein-k <karlsen.stein at gmail.com>:


----------
nosy: +stein-k

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24159>
_______________________________________

From report at bugs.python.org  Sat Nov  2 18:15:31 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS2lzcyBLb2xsw6Fy?=)
Date: Sat, 02 Nov 2019 22:15:31 +0000
Subject: [issue38653] pkgutil.extend_path fails with zipped eggs if not at
 first place
In-Reply-To: <1572521308.12.0.490608170281.issue38653@roundup.psfhosted.org>
Message-ID: <1572732931.81.0.807791167732.issue38653@roundup.psfhosted.org>


Change by L?szl? Kiss Koll?r <kiss.kollar.laszlo at gmail.com>:


----------
nosy: +lkollar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38653>
_______________________________________

From report at bugs.python.org  Sat Nov  2 19:28:52 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 02 Nov 2019 23:28:52 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572737332.62.0.1063298094.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> No, that would be too much work. Writing a thread pool or process pool from scratch is an extremely tedious task and it will take us years to stabilize the code. It's not simple.

> We should design *our* API correctly though. And that means that we can't initialize our pools in __init__.

I can see that it would be a lot of additional work, that's why I was using ThreadPoolExecutor in my earlier prototype. 

The main issue that I'm not seeing though is how exactly we're going to actually spawn the threads or processes asynchronously upon *startup* in ThreadPool using ThreadPoolExecutor's existing public API, with only the submit(), map(), and shutdown() methods. 

Unless I'm misunderstanding something, the executor classes were not designed with that intention in mind. With Executor, a new thread/process (worker) is spawned *as needed* when submit() is called throughout the lifespan of the Executor up to max_workers, rather than upon startup as you're wanting ThreadPool to do. 

Thus, it seemed to make more sense to me to actually build up a new Pool class from scratch that was largely based on Executor, but with significantly differing functionality. Otherwise, it seems like we would have to make some modifications to ThreadPoolExecutor, or inherit from it and then redesign the internals of some of the methods to change the way the threads/processes are spawned. 

> It shouldn't be much harder than run_in_executor() as we continue to rely on concurrent.future (at least for the first version).

I think that run_in_executor() was far more simple compared to this. The functionality of run_in_executor() almost maps directly to executor.submit(), other than a few conditional checks and converting the concurrent.futures.Future returned to an asyncio.Future through wrap_future(). 

> We need to start the discussion about this API on discourse.  Please give me a few days to organize that.

I agree that we should probably continue this discussion on discourse, as it probably goes beyond the scope of a single issue. No problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Sat Nov  2 20:38:13 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 03 Nov 2019 00:38:13 +0000
Subject: [issue38430] Memory leak in ThreadPoolExecutor + run_in_executor
In-Reply-To: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>
Message-ID: <1572741493.83.0.887472059692.issue38430@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38430>
_______________________________________

From report at bugs.python.org  Sat Nov  2 21:31:46 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Nov 2019 01:31:46 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572744706.8.0.87807365103.issue37903@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This feature may be fine or it may not.  I haven't been able to apply the PR and get a working Python 3.9 with Tkinter support, nor have I seen the requested additional screen shots.

Ideally, major changes in appearance or functionality should have significant user testing and feedback.  However, the tone of this thread is that the user feedback is irrelevant and the feature will happen and be backported regardless.

My team has used IDLE 8 hours a day for the last eight years, cumulatively training 25,000+ engineers using IDLE.  We have served as the beta tester and as the canary in the coal mine, reporting every usability issue so that IDLE can be improved.  We have tried to be a voice for users and it is sad to be roundly dismissed.

Other bug reports and feature requests that matter to us don't appear to be getting any traction:

* The squeezer on-by-default degraded our user experience
* Need auto-save shell sessions (we record full day sessions)
* Print speed is slow, giving the appearance of Python being slow
* Need Alt +/- hot keys for changing font size
* Recently lost the strip-trailing-whitespace menu option
* Need auto-strip-trailing-whitespace on save
* Tab completion has been unreliable for several years
* Need an option to run the install-certificates script (otherwise urllib HTTP requests fail with a fresh install of Python from python.org)
* Cntl-A on macOS jumps before the >>> prompt
* Font samples on the Settings tab are useless, distracting, and so large that it can make it impossible to mouse down to the Ok or Apply buttons when the display size is small (constrained by the projector).
* The tab size slider should be a scroll box and the font size scroll-box should be slider (users should almost never change the tab size but almost always want to change the font size).
* The default font size is too small.  For some users, when IDLE opens, the text looks like dust.
* The completions pop-up menu has never been helpful and users have a hard time getting it dismissed (so we usually have people change the completions pop-up time to 10,000 milliseconds)
* The mouse cursor targeting frequently gets missed by about seven lines (my understanding is that this is an upstream Tkinter problem, but it has been around for many years -- we have to close and reopen windows frequently to make this goa away).
* For the past two or three years, we periodically get an unintentional clipboard paste in to the shell window.  This happens during live demos, so the instructors have been accustomed to reflexively type Cntl-Z to undo the paste so as not to interrupt the demo).
* For mac users who have enabled tabs system-wide, opening a new window in IDLE triggers a system log-out (amazing that this is even possible).  My understanding is there isn't anything we can do about this, but it is a really bad out-of-the-box user experience seconds after a fresh install of Python.
* On rare occasion, I teach Python to kids.  A menu option to launch the turtle demo would be helpful.
* Being able to run pip from within IDLE would be a major win, especially for Windows users who are foreign to the command-line and who often do have Python on the PATH.
* The Search Dialog window doesn't stay on top of other windows.  It can have the focus, but be hidden underneath other windows.  The user experience that is there is no key that they can press to continue running their session.
* Sometimes the Search Dialog window becomes unresponsive and there is no way to clear it without turning IDLE off.
* When launching IDLE from the command-line, we see various exceptions and tracebacks for errors in the code (typically along the lines of None-type object doesn't have some attribute).
* Several of these issues have only came-up in the past few years.  IDLE used to be more stable than it is now.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 21:59:37 2019
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Sun, 03 Nov 2019 01:59:37 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572746377.3.0.910194308408.issue37903@roundup.psfhosted.org>


Stephen Paul Chappell <Noctis.Skytower at gmail.com> added the comment:

@rhettinger: The turtle demo is easily accessible through the menus via Help > Turtle Demo.

It is nice to see there are others interested in IDLE's improvement. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 22:30:39 2019
From: report at bugs.python.org (Elena Oat)
Date: Sun, 03 Nov 2019 02:30:39 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
Message-ID: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>


New submission from Elena Oat <oat.elena at gmail.com>:

When using patch.object with first argument as a string, e.g. 
??patch.object('SomeClass', 'somemethod')?? this raises ??AttributeError: Something does not have the attribute 'do_something'??. 
This should instead warn user that the correct type for the first argument is a class.

----------
components: Tests
messages: 355886
nosy: Elena.Oat
priority: normal
severity: normal
status: open
title: patch.object should raise another error when first argument is a str
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38669>
_______________________________________

From report at bugs.python.org  Sat Nov  2 22:58:59 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 03 Nov 2019 02:58:59 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1572749939.5.0.797391736255.issue38669@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +cjw296, lisroach, mariocj89, michael.foord, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38669>
_______________________________________

From report at bugs.python.org  Sat Nov  2 23:51:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Nov 2019 03:51:03 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572753063.67.0.821568786816.issue37903@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> The turtle demo is easily accessible through the 
> menus via Help > Turtle 

Thanks.  I didn't see that one land.  It is a nice improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sat Nov  2 23:59:56 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Nov 2019 03:59:56 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572753596.72.0.804555324563.issue37903@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Hmm, the turtle demo is barely usable on the mac:

* The "Choose Example from Menu" is a label and not clickable.
* The left pane is clickable but does nothing.
* When code is chosen from the menu the font-size is small.
* The "start" button label is invisible and the "stop" and "clear" buttons are barely visible with yellow-on-white.
* Once started, the "stop" button is invisible and the other two buttons shift to yellow-on-white.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sun Nov  3 01:09:07 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 03 Nov 2019 06:09:07 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1572761347.85.0.310123569405.issue37903@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@raymond Please stop spamming this issue with unrelated IDLE issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Sun Nov  3 03:13:12 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Nov 2019 08:13:12 +0000
Subject: [issue38670] can we accept os.PathLike objects within the subprocess
 args= list?
Message-ID: <1572768792.96.0.63320860714.issue38670@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

We started down this path in?https://bugs.python.org/issue31961?but had to revert part of that before 3.7 as the implementation was incomplete making it inconsistent across platforms.??https://github.com/python/cpython/pull/4329.

Specifically accepting PathLike objects within the args list hasn't been ruled out...

There is at least one question about behavior though, is str() called when running on posix systems or bytes() (bytes uses fsencode)?

Or does what gets called depend on the specific sub-type of the path vs the current platform?

Example scenario: if you're processing a PureWindowsPath on a posix system and passing that to a child process, sending that through os.fsencode would presumably be the wrong choice...

----------
messages: 355890
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: can we accept os.PathLike objects within the subprocess args= list?
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38670>
_______________________________________

From report at bugs.python.org  Sun Nov  3 03:42:16 2019
From: report at bugs.python.org (Big Stone)
Date: Sun, 03 Nov 2019 08:42:16 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1572770536.89.0.619185609032.issue37373@roundup.psfhosted.org>


Big Stone <stonebig34 at gmail.com> added the comment:

Is it be possible to backport this inside the standard ProactorEventLoop of Python-3.8.1 ? As things are currently broken, no kitten would be armed https://github.com/python-trio/trio/pull/1269

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Sun Nov  3 04:55:31 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 03 Nov 2019 09:55:31 +0000
Subject: [issue38671] pathlib.Path.resolve(strict=False) returns relative path
 on Windows if the entry does not existent
Message-ID: <1572774931.11.0.993470333259.issue38671@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

Originally from https://discuss.python.org/t/pathlib-absolute-vs-resolve/2573/4

>>> import pathlib
>>> pathlib.Path().resolve()
WindowsPath('C:/temp')
>>> list(pathlib.Path().iterdir())
[]
>>> pathlib.Path('foo').resolve()
WindowsPath('foo')
>>> pathlib.Path('bar').touch()
>>> pathlib.Path('bar').resolve()
WindowsPath('C:/temp/bar')

----------
messages: 355892
nosy: uranusjr
priority: normal
severity: normal
status: open
title: pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not existent
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38671>
_______________________________________

From report at bugs.python.org  Sun Nov  3 06:37:04 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 03 Nov 2019 11:37:04 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1572781024.63.0.245528310568.issue37373@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

IOCTL_AFD_POLL looks interesting.
I wonder if it is 100% reliable; we can miss some edge case easily.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Sun Nov  3 06:55:54 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 03 Nov 2019 11:55:54 +0000
Subject: [issue38388] Pickle protocol v 5 needs to be documented
In-Reply-To: <1570405873.92.0.178526679084.issue38388@roundup.psfhosted.org>
Message-ID: <1572782154.04.0.882884362388.issue38388@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16547
pull_request: https://github.com/python/cpython/pull/17035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38388>
_______________________________________

From report at bugs.python.org  Sun Nov  3 06:55:58 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 03 Nov 2019 11:55:58 +0000
Subject: [issue38388] Pickle protocol v 5 needs to be documented
In-Reply-To: <1570405873.92.0.178526679084.issue38388@roundup.psfhosted.org>
Message-ID: <1572782158.94.0.11070329434.issue38388@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset d0e0f5bf0c07ca025f54df21fd1df55ee430d9fc by Tal Einat (Dima Tisnek) in branch 'master':
bpo-38388: Document pickle protocol version 5 (GH-16639)
https://github.com/python/cpython/commit/d0e0f5bf0c07ca025f54df21fd1df55ee430d9fc


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38388>
_______________________________________

From report at bugs.python.org  Sun Nov  3 06:57:20 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 03 Nov 2019 11:57:20 +0000
Subject: [issue38388] Pickle protocol v 5 needs to be documented
In-Reply-To: <1570405873.92.0.178526679084.issue38388@roundup.psfhosted.org>
Message-ID: <1572782240.6.0.707668202005.issue38388@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for the report and the PR, Dima!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38388>
_______________________________________

From report at bugs.python.org  Sun Nov  3 07:03:22 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 03 Nov 2019 12:03:22 +0000
Subject: [issue38388] Pickle protocol v 5 needs to be documented
In-Reply-To: <1570405873.92.0.178526679084.issue38388@roundup.psfhosted.org>
Message-ID: <1572782602.38.0.422250688167.issue38388@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 87af51847b2fc911f2c1e82be58a7aa3bb5bd2ca by Miss Skeleton (bot) in branch '3.8':
bpo-38388: Document pickle protocol version 5 (GH-16639)
https://github.com/python/cpython/commit/87af51847b2fc911f2c1e82be58a7aa3bb5bd2ca


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38388>
_______________________________________

From report at bugs.python.org  Sun Nov  3 07:33:22 2019
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Szymaniak?=)
Date: Sun, 03 Nov 2019 12:33:22 +0000
Subject: [issue38672] Crash on mimetypes.init() if there is no access to one
 of knownfiles
Message-ID: <1572784402.07.0.839086408394.issue38672@roundup.psfhosted.org>


New submission from Micha? Szymaniak <sc0typl at gmail.com>:

When user lacks rights to read on of the mimetypes.knownfiles, mimetypes init() will throw PermissionError and library becomes unusable.

Reproduction steps:
# mkdir -p /etc/httpd/conf/
# touch /etc/httpd/conf/mime.types
# chmod a-r /etc/httpd/conf/mime.types
$ python
>>> import mimetypes
>>> mimetypes.init()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/mimetypes.py", line 355, in init
    db.read(file)
  File "/usr/lib/python3.7/mimetypes.py", line 204, in read
    with open(filename, encoding='utf-8') as fp:
PermissionError: [Errno 13] Permission denied: '/etc/httpd/conf/mime.types'

----------
components: Library (Lib)
messages: 355897
nosy: Micha? Szymaniak
priority: normal
severity: normal
status: open
title: Crash on mimetypes.init() if there is no access to one of knownfiles
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38672>
_______________________________________

From report at bugs.python.org  Sun Nov  3 07:42:00 2019
From: report at bugs.python.org (Pete Wicken)
Date: Sun, 03 Nov 2019 12:42:00 +0000
Subject: [issue38657] String format for hexadecimal notation breaks padding
 with alternative form
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572784920.53.0.346164053688.issue38657@roundup.psfhosted.org>


Change by Pete Wicken <petewicken at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Sun Nov  3 07:49:08 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 03 Nov 2019 12:49:08 +0000
Subject: [issue38657] Clarify numeric padding behavior in string formatting
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1572785348.15.0.735145857034.issue38657@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
title: String format for hexadecimal notation breaks padding with alternative form -> Clarify numeric padding behavior in string formatting

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Sun Nov  3 08:17:57 2019
From: report at bugs.python.org (Edward K Ream)
Date: Sun, 03 Nov 2019 13:17:57 +0000
Subject: [issue38663] Untokenize does not round-trip ws before bs-nl
In-Reply-To: <1572629495.93.0.152221972505.issue38663@roundup.psfhosted.org>
Message-ID: <1572787077.04.0.702070819324.issue38663@roundup.psfhosted.org>


Edward K Ream <edreamleo at gmail.com> added the comment:

The original bug report used a Leo-only function, g.toUnicode. To fix this, replace:

result = g.toUnicode(tokenize.untokenize(tokens))

by:

result_b = tokenize.untokenize(tokens)
result = result_b.decode('utf-8', 'strict')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38663>
_______________________________________

From report at bugs.python.org  Sun Nov  3 08:23:54 2019
From: report at bugs.python.org (Edward K Ream)
Date: Sun, 03 Nov 2019 13:23:54 +0000
Subject: [issue38663] Untokenize does not round-trip ws before bs-nl
In-Reply-To: <1572629495.93.0.152221972505.issue38663@roundup.psfhosted.org>
Message-ID: <1572787434.22.0.174159908282.issue38663@roundup.psfhosted.org>


Edward K Ream <edreamleo at gmail.com> added the comment:

This post
https://groups.google.com/d/msg/leo-editor/DpZ2cMS03WE/VPqtB9lTEAAJ
discusses a complete rewrite of tokenizer.untokenize.

To quote from the post:

I have "discovered" a spectacular replacement for Untokenizer.untokenize in python's tokenize library module. The wretched, buggy, and impossible-to-fix add_whitespace method is gone. The new code has no significant 'if' statements, and knows almost nothing about tokens!  This is the way untokenize is written in The Book.

The new code should put an end to a long series of issues against untokenize code in python's tokenize library module.  Some closed issues were blunders arising from dumbing-down the TestRoundtrip.check_roundtrip method in test_tokenize.py. 

Imo, the way is now clear for proper unit testing of python's Untokenize class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38663>
_______________________________________

From report at bugs.python.org  Sun Nov  3 08:27:10 2019
From: report at bugs.python.org (Edward K Ream)
Date: Sun, 03 Nov 2019 13:27:10 +0000
Subject: [issue38663] Untokenize does not round-trip ws before bs-nl
In-Reply-To: <1572629495.93.0.152221972505.issue38663@roundup.psfhosted.org>
Message-ID: <1572787630.22.0.450379256722.issue38663@roundup.psfhosted.org>


Edward K Ream <edreamleo at gmail.com> added the comment:

This post:
https://groups.google.com/d/msg/leo-editor/DpZ2cMS03WE/5X8IDzpgEAAJ

discusses unit testing. The summary states:

"I've done the heavy lifting on issue 38663. Python devs should handle the details of testing and packaging."

I'll leave it at that. In some ways this issue if very minor, and of almost no interest to anyone :-) Do with it as you will.  The ball is in python's court.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38663>
_______________________________________

From report at bugs.python.org  Sun Nov  3 08:46:27 2019
From: report at bugs.python.org (alclarks)
Date: Sun, 03 Nov 2019 13:46:27 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1572788787.12.0.908394428321.issue11354@roundup.psfhosted.org>


alclarks <alexpclarkson at gmail.com> added the comment:

Hi, I'm a new contributor looking for issues to work on. This looks like a nice enhancement, would it be a good idea for me to update the patch and raise a pull request?

----------
nosy: +alclarks

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Sun Nov  3 10:15:06 2019
From: report at bugs.python.org (hai shi)
Date: Sun, 03 Nov 2019 15:15:06 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1572794106.34.0.178415230538.issue11354@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I think the answer is 'yes'(It's over 8 years~).
And tons of argparse'work need to be finished;)

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Sun Nov  3 11:15:35 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 03 Nov 2019 16:15:35 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
Message-ID: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

This has always bothered me, and it shouldn't be necessary.

This session:

>>> #foo
... 
>>> 

should really have been

>>> #foo
>>>

It's confusing that the REPL prompt switches to "..." here, for no good reason. It should just treat the line as empty.

Ditto if you enter a space (there's an invisible space after the first prompt):

>>>  
... 
>>>

----------
components: Interpreter Core
messages: 355903
nosy: gvanrossum
priority: low
severity: normal
status: open
title: REPL shows continuation prompt (...) when comment or space entered
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Sun Nov  3 11:40:24 2019
From: report at bugs.python.org (paul j3)
Date: Sun, 03 Nov 2019 16:40:24 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1572799224.25.0.851286645234.issue11354@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

A couple of quick observations:

- this is one of the first patches that I worked on, so the details aren't fresh in my mind.  A glance at my latest patch show that this isn't a trivial change.  

- nargs changes affect the input handling, the parsing, help and usage formatting, and error formatting.  As a result, nargs are referenced in several places in the code.  That complicates maintenance and the addition of new features.  Help formatting is particularly brittle; just look at the number of issues that deal with 'metavar' to get a sense of that.

- At one point I tried to refactor the code to consolidate the nargs handling in a few functions.  I don't recall if I posted that as a patch.

- The first posts on this topic suggested a (n,m) notation; I proposed a regex like {n,m}.  There wasn't any further discussion.

- Note that the initial posts were in 2011 when Steven (the original author) was involved.  I posted in 2013.  There hasn't been any further action until now.  I don't recall much interest in this topic on Stackoverflow either.  So my sense is that this isn't a pressing issue.

- It's easy to test for this range after parsing, with '*' or '+' nargs.  So the main thing this patch adds is in the help/usage display.  It doesn't add significant functionality.

- cross links:

https://bugs.python.org/issue9849 - Argparse needs better error handling for nargs

https://bugs.python.org/issue16468 - argparse only supports iterable choices (recently closed)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Sun Nov  3 12:51:09 2019
From: report at bugs.python.org (Akshay Indalkar)
Date: Sun, 03 Nov 2019 17:51:09 +0000
Subject: [issue38674] RotatingFileHandler issue: logs in the file are printed
 in incorrect order.
Message-ID: <1572803469.31.0.999817574447.issue38674@roundup.psfhosted.org>


New submission from Akshay Indalkar <akshayindalkar1995 at gmail.com>:

I am using RotatingFileHandler library for saving the logs in the email.log file. Issue is logs are not saved in the correct order in the log file.

For Example: The latest logs are always needs to be saved in 
email.log file, then email.log.1, then email.log.2 and so on 

Correct Order:
email.log.3  ----> older than email.log.2
email.log.2  ----> older than email.log.1
email.log.1  ----> older than email.log
email.log    ----> Latest logs always saved here

But now the logs are randomly saved in the log file like
email.log.2  
email.log.1  
email.log  
email.log.3

or    
email.log.2  
email.log.3  
email.log.1  
email.log

Log are been saved randomly in incorrect order.

I have attached the evidence image also instructions to replicate.

To give you jist:
Using linux environment.
Basically I am just logging into the file every 5 seconds, and printing the files which are modified in the order.

To replicate ,just run 
python abc.py

----------
components: Library (Lib)
files: RotatingFIleHandler.zip
messages: 355905
nosy: akshay_indalkar, vinay.sajip
priority: normal
severity: normal
status: open
title: RotatingFileHandler issue: logs in the file are printed in incorrect order.
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file48691/RotatingFIleHandler.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38674>
_______________________________________

From report at bugs.python.org  Sun Nov  3 12:53:58 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 03 Nov 2019 17:53:58 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1572803638.52.0.727729437981.issue37373@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Yeah, that's the question. I've dug into the AFD_POLL stuff more now, and... There's a lot of edge cases to think about. It certainly *can* be done, because this is the primitive that 'select' and friends are built on, so obviously it can do anything they can do. But it also has some very sharp corners that 'select' knows how to work around, and we might not, since the folks writing 'select' could look at the internals and we can't.

The good news is that libuv has been shipping a version of this code for many years, and trio started shipping a version yesterday, so we can treat those as field experiments to gather data for asyncio. (I think that rust's mio library is also moving this way, but I'm not as familiar with the details. And wepoll is a good reference too, but I don't know how widely-deployed it is.)

The libuv implementation is very conservative, and falls back to calling 'select' in a thread if anything looks the slightest bit weird. The author of that code told me that he now thinks that's too conservative, esp. since some if the issues they were worrying about in the win xp era are no longer relevant. So Trio's version is more aggressive. I'm very curious to see how it goes.

I do think the incompatibilities between the different aio event loops are really a problem and the ultimate goal should be to support the full feature set everywhere. The question is how to make that viable.

Getting more experience with AFD_POLL will help make it possible for aio to implement its own version, if that's the direction we want to go.

Maybe it would also be helpful to try to find the right folks inside Microsoft to get more information about this? My understanding is that their official position on AFD_POLL is "don't do that", but you can't put the genie back into the bottle...

Alternatively: it seems like this is really highlighting the downsides of aio maintaining its own written-from-scratch event loops. Would it make sense to promote uvloop to the One True Event Loop? I get that there are significant complications to doing that, but there are also significant benefits: we'd get a more mature event loop core that we don't have to maintain alone, and it would fix tornado.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Sun Nov  3 14:41:02 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 03 Nov 2019 19:41:02 +0000
Subject: [issue38672] Crash on mimetypes.init() if there is no access to one
 of knownfiles
In-Reply-To: <1572784402.07.0.839086408394.issue38672@roundup.psfhosted.org>
Message-ID: <1572810062.67.0.151043694992.issue38672@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

The fix seems fairly obvious: replacing isfile check with try-catch statement for all OSErrors. Would you like to submit a pull request, Micha??

----------
nosy: +SilentGhost
stage:  -> test needed
type: crash -> behavior
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38672>
_______________________________________

From report at bugs.python.org  Sun Nov  3 14:42:26 2019
From: report at bugs.python.org (Elena Oat)
Date: Sun, 03 Nov 2019 19:42:26 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1572810146.5.0.719087590568.issue38669@roundup.psfhosted.org>


Change by Elena Oat <oat.elena at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38669>
_______________________________________

From report at bugs.python.org  Sun Nov  3 15:32:41 2019
From: report at bugs.python.org (David Goldsmith)
Date: Sun, 03 Nov 2019 20:32:41 +0000
Subject: [issue38675] Sug. for the scope example in TPT Cjapter 9
Message-ID: <1572813161.36.0.350406058195.issue38675@roundup.psfhosted.org>


New submission from David Goldsmith <eulergaussriemann at gmail.com>:

In The Python Tutorial, at the end of Section 9.2.1 "Scopes and Namespaces Example," there occurs the statement: "You can also see that there was no previous binding for spam before the global assignment."  Indeed, one can "virtually see" this by mentally analyzing what the code is doing--if one adequately understood the exposition given in Section 9.2--but, unless it is to be understood by an omission in the example code's output, which is a conclusion I myself am missing, that example code's output does not explicitly validate this claim...and yet, with the addition of just one line to the code, the claim can be shown explicitly: simply copy the line of code:

print("In global scope:", spam)

to precede, as well as follow (as it currently does) the line:

scope_test()

and the code output changes to:

>>> print("In global scope:", spam)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'spam' is not defined
>>> scope_test()
After local assignment: test spam
After nonlocal assignment: nonlocal spam
After global assignment: nonlocal spam
>>> print("In global scope:", spam)
In global scope: global spam  

This does _explicitly_ show that "there was no previous binding for spam before the global assignment": I respectfully suggest that this line be added to the code and that the code's quoted output be suitably updated as well.

----------
assignee: docs at python
components: Documentation
messages: 355908
nosy: David Goldsmith, docs at python
priority: normal
severity: normal
status: open
title: Sug. for the scope example in TPT Cjapter 9
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38675>
_______________________________________

From report at bugs.python.org  Sun Nov  3 15:33:18 2019
From: report at bugs.python.org (David Goldsmith)
Date: Sun, 03 Nov 2019 20:33:18 +0000
Subject: [issue38675] Sug. for the scope example in TPT Chapter 9
In-Reply-To: <1572813161.36.0.350406058195.issue38675@roundup.psfhosted.org>
Message-ID: <1572813198.57.0.753475398046.issue38675@roundup.psfhosted.org>


Change by David Goldsmith <eulergaussriemann at gmail.com>:


----------
title: Sug. for the scope example in TPT Cjapter 9 -> Sug. for the scope example in TPT Chapter 9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38675>
_______________________________________

From report at bugs.python.org  Sun Nov  3 16:09:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Nov 2019 21:09:23 +0000
Subject: [issue38382] statistics.harmonic_mean fails to raise error with
 negative input that follows a 0
In-Reply-To: <1570326378.93.0.0728676630318.issue38382@roundup.psfhosted.org>
Message-ID: <1572815363.41.0.394888151801.issue38382@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +16550
pull_request: https://github.com/python/cpython/pull/17037

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38382>
_______________________________________

From report at bugs.python.org  Sun Nov  3 16:50:05 2019
From: report at bugs.python.org (Isuru Fernando)
Date: Sun, 03 Nov 2019 21:50:05 +0000
Subject: [issue37916] distutils: allow overriding of the RANLIB command on
 macOS (darwin)
In-Reply-To: <1566473837.96.0.294748627211.issue37916@roundup.psfhosted.org>
Message-ID: <1572817805.41.0.862272123114.issue37916@roundup.psfhosted.org>


Isuru Fernando <isuruf at gmail.com> added the comment:

This is an issue even without cross-compilations as there is an environment variable for the archiver and therefore the archiver and ranlib can be from 2 different toolchains and leads to error. Ran into this issue in python 3.8 on macOS with an lto build

----------
nosy: +isuruf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37916>
_______________________________________

From report at bugs.python.org  Sun Nov  3 17:08:12 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 03 Nov 2019 22:08:12 +0000
Subject: [issue38663] Untokenize does not round-trip ws before bs-nl
In-Reply-To: <1572629495.93.0.152221972505.issue38663@roundup.psfhosted.org>
Message-ID: <1572818892.68.0.414265018291.issue38663@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since these posts were more or less copied to pydev list, I am copying my response on the list here.
---

> **tl;dr:** Various posts, linked below, discuss a much better replacement for untokenize.
If that were true, I would be interested.  But as explained below, I don't believe it.  Even if I did, https://bugs.python.org/issue38663 gives no evidence that you have signed the PSF contributor agreement.  In any case, it has no PR.  We only use code that is actually contributed on the issue or in a PR under that agreement.

To continue, the first two lines of tokenize.untokenize() are
    ut = Untokenizer()
    out = ut.untokenize(iterable)

Your leoBeautify.Untokenize class appears to be completely unsuited as a replacement for tokenize.Untokenizer as the API for the class and method are incompatible with the above.

1. untokenize.Untokenizer takes no argument. leoBeautify.Untokenize() requires a 'contents' argument, a (unicode) string, that is otherwise undocumented.  At first glance, it appears that 'contents' needs to be something like the desired output.  (I could read the code where you call Untokenizer to improve my guess, but not now.)  Since our exising tests do not pass 'contents', they should all fail.

2. untokenize.Untokenizer.untokenize(iterable) require an iterable that returns "sequences with at least two elements, the token type and the token string."
https://docs.python.org/3/library/tokenize.html#tokenize.untokenize
One can generate python code from a sequence of pairs with a guarantee that the resulting code will be tokenized by the python.exe parser into the same sequence.

The doc continues "Any additional sequence elements are ignored."
The intent is that a tool can tokenize a file, modify the file (and thereby possibly invalidate the begin, end, and line elements of the original token stream) and generate a modified file.

[Note that the end index (4th element), when present, is not ignored but is used to improve white space insertion.  I believe that this should be documented.  What if the end index is no longer valid?  Should be also use the start index?]

leoBeautify.Untokenize.untokenize() requires an iterable of 5-tuples.  It makes uses of both the start and end elements, as well as the mysterious required 'contents' string.

> I have "discovered" a spectacular replacement for Untokenizer.untokenize in python's tokenize library module:
To pass 'code == untokenize(tokenize(code))' (ignoring api details), there is an even more spectacular replacement: rebuild the code from the 'line' elements.  But while the above is an essential test, it is a toy example with respect to applications.  The challenge is to create a correct and valid file from less information, possibly with only token type and string.  (The latter is 'compatibility mode'.)
> In particular, it is, imo, time to remove compatibility mode.
And break all usage that requires it?  Before doing much more with tokenize, I would want to understand more how it is actually used.

> Imo, python devs are biased in favor of parse trees in programs involving text manipulations.  [snip]
So why have 46 of us contributed to this one module?  This sort of polemic is a net negative here. We a multiple individuals with differing opinions.

----------
nosy: +terry.reedy
stage:  -> test needed
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38663>
_______________________________________

From report at bugs.python.org  Sun Nov  3 17:42:12 2019
From: report at bugs.python.org (BRT)
Date: Sun, 03 Nov 2019 22:42:12 +0000
Subject: [issue38676] Unable to install Python 3.8 on Windows 10
Message-ID: <1572820932.82.0.0473031743457.issue38676@roundup.psfhosted.org>


New submission from BRT <mb_17 at hotmail.it>:

Some information:

I had the same Python version installed before, I uninstalled it (along with its launcher) using ccleaner (to install it in another path)
I tried to install Python in a new folder but got an error because another installation was going on (it wasn't another Python installation, but another program)
Now, when I try to install Python I get a message "No python 3.8 version was found" --> fatal error 0x80070643
I used the software "everything" to remove python stuff from the previous location, ccleaner to clean registry (+ msiexec /unreg and msiexec /regserver),  deleted pip folder from Appdata/Local and removed python from PATH

Log file: https://pastebin.com/wQizN9Nc

----------
components: Windows
messages: 355911
nosy: BRT, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to install Python 3.8 on Windows 10
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38676>
_______________________________________

From report at bugs.python.org  Sun Nov  3 17:59:34 2019
From: report at bugs.python.org (BRT)
Date: Sun, 03 Nov 2019 22:59:34 +0000
Subject: [issue38676] Unable to install Python 3.8 on Windows 10
In-Reply-To: <1572820932.82.0.0473031743457.issue38676@roundup.psfhosted.org>
Message-ID: <1572821974.18.0.433024237911.issue38676@roundup.psfhosted.org>


Change by BRT <mb_17 at hotmail.it>:


Added file: https://bugs.python.org/file48692/Python 3.8.0 (32-bit)_20191103234319.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38676>
_______________________________________

From report at bugs.python.org  Sun Nov  3 18:00:17 2019
From: report at bugs.python.org (BRT)
Date: Sun, 03 Nov 2019 23:00:17 +0000
Subject: [issue38676] Unable to install Python 3.8 on Windows 10
In-Reply-To: <1572820932.82.0.0473031743457.issue38676@roundup.psfhosted.org>
Message-ID: <1572822017.15.0.373092964896.issue38676@roundup.psfhosted.org>


Change by BRT <mb_17 at hotmail.it>:


Removed file: https://bugs.python.org/file48692/Python 3.8.0 (32-bit)_20191103234319.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38676>
_______________________________________

From report at bugs.python.org  Sun Nov  3 18:01:48 2019
From: report at bugs.python.org (BRT)
Date: Sun, 03 Nov 2019 23:01:48 +0000
Subject: [issue38676] Unable to install Python 3.8 on Windows 10
In-Reply-To: <1572820932.82.0.0473031743457.issue38676@roundup.psfhosted.org>
Message-ID: <1572822108.92.0.599398421658.issue38676@roundup.psfhosted.org>


BRT <mb_17 at hotmail.it> added the comment:

Attaching a rar with the Justforme log files

----------
Added file: https://bugs.python.org/file48693/Temp.rar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38676>
_______________________________________

From report at bugs.python.org  Sun Nov  3 18:21:28 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 03 Nov 2019 23:21:28 +0000
Subject: [issue38430] Memory leak in ThreadPoolExecutor + run_in_executor
In-Reply-To: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>
Message-ID: <1572823288.29.0.289889769194.issue38430@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38430>
_______________________________________

From report at bugs.python.org  Sun Nov  3 18:27:02 2019
From: report at bugs.python.org (Marco Paolini)
Date: Sun, 03 Nov 2019 23:27:02 +0000
Subject: [issue38677] Arraymodule initialization error handling improvements
Message-ID: <1572823622.93.0.752200478354.issue38677@roundup.psfhosted.org>


New submission from Marco Paolini <markopaolini at gmail.com>:

Module two-phase initialization does not report errors correctly to the import machinery

----------
components: Extension Modules
messages: 355913
nosy: mpaolini
priority: normal
severity: normal
status: open
title: Arraymodule initialization error handling improvements
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38677>
_______________________________________

From report at bugs.python.org  Sun Nov  3 18:31:18 2019
From: report at bugs.python.org (David Goldsmith)
Date: Sun, 03 Nov 2019 23:31:18 +0000
Subject: [issue38678] TypeError raised trying to run TPT 10.3 Example 2 in
 Python 3.4.3
Message-ID: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>


New submission from David Goldsmith <eulergaussriemann at gmail.com>:

When I run the second example code of Section 10.3 of The Python Tutorial:

import argparse
from getpass import getuser
parser = argparse.ArgumentParser(description='An argparse example.')
parser.add_argument('name', nargs='?', default=getuser(), help='The name of someone to greet.')
parser.add_argument('--verbose', '-v', action='count')
args = parser.parse_args()
greeting = ["Hi", "Hello", "Greetings! its very nice to meet you"][args.verbose % 3]
print(f'{greeting}, {args.name}')
if not args.verbose:
    print('Try running this again with multiple "-v" flags!')

the greeting assignment line raises:

>>> greeting = ["Hi", "Hello", "Greetings! its very nice to meet you"][args.verbose % 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for %: 'NoneType' and 'int'
 
Is this an artifact of me being so far behind in my Python version:

Davids-MacBook-Air:~ DLG$ python3
Python 3.4.3 |Anaconda 2.4.0 (x86_64)| (default, Oct 20 2015, 14:27:51) 
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin

Or is it a bug in the example code in the doc?

----------
assignee: docs at python
components: Documentation
messages: 355914
nosy: David Goldsmith, docs at python
priority: normal
severity: normal
status: open
title: TypeError raised trying to run TPT 10.3 Example 2 in Python 3.4.3
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Sun Nov  3 18:32:47 2019
From: report at bugs.python.org (Marco Paolini)
Date: Sun, 03 Nov 2019 23:32:47 +0000
Subject: [issue38677] Arraymodule initialization error handling improvements
In-Reply-To: <1572823622.93.0.752200478354.issue38677@roundup.psfhosted.org>
Message-ID: <1572823967.13.0.359406489951.issue38677@roundup.psfhosted.org>


Change by Marco Paolini <markopaolini at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38677>
_______________________________________

From report at bugs.python.org  Sun Nov  3 19:29:20 2019
From: report at bugs.python.org (Warren Weckesser)
Date: Mon, 04 Nov 2019 00:29:20 +0000
Subject: [issue38382] statistics.harmonic_mean fails to raise error with
 negative input that follows a 0
In-Reply-To: <1570616840.88.0.350995647145.issue38382@roundup.psfhosted.org>
Message-ID: <CAGzF1uc-+f9LYoiTtZf9wSSvVDoZ+qvz5M+WDMak0kqugxs9VQ@mail.gmail.com>


Warren Weckesser <warren.weckesser at gmail.com> added the comment:

On 10/9/19, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
>> In [20]: harmonic_mean([math.nan, 0])
>>
>> Out[20]: 0
>
> That one seems excusable, for the same sort of reasons that IEEE 754
> specifies that hypot(nan, inf) is inf rather than nan. Similarly, sumSquare
> and sumAbs from IEEE 754-2008 specify that infinities take precedence over
> NaNs, on the basis that the result doesn't change if the nan is replaced
> with any non-nan value.
>

A belated "thanks", Mark.  I wasn't aware of that, but it makes sense.

Warren

> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38382>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38382>
_______________________________________

From report at bugs.python.org  Sun Nov  3 20:19:50 2019
From: report at bugs.python.org (Marvin)
Date: Mon, 04 Nov 2019 01:19:50 +0000
Subject: [issue38679] Scipy and Scikit learn library installation issues
Message-ID: <1572830390.76.0.194683013325.issue38679@roundup.psfhosted.org>


New submission from Marvin <marvinmckinneyii at rocketmail.com>:

I recently uninstalled a previous version of Python 3.7.3, and installed Python 3.8.0. Prior to the update, I had no issues installing scipy, and scikit learn. However, I am unable to do this and received the error below. 


C:\Users\Marvin McKiney II>python -m pip install numpy
Requirement already satisfied: numpy in c:\users\marvin mckiney ii\appdata\local\programs\python\python38-32\lib\site-packages (1.17.3)

C:\Users\Marvin McKiney II>python -m pip install scipy
Collecting scipy
  Using cached https://files.pythonhosted.org/packages/ee/5b/5afcd1c46f97b3c2ac3489dbc95d6ca28eacf8e3634e51f495da68d97f0f/scipy-1.3.1.tar.gz
  Installing build dependencies ... error
  ERROR: Command errored out with exit status 1:
   command: 'C:\Users\Marvin McKiney II\AppData\Local\Programs\Python\Python38-32\python.exe' 'C:\Users\Marvin McKiney II\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pip' install --ignore-installed --no-user --prefix 'C:\Users\Marvin McKiney II\AppData\Local\Temp\pip-build-env-wsel_5uo\overlay' --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- wheel setuptools 'Cython>=0.29.2' 'numpy==1.13.3; python_version=='"'"'3.5'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.13.3; python_version=='"'"'3.6'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.14.5; python_version>='"'"'3.7'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.16.0; python_version=='"'"'3.5'"'"' and platform_system=='"'"'AIX'"'"'' 'numpy==1.16.0; python_version=='"'"'3.6'"'"' and platform_system=='"'"'AIX'"'"'' 'numpy==1.16.0; python_version>='"'"'3.7'"'"' and platform_system=='"'"'AIX'"'"''
       cwd: None
  Complete output (21 lines):
  Ignoring numpy: markers 'python_version == "3.5" and platform_system != "AIX"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.6" and platform_system != "AIX"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.5" and platform_system == "AIX"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.6" and platform_system == "AIX"' don't match your environment
  Ignoring numpy: markers 'python_version >= "3.7" and platform_system == "AIX"' don't match your environment
  Collecting wheel
    Using cached https://files.pythonhosted.org/packages/00/83/b4a77d044e78ad1a45610eb88f745be2fd2c6d658f9798a15e384b7d57c9/wheel-0.33.6-py2.py3-none-any.whl
  Collecting setuptools
    Downloading https://files.pythonhosted.org/packages/d9/de/554b6310ac87c5b921bc45634b07b11394fe63bc4cb5176f5240addf18ab/setuptools-41.6.0-py2.py3-none-any.whl (582kB)
  Collecting Cython>=0.29.2
    Downloading https://files.pythonhosted.org/packages/22/03/510503cfbf20f62810a9548c9be13ab86181f00cca9a3a56717c4595d952/Cython-0.29.14-cp38-cp38-win32.whl (1.6MB)
  Collecting numpy==1.14.5
    Using cached https://files.pythonhosted.org/packages/d5/6e/f00492653d0fdf6497a181a1c1d46bbea5a2383e7faf4c8ca6d6f3d2581d/numpy-1.14.5.zip
  Installing collected packages: wheel, setuptools, Cython, numpy
      Running setup.py install for numpy: started
      Running setup.py install for numpy: still running...
      Running setup.py install for numpy: still running...
      Running setup.py install for numpy: still running...
      Running setup.py install for numpy: finished with status 'done'
  ERROR: Could not install packages due to an EnvironmentError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '"C:'

  ----------------------------------------
ERROR: Command errored out with exit status 1: 'C:\Users\Marvin McKiney II\AppData\Local\Programs\Python\Python38-32\python.exe' 'C:\Users\Marvin McKiney II\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pip' install --ignore-installed --no-user --prefix 'C:\Users\Marvin McKiney II\AppData\Local\Temp\pip-build-env-wsel_5uo\overlay' --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- wheel setuptools 'Cython>=0.29.2' 'numpy==1.13.3; python_version=='"'"'3.5'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.13.3; python_version=='"'"'3.6'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.14.5; python_version>='"'"'3.7'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.16.0; python_version=='"'"'3.5'"'"' and platform_system=='"'"'AIX'"'"'' 'numpy==1.16.0; python_version=='"'"'3.6'"'"' and platform_system=='"'"'AIX'"'"'' 'numpy==1.16.0; python_version>='"'"'3.7'"'"' and platform_system=='"'"'AIX'"'"'' Check the logs for full command output.

----------
components: Library (Lib)
messages: 355916
nosy: marvinmckinneyii
priority: normal
severity: normal
status: open
title: Scipy and Scikit learn library installation issues
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38679>
_______________________________________

From report at bugs.python.org  Sun Nov  3 20:27:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 01:27:22 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572830842.86.0.0377709163008.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> -1 about the PR solution to suppress ProcessLookupError in case the process is gone.

Did someone propose a pull request to fix this issue by ignoring ProcessLookupError?

> In psutil I solved the ?pid reused problem? by using process creation time to identify a process uniquely (on start). 

Well, that requires to write platform specific code.

I would prefer to only use platform specific code when the platform provides something like pidfd: I understand that Linux, FreeBSD, OpenBSD, NetBSD, and Illumos are concerned. I mean reuse an exisiting solution, rather than writing our own "workaround" (solution?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Sun Nov  3 20:28:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 01:28:15 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572830895.4.0.860463716871.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I would prefer to only use platform specific code when the platform provides something like pidfd: I understand that Linux, FreeBSD, OpenBSD, NetBSD, and Illumos are concerned. I mean reuse an exisiting solution, rather than writing our own "workaround" (solution?).

By the way, I suggest to stick to the initial problem in this issue. If someone is intersted to explore the pidfd idea, I recommend to open a different issue ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Sun Nov  3 20:33:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 01:33:18 +0000
Subject: [issue38667] PYTHONCOERCECLOCALE=0 ignored
In-Reply-To: <1572700464.48.0.125378742934.issue38667@roundup.psfhosted.org>
Message-ID: <1572831198.88.0.00174152530777.issue38667@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

You should not use sys.getfilesystemencoding() nor locale.getpreferredencofing() to check if the C locale has been coerced, but read the LC_CTYPE locale instead:

# C locale coerced
$ LC_CTYPE=C python3 -c "import locale; print(locale.setlocale(locale.LC_CTYPE, ''))"
C.UTF-8

# C locale not coerced: remains "C"
$ LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -c "import locale; print(locale.setlocale(locale.LC_CTYPE, ''))"
C

--

$ LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -c "import sys; print(sys.getfilesystemencoding())"   
utf-8

In this example, the UTF-8 encoding is used because of the UTF-8 Mode:

$ LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -X utf8=1 -c "import sys; print(sys.getfilesystemencoding(), sys.flags.utf8_mode)"
utf-8 1

$ LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -X utf8=0 -c "import sys; print(sys.getfilesystemencoding(), sys.flags.utf8_mode)"
ascii 0

The relationship between the PEP 538 and the PEP 540 is non obvious:
https://www.python.org/dev/peps/pep-0540/#relationship-with-the-locale-coercion-pep-538

I guess that you would like: PYTHONUTF8=0 env var or -X utf8=0 command line option.

--

I don't think that this issue is a bug, and so I suggest to close it as "not a bug".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38667>
_______________________________________

From report at bugs.python.org  Sun Nov  3 21:02:51 2019
From: report at bugs.python.org (Dhongs Elmido)
Date: Mon, 04 Nov 2019 02:02:51 +0000
Subject: [issue38679] Scipy and Scikit learn library installation issues
In-Reply-To: <1572830390.76.0.194683013325.issue38679@roundup.psfhosted.org>
Message-ID: <1572832971.58.0.340234596185.issue38679@roundup.psfhosted.org>


Change by Dhongs Elmido <corralesmarlon37 at gmail.com>:


----------
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38679>
_______________________________________

From report at bugs.python.org  Sun Nov  3 21:21:45 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 04 Nov 2019 02:21:45 +0000
Subject: [issue38679] Scipy and Scikit learn library installation issues
In-Reply-To: <1572830390.76.0.194683013325.issue38679@roundup.psfhosted.org>
Message-ID: <1572834105.14.0.410639081685.issue38679@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This bug tracker is for CPython related issues. Please file this issue in the respective project issue tracker. I propose closing it as third party.

----------
nosy: +xtreak
type: security -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38679>
_______________________________________

From report at bugs.python.org  Sun Nov  3 23:48:28 2019
From: report at bugs.python.org (123 wlpha)
Date: Mon, 04 Nov 2019 04:48:28 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
Message-ID: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>


New submission from 123 wlpha <hackjajk at gmail.com>:

PyGILState_Release does not really release gil, causing the next PyGILState_Ensure deadlock, now you need to call if (PyGILState_Check () > 0) {PyEval_SaveThread ();}


```
auto gil = PyGILState_Ensure();

// call c api

PyGILState_Release (gil);
if (PyGILState_Check () ? 0) {
   PyEval_SaveThread ();
}
    
```

----------
components: Interpreter Core
messages: 355921
nosy: 123 wlpha
priority: normal
severity: normal
status: open
title: PyGILState_Release does not release gil correctly, resulting in deadlock
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Sun Nov  3 23:55:37 2019
From: report at bugs.python.org (123 wlpha)
Date: Mon, 04 Nov 2019 04:55:37 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
In-Reply-To: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>
Message-ID: <1572843337.75.0.981044600034.issue38680@roundup.psfhosted.org>


123 wlpha <hackjajk at gmail.com> added the comment:

Usually in the python extension, only the python function needs to be written between Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW THREADS, but the c callback function needs PyGILState_Ensure and PyGILState_Release, but PyGILState_Releas cannot release gil correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Mon Nov  4 00:31:14 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 04 Nov 2019 05:31:14 +0000
Subject: [issue38601] Couldn't able to install multiple python minor version
 in windows due to EXE script
In-Reply-To: <1572178164.18.0.338058343246.issue38601@roundup.psfhosted.org>
Message-ID: <1572845474.1.0.669926348781.issue38601@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

When you say minor version, I assume you mean 3.x vs 3.y versions.

These already install separately and should not upgrade each other. If you think they are, could you provide some more information about what you are seeing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38601>
_______________________________________

From report at bugs.python.org  Mon Nov  4 00:40:53 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Nov 2019 05:40:53 +0000
Subject: [issue37759] Polish whatsnew for 3.8
In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org>
Message-ID: <1572846053.96.0.476265704983.issue37759@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +16553
pull_request: https://github.com/python/cpython/pull/17040

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37759>
_______________________________________

From report at bugs.python.org  Mon Nov  4 00:47:05 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Nov 2019 05:47:05 +0000
Subject: [issue37759] Polish whatsnew for 3.8
In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org>
Message-ID: <1572846425.39.0.155351547285.issue37759@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 1cdadf414b9934bba9294efa1f4b8d97eef08434 by Raymond Hettinger in branch 'master':
bpo-37759:  Show output from var_access_benchmark (GH-17040)
https://github.com/python/cpython/commit/1cdadf414b9934bba9294efa1f4b8d97eef08434


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37759>
_______________________________________

From report at bugs.python.org  Mon Nov  4 00:47:19 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Nov 2019 05:47:19 +0000
Subject: [issue37759] Polish whatsnew for 3.8
In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org>
Message-ID: <1572846439.15.0.069229808329.issue37759@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16554
pull_request: https://github.com/python/cpython/pull/17041

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37759>
_______________________________________

From report at bugs.python.org  Mon Nov  4 00:55:29 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Nov 2019 05:55:29 +0000
Subject: [issue37759] Polish whatsnew for 3.8
In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org>
Message-ID: <1572846929.36.0.70816636922.issue37759@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset f90e0d2371bc2bcab7bf5307cfd73571eb06b375 by Raymond Hettinger (Miss Skeleton (bot)) in branch '3.8':
bpo-37759:  Show output from var_access_benchmark (GH-17040) (GH-17041)
https://github.com/python/cpython/commit/f90e0d2371bc2bcab7bf5307cfd73571eb06b375


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37759>
_______________________________________

From report at bugs.python.org  Mon Nov  4 01:39:08 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 04 Nov 2019 06:39:08 +0000
Subject: [issue38671] pathlib.Path.resolve(strict=False) returns relative path
 on Windows if the entry does not exist
In-Reply-To: <1572774931.11.0.993470333259.issue38671@roundup.psfhosted.org>
Message-ID: <1572849548.51.0.098472164137.issue38671@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
title: pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not existent -> pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38671>
_______________________________________

From report at bugs.python.org  Mon Nov  4 02:12:47 2019
From: report at bugs.python.org (Samuel Tatasurya)
Date: Mon, 04 Nov 2019 07:12:47 +0000
Subject: [issue38681] 2to3 Conversion Result using BlankLine() can be
 Syntactically Incorrect
Message-ID: <1572851567.83.0.781319798867.issue38681@roundup.psfhosted.org>


New submission from Samuel Tatasurya <tatasurya.samuel at gmail.com>:

Transformation performed by certain fixers (e.g. future, itertools_imports) that causes a statement to be replaced by a blank line will generate a Python file that contains syntax error.

For example, assuming a Python file (foo.py) containing line below:

try:
    from itertools import imap
except ImportError:
    pass

If we run "itertools_imports" fixer against it:
2to3 -f itertools_imports foo.py

will result in the following:

try:

except ImportError:
    pass

which is syntactically incorrect.

Suggestion:
Instead of always replacing such case with BlankLine(), a check should be performed beforehand if the statement to be replaced has any siblings. If no sibling is found, then replace that statement with a "pass" statement instead.

By doing this, Python source files generated by 2to3 are more readily runnable right after the transformation.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 355926
nosy: Samuel Tatasurya
priority: normal
severity: normal
status: open
title: 2to3 Conversion Result using BlankLine() can be Syntactically Incorrect
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38681>
_______________________________________

From report at bugs.python.org  Mon Nov  4 02:18:40 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Mon, 04 Nov 2019 07:18:40 +0000
Subject: [issue38667] PYTHONCOERCECLOCALE=0 ignored
In-Reply-To: <1572700464.48.0.125378742934.issue38667@roundup.psfhosted.org>
Message-ID: <1572851920.42.0.230497010665.issue38667@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

Thanks! I didn't quite see the relation between PEP 538 and PEP 540 after only reading the former.

Anyone else finding this: See "Relationship with the locale coercion" in https://www.python.org/dev/peps/pep-0540/ for the details.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38667>
_______________________________________

From report at bugs.python.org  Mon Nov  4 02:55:40 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 04 Nov 2019 07:55:40 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572854140.76.0.610062615599.issue38630@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Did someone propose a pull request to fix this issue by ignoring ProcessLookupError?

I misread your PR, sorry. I thought that was the effect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Mon Nov  4 02:59:31 2019
From: report at bugs.python.org (BRT)
Date: Mon, 04 Nov 2019 07:59:31 +0000
Subject: [issue38676] Unable to install Python 3.8 on Windows 10
In-Reply-To: <1572820932.82.0.0473031743457.issue38676@roundup.psfhosted.org>
Message-ID: <1572854371.51.0.359915656571.issue38676@roundup.psfhosted.org>


BRT <mb_17 at hotmail.it> added the comment:

I find a solution: during the installation process I unchecked the "associate with python files" and it worked!

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38676>
_______________________________________

From report at bugs.python.org  Mon Nov  4 02:59:49 2019
From: report at bugs.python.org (BRT)
Date: Mon, 04 Nov 2019 07:59:49 +0000
Subject: [issue38676] Unable to install Python 3.8 on Windows 10
In-Reply-To: <1572820932.82.0.0473031743457.issue38676@roundup.psfhosted.org>
Message-ID: <1572854389.91.0.533115458559.issue38676@roundup.psfhosted.org>


Change by BRT <mb_17 at hotmail.it>:


----------
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38676>
_______________________________________

From report at bugs.python.org  Mon Nov  4 03:18:53 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 04 Nov 2019 08:18:53 +0000
Subject: [issue38674] RotatingFileHandler issue: logs in the file are printed
 in incorrect order.
In-Reply-To: <1572803469.31.0.999817574447.issue38674@roundup.psfhosted.org>
Message-ID: <1572855533.92.0.597158310818.issue38674@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

You're doing it wrong. I inserted a print statement just before the RotatingFileHandler for email.log is created. Here's what was printed:

Creating RFH email.log
Creating RFH email.log
Creating RFH email.log
Creating RFH email.log
Creating RFH email.log

In the above, RFH is short for RotatingFileHandler. You're creating five handlers for the same file. Because you are doing this, things won't work as expected - you're not supposed to have multiple handlers pointing to the same file. They will trample over each other and the resulting behaviour will be ill-defined.

In future, I suggest you post your problem on Stack Overflow, python-list or some similar forum to establish whether there is really a Python bug or whether it's a problem in your own code. Posting a new issue when there isn't actually one wastes volunteer time that could be better spent on actual bugs - time spent on triaging, investigating and updating the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38674>
_______________________________________

From report at bugs.python.org  Mon Nov  4 03:27:47 2019
From: report at bugs.python.org (serge-sans-paille)
Date: Mon, 04 Nov 2019 08:27:47 +0000
Subject: [issue38634] Symbol resolution conflict when embeding python in an
 application using libedit
In-Reply-To: <1572362225.21.0.644355885677.issue38634@roundup.psfhosted.org>
Message-ID: <1572856067.92.0.499964067877.issue38634@roundup.psfhosted.org>


serge-sans-paille <serge.guelton at telecom-bretagne.eu> added the comment:

@ned I(d rather see this as an evolution of Issue13631, as this solves a problem when libreadline and libedit are both loaded in the same executable. As such, using libedit instead of readline wouldn't solve the issue: what if the program Python is embeded in is linked to readline?

I find python approach relatively elegant: detect the linked library at runtime and use the ad-hoc implementation based on this.

An other option would be to dlopen readline using the RTLD_LOCAL flag, so that we get a better, non intrusive symbol resolution.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38634>
_______________________________________

From report at bugs.python.org  Mon Nov  4 04:36:12 2019
From: report at bugs.python.org (Mithil)
Date: Mon, 04 Nov 2019 09:36:12 +0000
Subject: [issue38682] struct timeval is not declared
Message-ID: <1572860172.48.0.713229733746.issue38682@roundup.psfhosted.org>


New submission from Mithil <mithil467 at gmail.com>:

pytime.h compilation gives warnings - 

pytime.h:123:59: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
 PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);
                                                           ^~~~~~~
pytime.h:130:12: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
     struct timeval *tv,
            ^~~~~~~
pytime.h:135:12: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
     struct timeval *tv,

=====

I think the reason for this is that the struct timeval isn't declared anywhere before the declaration of this function. For me on windows, the structure is defined inside of winsock.h and including it before the other python header files fixes the problem.

----------
components: Windows
messages: 355932
nosy: Mithil, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: struct timeval is not declared
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38682>
_______________________________________

From report at bugs.python.org  Mon Nov  4 05:03:10 2019
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 04 Nov 2019 10:03:10 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1572861790.81.0.912775204512.issue38500@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

I'm strongly opposed to this change.

PEP 523 does not specify what the semantics of changing the interpreter frame evaluator actually is:
Is the VM obliged to call the new interpreter?
What happens if the custom evaluator leaves the VM in a inconsistent state?
Does the VM have to roll back any speculative optimisations it has made? What happens if it the evaluator is changed multiple times by different modules?
What if the evaluator is changed when a coroutine or generator is suspended, or in another thread?
I could go on...

IMO this punches a big hole in the Python execution model, but provides no benefit.

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Mon Nov  4 05:03:49 2019
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 04 Nov 2019 10:03:49 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1572861829.91.0.349526243828.issue38500@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Fabio,

OOI what are you trying achieve by changing the frame evaluator?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Mon Nov  4 05:56:00 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 04 Nov 2019 10:56:00 +0000
Subject: [issue38438] argparse "usage" overly-complex with nargs="*"
In-Reply-To: <1570739079.02.0.395133592841.issue38438@roundup.psfhosted.org>
Message-ID: <1572864960.35.0.627926442186.issue38438@roundup.psfhosted.org>


Change by Callum Ward <wards.callum at gmail.com>:


----------
nosy: +callumquick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38438>
_______________________________________

From report at bugs.python.org  Mon Nov  4 06:02:56 2019
From: report at bugs.python.org (=?utf-8?q?Benedek_R=C3=A1cz?=)
Date: Mon, 04 Nov 2019 11:02:56 +0000
Subject: [issue38683] Installation failed - no privileges to access directory
Message-ID: <1572865376.09.0.193791469521.issue38683@roundup.psfhosted.org>


New submission from Benedek R?cz <betontalpfa at gmail.com>:

Python installation failed when I try to install to system dir on Windows 10. (C:\Program Files\Python37)

**Reproduce**

I have downloaded the installer, and I have changed the install location to `C:\Program Files\Python37`. Then I get the attached error.

**Expected behavior**

Not to crash, ask for administrator privileges. If its needed.

**I use:**
 - Win 10 Pro
 - Version 10.0.18362 Build 18362
 - Python 3.7.5 (https://www.python.org/ftp/python/3.7.5/python-3.7.5-amd64.exe)

----------
components: Installation
files: pythonInstallFail.PNG
messages: 355935
nosy: Benedek R?cz
priority: normal
severity: normal
status: open
title: Installation failed - no privileges to access directory
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48694/pythonInstallFail.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38683>
_______________________________________

From report at bugs.python.org  Mon Nov  4 06:07:34 2019
From: report at bugs.python.org (Fabio Zadrozny)
Date: Mon, 04 Nov 2019 11:07:34 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1572865654.27.0.623557950815.issue38500@roundup.psfhosted.org>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

@Mark Shannon what I do is change the code object of the frame about to be evaluated to add a programmatic breakpoint, to avoid the need to have the trace function set at contexts that would need to be traced (after changing the frame.f_code it goes on to call the regular _PyEval_EvalFrameDefault), so, the user-code runs at full speed on all contexts (there's still added overhead on a function call to decide if the code object needs to be changed, but that'd happen on the regular tracing code too).

Note that this does not change the semantics of anything as it calls the regular _PyEval_EvalFrameDefault, so, the worries you're listing shouldn't be a concern in this particular use-case.

Also note that until Python 3.7 this was easy to change, and that's still possible in Python 3.8 (the only thing is that now it's less straightforward).

Note that my use is much simpler that the original intent of the frame evaluator -- my use case could be solved by having a callback to change the code object before the frame execution -- but as far as I know, right now, the way to do that is through the frame evaluation API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Mon Nov  4 06:10:04 2019
From: report at bugs.python.org (Tomas Hyland)
Date: Mon, 04 Nov 2019 11:10:04 +0000
Subject: [issue33178] Add support for BigEndianUnion and LittleEndianUnion in
 ctypes
In-Reply-To: <1522331303.68.0.467229070634.issue33178@psf.upfronthosting.co.za>
Message-ID: <1572865804.11.0.301465467018.issue33178@roundup.psfhosted.org>


Tomas Hyland <tomas.hyland at hotmail.co.uk> added the comment:

Hi there, I'm taking part in 'EnHackathon' spending several days over the next few weeks working on issues. I think this could be a good issue for a small team of first-time contributors with experience in C to work on.
Would anyone be able to offer guidance if we encounter problems?

----------
nosy: +tohyland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33178>
_______________________________________

From report at bugs.python.org  Mon Nov  4 06:15:08 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 04 Nov 2019 11:15:08 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572866108.11.0.847614201892.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> The asynchronous spawning of threads or processes would also not be compatible with the executor subclasses as far as I can tell.

> Thus, it seemed to make more sense to me to actually build up a new Pool class from scratch that was largely based on Executor, but with significantly differing functionality. Otherwise, it seems like we would have to make some modifications to ThreadPoolExecutor, or inherit from it and then redesign the internals of some of the methods to change the way the threads/processes are spawned. 

I'm going to have to rescind the above statements. I was able to implement a new prototype of asyncio.ThreadPool (using ThreadPoolExecutor) that spawns it's threads asynchronously on startup. Since this one a bit more involved than the previous code examples, I created a gist: https://gist.github.com/aeros/8a86de6b13f17b9f717ea539ee1ee78f

It's by no means a complete implementation, but it at least proves the functionality that Yury described is very much possible using the existing ThreadPoolExecutor class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Mon Nov  4 06:17:29 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 04 Nov 2019 11:17:29 +0000
Subject: [issue38314] Implement unix read_pipe.is_reading() method
In-Reply-To: <1569756133.59.0.955288942116.issue38314@roundup.psfhosted.org>
Message-ID: <1572866249.31.0.731249340583.issue38314@roundup.psfhosted.org>


Callum Ward <wards.callum at gmail.com> added the comment:

I've agreed with Ben that I'll look at making the necessary changes today.

----------
nosy: +callumquick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38314>
_______________________________________

From report at bugs.python.org  Mon Nov  4 07:24:10 2019
From: report at bugs.python.org (Alexandru Ardelean)
Date: Mon, 04 Nov 2019 12:24:10 +0000
Subject: [issue38684] hashlib: build fails when blake2 is disabled in OpenSSL
Message-ID: <1572870250.89.0.269143912742.issue38684@roundup.psfhosted.org>


New submission from Alexandru Ardelean <ardeleanalex at gmail.com>:

This was caught via OpenWrt's build, when upgrading to 3.8.
By default, Blake2 is not enabled in OpenWrt's OpenSSL.
Not sure if this is an issue in OpenSSL or Python or both.

After digging through the _hashopenssl.c, it seems that the check for Blake2 being enabled/present in OpenSSL is not consistent with how OpenSSL does it.

The build error is:

86_64-openwrt-linux-musl-gcc -shared -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -znow -zrelro -L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0 -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -znow -zrelro -L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0 -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -znow -zrelro -L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0 -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -ffile-prefix-map=/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0=Python-3.8.0 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -DNDEBUG -fno-inline -I/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/include -I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/include -I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/include/fortify -I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/include build/temp.linux2-3.8/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_curses_panel.o -L. -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0 -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/x86_64-openwrt-linux-musl/lib -lpanelw -lncursesw -o build/lib.linux2-3.8/_curses_panel.cpython-38.so
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c: In function 'py_digest_by_name':
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:220:22: error: implicit declaration of function 'EVP_blake2s256'; did you mean 'SN_blake2s256'? [-Werror=implicit-function-declaration]
             digest = EVP_blake2s256();
                      ^~~~~~~~~~~~~~
                      SN_blake2s256
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:220:20: warning: assignment to 'const EVP_MD *' {aka 'const struct evp_md_st *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
             digest = EVP_blake2s256();
                    ^
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:223:22: error: implicit declaration of function 'EVP_blake2b512'; did you mean 'LN_blake2b512'? [-Werror=implicit-function-declaration]
             digest = EVP_blake2b512();
                      ^~~~~~~~~~~~~~
                      LN_blake2b512
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:223:20: warning: assignment to 'const EVP_MD *' {aka 'const struct evp_md_st *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
             digest = EVP_blake2b512();
                    ^

----------
assignee: christian.heimes
components: Build, SSL
messages: 355940
nosy: Alexandru Ardelean, christian.heimes
priority: normal
severity: normal
status: open
title: hashlib: build fails when blake2 is disabled in OpenSSL
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38684>
_______________________________________

From report at bugs.python.org  Mon Nov  4 07:24:52 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 04 Nov 2019 12:24:52 +0000
Subject: [issue38314] Implement unix read_pipe.is_reading() method
In-Reply-To: <1569756133.59.0.955288942116.issue38314@roundup.psfhosted.org>
Message-ID: <1572870292.38.0.260290101903.issue38314@roundup.psfhosted.org>


Change by Callum Ward <wards.callum at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38314>
_______________________________________

From report at bugs.python.org  Mon Nov  4 07:35:48 2019
From: report at bugs.python.org (Alexandru Ardelean)
Date: Mon, 04 Nov 2019 12:35:48 +0000
Subject: [issue38684] hashlib: build fails when blake2 is disabled in OpenSSL
In-Reply-To: <1572870250.89.0.269143912742.issue38684@roundup.psfhosted.org>
Message-ID: <1572870948.24.0.637725297517.issue38684@roundup.psfhosted.org>


Change by Alexandru Ardelean <ardeleanalex at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38684>
_______________________________________

From report at bugs.python.org  Mon Nov  4 08:02:45 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 04 Nov 2019 13:02:45 +0000
Subject: [issue38685] can't create a venv with a dash in the name
Message-ID: <1572872565.71.0.957750113607.issue38685@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

I tried to create a venv via python -m venv 

here are the commands:

> python --version
Python 3.8.0

> python -m venv ~/.virtualenvs/test-proftpd
Error: [Errno 40] Too many levels of symbolic links: '/home/stephane/.virtualenvs/test-proftpd/bin/python'
Fail with a dash.

> python -m venv ~/.virtualenvs/test_proftpd
Work fine with an underscore

----------
messages: 355941
nosy: matrixise
priority: normal
severity: normal
status: open
title: can't create a venv with a dash in the name
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38685>
_______________________________________

From report at bugs.python.org  Mon Nov  4 08:03:55 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 04 Nov 2019 13:03:55 +0000
Subject: [issue38685] can't create a venv with a dash in the name
In-Reply-To: <1572872565.71.0.957750113607.issue38685@roundup.psfhosted.org>
Message-ID: <1572872635.8.0.192344966535.issue38685@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

close, bad manip :/

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38685>
_______________________________________

From report at bugs.python.org  Mon Nov  4 09:25:10 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 04 Nov 2019 14:25:10 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
In-Reply-To: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>
Message-ID: <1572877510.95.0.938618011217.issue38680@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

What's the value of PyGILState_Check() before the call to PyGILState_Ensure()? 

PyGILState_Ensure() and PyGILState_Release() should bracket code where you're not sure about the current GIL state, but need the GIL.  The Release function only undoes the action of the Ensure function, and won't release the GIL if the GIL was held before the call to the Ensure function.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Mon Nov  4 09:33:21 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 04 Nov 2019 14:33:21 +0000
Subject: [issue38599] Deprecate creation of asyncio object when the loop is
 not running
In-Reply-To: <1572160085.79.0.39835517746.issue38599@roundup.psfhosted.org>
Message-ID: <1572878001.97.0.444894282368.issue38599@roundup.psfhosted.org>


Callum Ward <wards.callum at gmail.com> added the comment:

Hi, I'm a new contributor and this issue looks like an interesting enhancement: is there any consensus forming on what we want to limit to e.g. raising depreciation warnings when these first-class classes are created without running event loop?

----------
nosy: +callumquick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38599>
_______________________________________

From report at bugs.python.org  Mon Nov  4 09:45:14 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 04 Nov 2019 14:45:14 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572878714.85.0.875325365989.issue38285@roundup.psfhosted.org>


Callum Ward <wards.callum at gmail.com> added the comment:

Hi Andrew, I'm a new contributor, but this sounds like a pretty cool enhancement. 

Would you be able to elaborate on what kind of things might be required to support each new socket type and test them in particular so I can see if I can take it on?

----------
nosy: +callumquick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 09:56:02 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Nov 2019 14:56:02 +0000
Subject: [issue38684] hashlib: build fails when blake2 is disabled in OpenSSL
In-Reply-To: <1572870250.89.0.269143912742.issue38684@roundup.psfhosted.org>
Message-ID: <1572879362.14.0.192968255735.issue38684@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 6552563b3d5061816720a5a6c7d4ffd6ba35b98b by Christian Heimes (Alexandru Ardelean) in branch 'master':
bpo-38684: haslib: fix build when Blake2 not enabled in OpenSSL (#17043)
https://github.com/python/cpython/commit/6552563b3d5061816720a5a6c7d4ffd6ba35b98b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38684>
_______________________________________

From report at bugs.python.org  Mon Nov  4 09:56:23 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Nov 2019 14:56:23 +0000
Subject: [issue38684] hashlib: build fails when blake2 is disabled in OpenSSL
In-Reply-To: <1572870250.89.0.269143912742.issue38684@roundup.psfhosted.org>
Message-ID: <1572879383.0.0.724679416502.issue38684@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16557
pull_request: https://github.com/python/cpython/pull/17044

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38684>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:00:39 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 04 Nov 2019 15:00:39 +0000
Subject: [issue38608] Undocumented behavior that IsolatedAsyncioTestCase would
 enable event loop debug mode
In-Reply-To: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>
Message-ID: <1572879639.58.0.406531234487.issue38608@roundup.psfhosted.org>


Callum Ward <wards.callum at gmail.com> added the comment:

Hi, is there anything that needs to be fixed or done here?

----------
nosy: +callumquick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38608>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:07:58 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 04 Nov 2019 15:07:58 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572880078.89.0.994067665301.issue38285@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

For each type, we need at least a test that creates a socket pair and successfully transfers data through the wire.

I don't know what additional things are required. For example, on reading about SOCK_SEQ_PACKET I've found that recvmsg() is highly recommended over recv() to get messages boundaries. It obviously requires the new transport type and the new async protocol specification.

Doesn't look trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:12:24 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 04 Nov 2019 15:12:24 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572880344.25.0.915466628072.issue38285@roundup.psfhosted.org>


Callum Ward <wards.callum at gmail.com> added the comment:

A matter of creating tests to allow test enabling of new socket types I could attempt, but new protocol/transport types may be beyond me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:19:05 2019
From: report at bugs.python.org (Jackson Riley)
Date: Mon, 04 Nov 2019 15:19:05 +0000
Subject: [issue23692] Undocumented feature prevents re module from finding
 certain matches
In-Reply-To: <1426618184.57.0.811463464384.issue23692@psf.upfronthosting.co.za>
Message-ID: <1572880745.27.0.40252899103.issue23692@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Hi Matthew, thank you for your suggestions of where to start.
Could you possibly give a pointer to the place in the code where the 'capture changed' counter is incremented? I had a bit of a hunt and couldn't find it but may have been looking in the wrong places!

----------
nosy: +jacksonriley

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23692>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:20:53 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 04 Nov 2019 15:20:53 +0000
Subject: [issue29930] Waiting for asyncio.StreamWriter.drain() twice in
 parallel raises an AssertionError when the transport stopped writing
In-Reply-To: <1490694354.71.0.0417616939951.issue29930@psf.upfronthosting.co.za>
Message-ID: <1572880853.91.0.365904753167.issue29930@roundup.psfhosted.org>


Callum Ward <wards.callum at gmail.com> added the comment:

Hi, I'm a new contributor: is there any consensus on what or if something needs to be done? If so, I can try and take forward the patch.

----------
nosy: +callumquick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29930>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:23:05 2019
From: report at bugs.python.org (Fred Drake)
Date: Mon, 04 Nov 2019 15:23:05 +0000
Subject: [issue38621] Bad decoding of encoded-words in unstructured email
 headers
In-Reply-To: <1572281263.86.0.289924184677.issue38621@roundup.psfhosted.org>
Message-ID: <1572880985.49.0.715106769945.issue38621@roundup.psfhosted.org>


Change by Fred Drake <fdrake at gmail.com>:


----------
resolution: fixed -> rejected
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38621>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:27:24 2019
From: report at bugs.python.org (PypeBros)
Date: Mon, 04 Nov 2019 15:27:24 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
Message-ID: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>


New submission from PypeBros <pype_1999.geo at yahoo.com>:

in urllib/request.py, 
   when trying to use HTTP Digest Authentication 
   with a server that replies with `WWW-Authenticate: Digest` 
   where `qop="auth,auth-int"` rather than mere `qop="auth"`

the connection fails to establish with a "qop 'auth,auth-int' is not supported" error message.

`qop="auth,auth-int" should imho be accepted according to the `qop-options` rule in ?3.2.1 of https://www.ietf.org/rfc/rfc2617.txt, given that 'auth' is supported by urllib/request.py

----------
messages: 355952
nosy: PypeBros
priority: normal
severity: normal
status: open
title: WWW-Authenticate qop="auth,auth-int" rejected by urllib
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:34:25 2019
From: report at bugs.python.org (PypeBros)
Date: Mon, 04 Nov 2019 15:34:25 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1572881665.28.0.00932202787356.issue38686@roundup.psfhosted.org>


Change by PypeBros <pype_1999.geo at yahoo.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:35:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Nov 2019 15:35:21 +0000
Subject: [issue23692] Undocumented feature prevents re module from finding
 certain matches
In-Reply-To: <1426618184.57.0.811463464384.issue23692@psf.upfronthosting.co.za>
Message-ID: <1572881721.72.0.837490502739.issue23692@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Matthew referred to the code of the regex module (of which he is the author).

https://pypi.org/project/regex/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23692>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:37:33 2019
From: report at bugs.python.org (=?utf-8?q?Malvers=C3=A1n?=)
Date: Mon, 04 Nov 2019 15:37:33 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572881853.27.0.788595037575.issue38285@roundup.psfhosted.org>


Malvers?n <malverspam at gmail.com> added the comment:

It has a certain logic to recommend recvmsg() in place of recv(), as SOCK_SEQ_PACKET is characterized by transmitting entire messages only. But it has to be noted that my current hack (described above) is working for SOCK_SEQ_PACKET sockets with no modification of the asyncio underlying reading logic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:45:50 2019
From: report at bugs.python.org (Jackson Riley)
Date: Mon, 04 Nov 2019 15:45:50 +0000
Subject: [issue23692] Undocumented feature prevents re module from finding
 certain matches
In-Reply-To: <1426618184.57.0.811463464384.issue23692@psf.upfronthosting.co.za>
Message-ID: <1572882350.24.0.238642946728.issue23692@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Ah thank you very much Serhiy, that's super helpful!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23692>
_______________________________________

From report at bugs.python.org  Mon Nov  4 10:59:13 2019
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 04 Nov 2019 15:59:13 +0000
Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an
 IPv4 /32
In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za>
Message-ID: <1572883153.93.0.958014515404.issue28577@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I came across this /32 issue today trying to iterate over the hosts in 127.0.0.1/32.  I think it's fair to say that any /32 network has precisely one host, and that host should by returned by IPv4Network().hosts().

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28577>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:22:47 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 04 Nov 2019 16:22:47 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572884567.39.0.559233892915.issue32309@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I'm going to have to rescind the above statements. I was able to implement a new prototype of asyncio.ThreadPool (using ThreadPoolExecutor) that spawns it's threads asynchronously on startup. Since this one a bit more involved than the previous code examples, I created a gist: https://gist.github.com/aeros/8a86de6b13f17b9f717ea539ee1ee78f

Nice work! This is a great excercise, but we can really just use concurrent.futures.ThreadPool as is. Spawning threads is fast. As I mentioned before all we need to do is to design *our* API to NOT initialize pools in __init__, that's it. The design outlined in https://bugs.python.org/msg355881 would do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:24:12 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 04 Nov 2019 16:24:12 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572884652.09.0.320049376836.issue38285@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

How to get the message boundary without recvmsg()? Sorry, I'm not familiar with seqpacket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:24:46 2019
From: report at bugs.python.org (Alex)
Date: Mon, 04 Nov 2019 16:24:46 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1572884686.65.0.284177687921.issue11354@roundup.psfhosted.org>


Alex <alexpclarkson at gmail.com> added the comment:

I've had a look at the most recent patch and the code surrounding it, and I would be happy to take on the work to update the code and testing.

However,
> - It's easy to test for this range after parsing, with '*' or '+' nargs.  So the main thing this patch adds is in the help/usage display.  It doesn't add significant functionality.

I didn't initially consider this.

I'd still be happy to finish this off, but if the general feeling is that contribution time would be better spent elsewhere then that's also fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:25:15 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 04 Nov 2019 16:25:15 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572884715.39.0.954439691889.issue38285@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Another question: does SSL/TLS make sense for seqpacket?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:27:38 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 04 Nov 2019 16:27:38 +0000
Subject: [issue38608] Undocumented behavior that IsolatedAsyncioTestCase would
 enable event loop debug mode
In-Reply-To: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>
Message-ID: <1572884858.83.0.874372289173.issue38608@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

At first, would be nice to figure out what "invalid line reported" does mean.  
What text is reported and what is expected?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38608>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:41:35 2019
From: report at bugs.python.org (=?utf-8?q?Malvers=C3=A1n?=)
Date: Mon, 04 Nov 2019 16:41:35 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572885695.69.0.580657450759.issue38285@roundup.psfhosted.org>


Malvers?n <malverspam at gmail.com> added the comment:

I do not have the answer about getting message boundaries at lower levels, but from a high-level point of view SOCK_SEQ_PACKET gives atomic reads, with no need to check for message boundaries yourself. Every time you read from a SOCK_SEQ_PACKET socket you get an entire message. That is the main difference with SOCK_STREAM, as far as I know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:51:11 2019
From: report at bugs.python.org (Anj-A)
Date: Mon, 04 Nov 2019 16:51:11 +0000
Subject: [issue37436] os.path.isfile() with big number cause OverflowError: fd
 is greater than maximum
In-Reply-To: <1561686823.22.0.469835611791.issue37436@roundup.psfhosted.org>
Message-ID: <1572886271.42.0.885795324563.issue37436@roundup.psfhosted.org>


Anj-A <2017anj at gmail.com> added the comment:

Hi all, I'm a newcomer interested in doing a small fix. Wondering if anyone's working on this at the moment?

----------
nosy: +Anj-A

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37436>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:53:25 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 04 Nov 2019 16:53:25 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1572886405.92.0.256310123574.issue15243@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:53:37 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 04 Nov 2019 16:53:37 +0000
Subject: [issue9495] argparse unittest tracebacks are confusing if an error is
 raised when not expected
In-Reply-To: <1280852518.56.0.709280463518.issue9495@psf.upfronthosting.co.za>
Message-ID: <1572886417.85.0.466631646191.issue9495@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9495>
_______________________________________

From report at bugs.python.org  Mon Nov  4 11:56:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 16:56:01 +0000
Subject: [issue37436] os.path.isfile() with big number cause OverflowError: fd
 is greater than maximum
In-Reply-To: <1561686823.22.0.469835611791.issue37436@roundup.psfhosted.org>
Message-ID: <1572886561.16.0.604606792387.issue37436@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue reminds me bpo-33721:

"os.path functions that return a boolean result like exists(), lexists(), isdir(), isfile(), islink(), and ismount() now return False instead of raising ValueError or its subclasses UnicodeEncodeError and UnicodeDecodeError for paths that contain characters or bytes unrepresentable at the OS level. (Contributed by Serhiy Storchaka in bpo-33721.)"

https://docs.python.org/dev/whatsnew/3.8.html#os-path

----------
nosy: +serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37436>
_______________________________________

From report at bugs.python.org  Mon Nov  4 12:11:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 17:11:41 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1572887501.58.0.745287509163.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16559
pull_request: https://github.com/python/cpython/pull/17046

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Nov  4 12:16:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 17:16:57 +0000
Subject: [issue31857] Make the behavior of USE_STACKCHECK deterministic
In-Reply-To: <1508807362.1.0.213398074469.issue31857@psf.upfronthosting.co.za>
Message-ID: <1572887817.87.0.160404070852.issue31857@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue added this FIXME:

/* Due to the macros in which it's used, _Py_CheckRecursionLimit is in
   the stable ABI.  It should be removed therefrom when possible.
*/

FYI I proposed PR 17046 to fix it ;-)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31857>
_______________________________________

From report at bugs.python.org  Mon Nov  4 12:31:41 2019
From: report at bugs.python.org (Anj-A)
Date: Mon, 04 Nov 2019 17:31:41 +0000
Subject: [issue37436] os.path.isfile() with big number cause OverflowError: fd
 is greater than maximum
In-Reply-To: <1561686823.22.0.469835611791.issue37436@roundup.psfhosted.org>
Message-ID: <1572888701.03.0.382151851398.issue37436@roundup.psfhosted.org>


Anj-A <2017anj at gmail.com> added the comment:

Hey, I'm not exactly clear what the required fix is here and would appreciate some guidance, is it in the documentation or in the way the error is handled?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37436>
_______________________________________

From report at bugs.python.org  Mon Nov  4 12:36:30 2019
From: report at bugs.python.org (Anj-A)
Date: Mon, 04 Nov 2019 17:36:30 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1572888990.28.0.852087202671.issue37838@roundup.psfhosted.org>


Change by Anj-A <2017anj at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:05:31 2019
From: report at bugs.python.org (Anj-A)
Date: Mon, 04 Nov 2019 18:05:31 +0000
Subject: [issue38652] Remove/update provisional note for
 asyncio.BufferedProtocol
In-Reply-To: <1572502481.2.0.695475270667.issue38652@roundup.psfhosted.org>
Message-ID: <1572890731.68.0.660254743849.issue38652@roundup.psfhosted.org>


Anj-A <2017anj at gmail.com> added the comment:

Hey, I've done the change and opened a pull request for it (I'm working with Ben and I've let him know)

----------
nosy: +Anj-A

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38652>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:12:04 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Nov 2019 18:12:04 +0000
Subject: [issue37436] os.path.isfile() with big number cause OverflowError: fd
 is greater than maximum
In-Reply-To: <1561686823.22.0.469835611791.issue37436@roundup.psfhosted.org>
Message-ID: <1572891124.43.0.362811707551.issue37436@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am not sure there is much in common between this and issue33721. There are many ways to get a file path unrepresentable at the OS level. But I do not know any valid case for getting an out-of-range file descriptor. I am not convinced there is a bug here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37436>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:35:36 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 04 Nov 2019 18:35:36 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572892536.86.0.605437965708.issue38285@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Can recv() get two messages at once?
What is the behavior if the buffer size passed into recv() is smaller than the message length?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:36:54 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Nov 2019 18:36:54 +0000
Subject: [issue38662] Decouple ensurepip from pip's internals using runpy
In-Reply-To: <1572629064.24.0.519341934772.issue38662@roundup.psfhosted.org>
Message-ID: <1572892614.66.0.758332529157.issue38662@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38662>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:37:56 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Nov 2019 18:37:56 +0000
Subject: [issue38665] Crash when running SQLAlchemy with pyodbc
In-Reply-To: <1572631006.11.0.3731179051.issue38665@roundup.psfhosted.org>
Message-ID: <1572892676.68.0.969860571972.issue38665@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Can you trace this to actually being Python's fault? Unfortunately you're using two extension modules who both could be at fault with this.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38665>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:39:14 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Nov 2019 18:39:14 +0000
Subject: [issue38671] pathlib.Path.resolve(strict=False) returns relative path
 on Windows if the entry does not exist
In-Reply-To: <1572774931.11.0.993470333259.issue38671@roundup.psfhosted.org>
Message-ID: <1572892754.02.0.971651803736.issue38671@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
components: +Library (Lib)
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38671>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:43:59 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Nov 2019 18:43:59 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1572893039.92.0.240291361935.issue38500@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@Mark are you strongly opposed because we're providing an API for changing the eval function in the CPython API and you think it should be in the private API? Or you objecting to PEP 523 all-up (based on your list of objections)? Either way the PEP was accepted and implemented a while ago and so I'm not quite sure what you are expecting as an outcome short of a repeal of PEP 523 which would require a separate PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:44:04 2019
From: report at bugs.python.org (Dave Johansen)
Date: Mon, 04 Nov 2019 18:44:04 +0000
Subject: [issue38665] Crash when running SQLAlchemy with pyodbc
In-Reply-To: <1572631006.11.0.3731179051.issue38665@roundup.psfhosted.org>
Message-ID: <1572893044.82.0.103132340573.issue38665@roundup.psfhosted.org>


Dave Johansen <davejohansen at gmail.com> added the comment:

I can't. I just know that I'm running this process and this crash happens. Any recommendations on how to diagnose that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38665>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:47:32 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Nov 2019 18:47:32 +0000
Subject: [issue38665] Crash when running SQLAlchemy with pyodbc
In-Reply-To: <1572631006.11.0.3731179051.issue38665@roundup.psfhosted.org>
Message-ID: <1572893252.39.0.190471370056.issue38665@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Basically you have to figure out where that bad memory came from and that's just plain hard in C short of slowly cutting out code until you get a small reproducer. Typically these sorts of issues are almost always in the extension modules, but your case is tricky as even if that's true you don't know which one is the cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38665>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:48:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 18:48:37 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1572893317.17.0.40266395417.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f4b1e3d7c64985f5d5b00f6cc9a1c146bbbfd613 by Victor Stinner in branch 'master':
bpo-38644: Add Py_EnterRecursiveCall() to the limited API (GH-17046)
https://github.com/python/cpython/commit/f4b1e3d7c64985f5d5b00f6cc9a1c146bbbfd613


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Nov  4 13:58:35 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 04 Nov 2019 18:58:35 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572893915.1.0.404323482763.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Nice work! This is a great excercise, but we can really just use concurrent.futures.ThreadPool as is. Spawning threads is fast. As I mentioned before all we need to do is to design *our* API to NOT initialize pools in __init__, that's it. The design outlined in https://bugs.python.org/msg355881 would do that.

Thanks, it was quite helpful for better understanding the internals of ThreadPoolExecutor. 

I think that I'm still not understanding something important though. Even if we initialize our ThreadPoolExecutor outside of __init__ (in a start() coroutine method, as your proposing), it seems like the threads will be spawned throughout the lifespan of the threadpool, rather than upon startup since the new threads are spawned in ThreadPoolExecutor *after* executor.submit() is called (up to max_workers) rather than upon initialization. So even if an instance of ThreadPoolExecututor is initialized asynchronously within a start() coroutine method, the individual threads within it won't be spawned at the same time.

That's why I wrote an explicit way of spawning threads in the above example, based on the way that ThreadPoolExecutor spawns threads in _adjust_thread_count(), which is called at the end of submit().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Mon Nov  4 14:01:54 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 04 Nov 2019 19:01:54 +0000
Subject: [issue38652] Remove/update provisional note for
 asyncio.BufferedProtocol
In-Reply-To: <1572502481.2.0.695475270667.issue38652@roundup.psfhosted.org>
Message-ID: <1572894114.19.0.755829273522.issue38652@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Hey, I've done the change and opened a pull request for it (I'm working with Ben and I've let him know)

Make sure to change the title of the PR to "bpo-<issue_number>: <pr_title>", this will automatically attach the PR to the associated bpo issue. For example, if your PR title was "Remove provisional note for asyncio.BufferedProtocol", the full title should be:

bpo-38652: Remove provisional note for asyncio.BufferedProtocol

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38652>
_______________________________________

From report at bugs.python.org  Mon Nov  4 14:11:19 2019
From: report at bugs.python.org (Callum Attryde)
Date: Mon, 04 Nov 2019 19:11:19 +0000
Subject: [issue38687] Expose 'adler32_combine' function from zlib
Message-ID: <1572894679.78.0.661181001635.issue38687@roundup.psfhosted.org>


New submission from Callum Attryde <callumattryde at gmail.com>:

zlib contains a function for combining Adler32 checksums which is not currently exposed by the Python module. This enhancement adds that function to Python

----------
components: Extension Modules
messages: 355977
nosy: callumattryde
priority: normal
severity: normal
status: open
title: Expose 'adler32_combine' function from zlib
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38687>
_______________________________________

From report at bugs.python.org  Mon Nov  4 14:14:20 2019
From: report at bugs.python.org (Callum Attryde)
Date: Mon, 04 Nov 2019 19:14:20 +0000
Subject: [issue38687] Expose 'adler32_combine' function from zlib
In-Reply-To: <1572894679.78.0.661181001635.issue38687@roundup.psfhosted.org>
Message-ID: <1572894860.38.0.219903045522.issue38687@roundup.psfhosted.org>


Change by Callum Attryde <callumattryde at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38687>
_______________________________________

From report at bugs.python.org  Mon Nov  4 14:15:20 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 04 Nov 2019 19:15:20 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1572894920.35.0.713855488662.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> since the new threads are spawned in ThreadPoolExecutor *after* executor.submit() is called

It's also worth mentioning that ThreadPoolExecutor only spawns up to one additional thread at a time for each executor.submit() called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Mon Nov  4 14:16:09 2019
From: report at bugs.python.org (Anj-A)
Date: Mon, 04 Nov 2019 19:16:09 +0000
Subject: [issue38652] Remove/update provisional note for
 asyncio.BufferedProtocol
In-Reply-To: <1572502481.2.0.695475270667.issue38652@roundup.psfhosted.org>
Message-ID: <1572894969.04.0.0834003667357.issue38652@roundup.psfhosted.org>


Change by Anj-A <2017anj at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38652>
_______________________________________

From report at bugs.python.org  Mon Nov  4 14:42:47 2019
From: report at bugs.python.org (=?utf-8?q?Malvers=C3=A1n?=)
Date: Mon, 04 Nov 2019 19:42:47 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572896567.61.0.584102817578.issue38285@roundup.psfhosted.org>


Malvers?n <malverspam at gmail.com> added the comment:

In my scenario that buffer overrun never happens, maybe because I use messages that are not big enough to overflow the default recv() buffer size.

But I think I can confirm that multiple messages are never received in an atomic read, even if they are being issued intensively in short millisecond intervals. Even more, I think there is a recvmmsg() call specific for that purpose if you want to receive multiple reads at once.

As I said I do not have the answers, I rely on the high-level definitions and have little knowledge about how it works at low level.

But I think your question may be extended also to recvmsg(). What is its behaviour if it fills all the passed iovec structs?

Probably an answer can be found where you found the recommendation of using recvmsg() over recv(). There should be a reason for that recommendation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Mon Nov  4 15:59:38 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Nov 2019 20:59:38 +0000
Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not
 exported in python38.dll
In-Reply-To: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org>
Message-ID: <1572901178.98.0.25068178892.issue37633@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I've flagged this as a release blocker so the Release Manager can make a call about whether this should hold up future releases.

----------
nosy: +brett.cannon
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37633>
_______________________________________

From report at bugs.python.org  Mon Nov  4 16:21:38 2019
From: report at bugs.python.org (Christian Boltz)
Date: Mon, 04 Nov 2019 21:21:38 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
Message-ID: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>


New submission from Christian Boltz <python-bugs at cboltz.de>:

The following test script works with Python 3.7 (and older), but triggers an endless loop with Python 3.8:


#!/usr/bin/python3

import shutil
import os

os.mkdir('/dev/shm/t')
os.mkdir('/dev/shm/t/pg')

with open('/dev/shm/t/pg/pol', 'w+') as f:
    f.write('pol')

shutil.copytree('/dev/shm/t/pg', '/dev/shm/t/pg/somevendor/1.0')


The important point is probably that 'pg' gets copied into a subdirectory of itsself. While this worked in Python up to 3.7, doing the same in Python 3.8 runs into an endless loop:

# python3 /home/abuild/rpmbuild/SOURCES/test.py
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/SOURCES/test.py", line 15, in <module> 
    shutil.copytree('/dev/shm/t/pg', '/dev/shm/t/pg/somevendor/1.0')
  File "/usr/lib/python3.8/shutil.py", line 547, in copytree 
    return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
  File "/usr/lib/python3.8/shutil.py", line 486, in _copytree
    copytree(srcobj, dstname, symlinks, ignore, copy_function,
...
    copytree(srcobj, dstname, symlinks, ignore, copy_function,
  File "/usr/lib/python3.8/shutil.py", line 547, in copytree 
    return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
  File "/usr/lib/python3.8/shutil.py", line 449, in _copytree
    os.makedirs(dst, exist_ok=dirs_exist_ok)
  File "/usr/lib/python3.8/os.py", line 206, in makedirs 
    head, tail = path.split(name)
  File "/usr/lib/python3.8/posixpath.py", line 104, in split 
    sep = _get_sep(p)
  File "/usr/lib/python3.8/posixpath.py", line 42, in _get_sep 
    if isinstance(path, bytes):
RecursionError: maximum recursion depth exceeded while calling a Python object

I also reported this at https://bugzilla.opensuse.org/show_bug.cgi?id=1155839

----------
components: Library (Lib)
messages: 355981
nosy: cboltz
priority: normal
severity: normal
status: open
title: Python 3.8 regression: endless loop in shutil.copytree
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Mon Nov  4 16:24:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 21:24:13 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1572902653.89.0.115001866366.issue38688@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Mon Nov  4 17:02:29 2019
From: report at bugs.python.org (Jackson Riley)
Date: Mon, 04 Nov 2019 22:02:29 +0000
Subject: [issue23692] Undocumented feature prevents re module from finding
 certain matches
In-Reply-To: <1426618184.57.0.811463464384.issue23692@psf.upfronthosting.co.za>
Message-ID: <1572904949.22.0.183185261375.issue23692@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

I've got a bit confused and am doubting myself - is the below output expected?
>>> m = re.match('(?:()|(?(1)()|z)){1,2}(?(2)a|z)', 'a')
>>> m.groups()
('', '')
>>> m = re.match('(?:()|(?(1)()|z)){1,2}(?(1)a|z)', 'a')
>>> m.groups()
('', None)

The first pattern doesn't behave as I would (probably naively expect) given Matthew's explanation of this bug - wouldn't the bug cause the match to fail with {1,2} as well?
Also, it seems odd that changing the condition in the if clause should change what gets captured.

Anyone have any thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23692>
_______________________________________

From report at bugs.python.org  Mon Nov  4 18:45:56 2019
From: report at bugs.python.org (Dan Snider)
Date: Mon, 04 Nov 2019 23:45:56 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
Message-ID: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

When the following program has been input (into 32 bit 3.8.0 Python running on windows 10), all IDLE processes and windows will immediately and irrevocably hang the instant the open parentheses at the end of the statement "Object(" is rendered.

However that's just my 90% sure guess of the cause, based on 
 how when the regular dict from this example is swapped with one that raises AttributeError instead of KeyError, a crash no longer occurs. Quite perplexing, seeing as neither exception is handled in get_argspec.

>>> if 1:
    from idlelib.calltip import get_argspec
    class Type(type):
        __class__ = property((__class__:={}).__getitem__,__class__.__setitem__)
    class Object(metaclass=Type):
        __slots__ = '__class__'
    get_argspec(Object)

    
Traceback (most recent call last):
  File "<pyshell#41>", line 7, in <module>
    get_argspec(Object)
  File "C:\Python38\lib\idlelib\calltip.py", line 141, in get_argspec
    argspec = str(inspect.signature(fob))
  File "C:\Python38\lib\inspect.py", line 3093, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "C:\Python38\lib\inspect.py", line 2842, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
  File "C:\Python38\lib\inspect.py", line 2218, in _signature_from_callable
    if isinstance(obj, types.MethodType):
KeyError: <class '__main__.Object'>

----------
assignee: terry.reedy
components: IDLE
messages: 355983
nosy: bup, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE crashes when KeyError is raised during calltip generation
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38689>
_______________________________________

From report at bugs.python.org  Mon Nov  4 18:51:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 23:51:26 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1572911486.84.0.468130394048.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset be434dc0380d9f5c7c800de9943cc46d55fd9491 by Victor Stinner in branch 'master':
bpo-38644: Pass tstate to Py_EnterRecursiveCall() (GH-16997)
https://github.com/python/cpython/commit/be434dc0380d9f5c7c800de9943cc46d55fd9491


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Nov  4 18:52:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Nov 2019 23:52:50 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1572911570.48.0.0648114808505.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16564
pull_request: https://github.com/python/cpython/pull/17050

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Nov  4 19:04:16 2019
From: report at bugs.python.org (jason gors)
Date: Tue, 05 Nov 2019 00:04:16 +0000
Subject: [issue38690] Command line option with &/or without a space results in
 the same outcome
Message-ID: <1572912256.03.0.374020363309.issue38690@roundup.psfhosted.org>


New submission from jason gors <jason.gors at gmail.com>:

The syntax in the Command line documentation was unexpected regarding the `-m` option (specifically `python -mtimeit`) [0].  Showing this:

```
python -mtimeit "range(100)"
# behaving equivalent to this:
python -m timeit "range(100)"
```

This led me to discover many cases where command line arguments are like this in python (e.g. the call working correctly without a space between an argument flag and what is being passed into the command).  Like this:

```
python -c"print('Hi')"
# behaving the same as:
python -c "print('Hi')"
```

This is also the case with pip as well:

```
pip install -rrequirements.txt 
# behaving exactly like:
pip install -r requirements.txt
```

However, when I think of the *nix commands, like `rm`, this behavior fails.  When you want to pass several flags at once, you can either list them separately (e.g. `rm -f -i myfile.py`) or concatenate them together (e.g. `rm -fi myfile.py`), but `rm` fails if you try calling it without a space between the argument(s) and the file to be removed (e.g.`rm -fimyfile.py`).

I'm not sure whether this command line behavior in python is intentional, but it's not obvious as to why this is the case.

[0] https://docs.python.org/3/using/cmdline.html#cmdoption-m

----------
components: Library (Lib)
messages: 355985
nosy: jgors
priority: normal
severity: normal
status: open
title: Command line option with &/or without a space results in the same outcome
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38690>
_______________________________________

From report at bugs.python.org  Mon Nov  4 19:07:45 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Tue, 05 Nov 2019 00:07:45 +0000
Subject: [issue38475] Break Statement
In-Reply-To: <1571081462.55.0.733459298847.issue38475@roundup.psfhosted.org>
Message-ID: <1572912465.13.0.336638543476.issue38475@roundup.psfhosted.org>


Lewis Gaul <lewis.gaul at gmail.com> added the comment:

Should this issue be closed?

----------
nosy: +Lewis Gaul

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38475>
_______________________________________

From report at bugs.python.org  Mon Nov  4 19:22:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 00:22:14 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1572913334.91.0.467714094356.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 17269090940aa20f6079a6b9f27ae319f8cdae14 by Victor Stinner in branch 'master':
bpo-38644: Pass tstate to _Py_CheckFunctionResult() (GH-17050)
https://github.com/python/cpython/commit/17269090940aa20f6079a6b9f27ae319f8cdae14


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Nov  4 19:38:14 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 05 Nov 2019 00:38:14 +0000
Subject: [issue25522] IDLE: warn if save-as name matches stdlib name
In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za>
Message-ID: <1572914294.2.0.116421016095.issue25522@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25522>
_______________________________________

From report at bugs.python.org  Mon Nov  4 19:40:06 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 05 Nov 2019 00:40:06 +0000
Subject: [issue25522] IDLE: warn if save-as name matches stdlib name
In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za>
Message-ID: <1572914406.38.0.152056719818.issue25522@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created a pull request for this issue.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25522>
_______________________________________

From report at bugs.python.org  Mon Nov  4 19:46:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 00:46:04 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1572914764.39.0.514591661421.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16566
pull_request: https://github.com/python/cpython/pull/17052

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Nov  4 19:48:04 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 05 Nov 2019 00:48:04 +0000
Subject: [issue23692] Undocumented feature prevents re module from finding
 certain matches
In-Reply-To: <1426618184.57.0.811463464384.issue23692@psf.upfronthosting.co.za>
Message-ID: <1572914884.25.0.398287333528.issue23692@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It's been many years since I looked at the code, and there have been changes since then, so some of the details might not be correct.

As to have it should behave:

re.match('(?:()|(?(1)()|z)){1,2}(?(2)a|z)', 'a')

Iteration 1.
Match the repeated part. Group 1 matches.
Iteration 2.
Match the repeated part. Group 1 matches.
Has group 2 matched? No.
Try to match 'z'. Fail and backtrack.
Retry the repeated part.
Iteration 2.
Has group 1 matched? Yes.
Group 2 matches.
Has group 2 matched? Yes.
Try to match 'a'. Success. Group 1 matched and group 2 matched.


re.match('(?:()|(?(1)()|z)){1,2}(?(1)a|z)', 'a')

Iteration 1.
Match the repeated part. Group 1 matches.
Iteration 2.
Match the repeated part. Group 1 matches.
Has group 1 matched? Yes.
Try to match 'a'. Success. Group 1 matched and group 2 didn't match.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23692>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:14:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:14:22 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1572916462.54.0.340514112076.issue38500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> IMO this punches a big hole in the Python execution model, but provides no benefit.

This PEP is about fixing a Python 3.8 regression. In Python 3.7, it was possible to get and set frame_eval. In Python 3.8, it's no longer possible.

One option to fix the regression would be to again expose PyInterpreterState structure... but we are trying to do the opposite: hide more structures, not expose more structures :-/

IMHO private getter and setter functions are perfectly fine. Please ensure that the setter can report an issue. We have too many setters which cannot report an error which is very painful :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:20:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:20:32 +0000
Subject: [issue38430] Memory leak in ThreadPoolExecutor + run_in_executor
In-Reply-To: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>
Message-ID: <1572916832.42.0.533262263949.issue38430@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38430>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:23:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:23:24 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1572917004.12.0.750181459232.issue37373@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Is it be possible to backport this inside the standard ProactorEventLoop of Python-3.8.1 ? As things are currently broken, no kitten would be armed https://github.com/python-trio/trio/pull/1269

No, we don't add features to minor releases.

If you need add_reader(), your code works with Python 3.7 but fails with 3.8, you can use the following code to ensure that you use the SelectorEventLoop:

if sys.platform == 'win32':
  asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:24:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:24:49 +0000
Subject: [issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1572917089.02.0.917677002144.issue36439@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:25:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:25:38 +0000
Subject: [issue36084] Threading: add builtin TID attribute to Thread objects
In-Reply-To: <1550875571.41.0.297490361597.issue36084@roundup.psfhosted.org>
Message-ID: <1572917138.51.0.968986303116.issue36084@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I have encountered a minor bug with this new feature.

Please open a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36084>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:29:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:29:42 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1572917382.24.0.431837243533.issue16575@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This change introduced a reference leak on Windows. Example on 3.7:

https://buildbot.python.org/all/#/builders/132/builds/645

test_ctypes leaked [174, 174, 174] references, sum=522
test_ctypes leaked [76, 77, 77] memory blocks, sum=230

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:31:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:31:11 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1572917471.44.0.637508800365.issue16575@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Same issue on x86 Gentoo Refleaks 3.7:

test_ctypes leaked [174, 174, 174] references, sum=522
test_ctypes leaked [76, 78, 76] memory blocks, sum=230

https://buildbot.python.org/all/#/builders/114/builds/631

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:31:45 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Tue, 05 Nov 2019 01:31:45 +0000
Subject: [issue27994] In the argparse help(argparse) prints weird comments
 instead of good docstrings
In-Reply-To: <1473218429.0.0.161771079956.issue27994@psf.upfronthosting.co.za>
Message-ID: <1572917505.47.0.330515261916.issue27994@roundup.psfhosted.org>


Lewis Gaul <lewis.gaul at gmail.com> added the comment:

This doesn't seem to be the case [anymore] to me, should this be closed?

----------
nosy: +Lewis Gaul

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27994>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:31:59 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Tue, 05 Nov 2019 01:31:59 +0000
Subject: [issue27994] In the argparse help(argparse) prints weird comments
 instead of good docstrings
In-Reply-To: <1473218429.0.0.161771079956.issue27994@psf.upfronthosting.co.za>
Message-ID: <1572917519.11.0.678004026465.issue27994@roundup.psfhosted.org>


Change by Lewis Gaul <lewis.gaul at gmail.com>:


----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27994>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:55:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:55:56 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
Message-ID: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

When using python3 -E or python3 -I, PYTHONCASEOK environment variable should be ignored by importlib. See an email sent in 2012:
https://mail.python.org/pipermail/python-dev/2012-December/123403.html

See importlib._bootstrap_external._relax_case attribute and its _make_relax_case() function.

----------
components: Library (Lib)
messages: 355996
nosy: vstinner
priority: normal
severity: normal
status: open
title: importlib: PYTHONCASEOK should be ignored when using python3 -E
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Mon Nov  4 21:17:21 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Nov 2019 02:17:21 +0000
Subject: [issue27994] In the argparse help(argparse) prints weird comments
 instead of good docstrings
In-Reply-To: <1473218429.0.0.161771079956.issue27994@psf.upfronthosting.co.za>
Message-ID: <1572920241.65.0.133505556949.issue27994@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27994>
_______________________________________

From report at bugs.python.org  Mon Nov  4 23:23:25 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Nov 2019 04:23:25 +0000
Subject: [issue38475] Break Statement
In-Reply-To: <1571081462.55.0.733459298847.issue38475@roundup.psfhosted.org>
Message-ID: <1572927805.36.0.665374416041.issue38475@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Absent any response from the OP, I'm going to go with yes.

Devor, if you can reduce your example to show a bug in the Python interpreter or standard library, please reopen with that example.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38475>
_______________________________________

From report at bugs.python.org  Tue Nov  5 00:06:19 2019
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 05 Nov 2019 05:06:19 +0000
Subject: [issue38655] ipaddress.ip_network('0.0.0.0/0').is_private == True
In-Reply-To: <1572530691.84.0.462430681921.issue38655@roundup.psfhosted.org>
Message-ID: <1572930379.69.0.960445601499.issue38655@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

The documentation for is_private notes:

  Returns:
  A boolean, True if the address is reserved per RFC 4193.
  iana-ipv4-special-registry or iana-ipv6-special-registry.

If we take a look at the iana-ipv4-special-registry then 0.0.0.0/8 does show up there: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

While the name might be a misnomer, is_reserved instead of is_private might have been better, it does seem to conform to what the documentation says it will do.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38655>
_______________________________________

From report at bugs.python.org  Tue Nov  5 00:09:49 2019
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 05 Nov 2019 05:09:49 +0000
Subject: [issue38655] ipaddress.ip_network('0.0.0.0/0').is_private == True
In-Reply-To: <1572530691.84.0.462430681921.issue38655@roundup.psfhosted.org>
Message-ID: <1572930589.77.0.342843758446.issue38655@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Aah actually I was looking at an older version of the docs, the documentation now says, "if the address is allocated for private networks" which is actually misleading. The addresses here aren't all private networks: https://github.com/python/cpython/blob/25fa3ecb98f2c038a422b19c53641fa8e3ef8e52/Lib/ipaddress.py#L1537-L1553

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38655>
_______________________________________

From report at bugs.python.org  Tue Nov  5 00:11:57 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Nov 2019 05:11:57 +0000
Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not
 exported in python38.dll
In-Reply-To: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org>
Message-ID: <1572930717.69.0.0564977850983.issue37633@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37633>
_______________________________________

From report at bugs.python.org  Tue Nov  5 00:34:17 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Nov 2019 05:34:17 +0000
Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not
 exported in python38.dll
In-Reply-To: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org>
Message-ID: <1572932057.8.0.607581163961.issue37633@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 62161ce989d7d4fe2b0e6899a54da20feeddc798 by Benjamin Peterson in branch 'master':
closes bpo-37633: Re?xport some function compatibility wrappers for macros in ``pythonrun.h``. (GH-17056)
https://github.com/python/cpython/commit/62161ce989d7d4fe2b0e6899a54da20feeddc798


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37633>
_______________________________________

From report at bugs.python.org  Tue Nov  5 00:34:56 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 05 Nov 2019 05:34:56 +0000
Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not
 exported in python38.dll
In-Reply-To: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org>
Message-ID: <1572932096.71.0.221363805443.issue37633@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16568
pull_request: https://github.com/python/cpython/pull/17057

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37633>
_______________________________________

From report at bugs.python.org  Tue Nov  5 00:43:04 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Nov 2019 05:43:04 +0000
Subject: [issue38692] add a pidfd child process watcher
Message-ID: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:

Recent versions of Linux has built out support for pidfd, a way to do process management with file descriptors. I wanted to try it out, so implemented a pidfd-based child watcher for asyncio.

My WIP progress patch is attached. It passes all asyncio tests.

----------
components: asyncio
files: 0001-asyncio-Add-a-pidfd-child-process-watcher.patch
keywords: patch
messages: 356001
nosy: asvetlov, benjamin.peterson, yselivanov
priority: normal
severity: normal
status: open
title: add a pidfd child process watcher
type: enhancement
versions: Python 3.9
Added file: https://bugs.python.org/file48695/0001-asyncio-Add-a-pidfd-child-process-watcher.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 00:43:45 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Nov 2019 05:43:45 +0000
Subject: [issue38591] Deprecate Process Child Watchers
In-Reply-To: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>
Message-ID: <1572932625.03.0.654814196387.issue38591@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

FWIW, I started implementing a pidfd-based child process watcher over on #38692.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38591>
_______________________________________

From report at bugs.python.org  Tue Nov  5 00:53:02 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 05 Nov 2019 05:53:02 +0000
Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not
 exported in python38.dll
In-Reply-To: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org>
Message-ID: <1572933182.67.0.55979269733.issue37633@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4c22e1665c4d8e8fa31bd7aa7b403480d9be5ce2 by Miss Islington (bot) in branch '3.8':
closes bpo-37633: Re?xport some function compatibility wrappers for macros in ``pythonrun.h``. (GH-17056)
https://github.com/python/cpython/commit/4c22e1665c4d8e8fa31bd7aa7b403480d9be5ce2


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37633>
_______________________________________

From report at bugs.python.org  Tue Nov  5 01:19:40 2019
From: report at bugs.python.org (paul j3)
Date: Tue, 05 Nov 2019 06:19:40 +0000
Subject: [issue38590] argparse unexpected behavior with argument group inside
 mutually exclusive group
In-Reply-To: <1572027184.79.0.23480523249.issue38590@roundup.psfhosted.org>
Message-ID: <1572934780.6.0.735306954679.issue38590@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

With one exception, groups are not designed or intended to be nested.  But by inheritance (from _ActionsContainer) nesting isn't blocked nor does it raise any errors.

As you surmise, an ArgumentGroup, is used only for grouping the help lines.  By default that are two groups, with 'optionals' and 'required' names (actually the later should be 'positional').  The rest are user defined.  They don't affect parsing in any way.

MutuallyExclusiveGroup is used in parsing.  It also is used, to the extent possible, when formatting usage.

If a MutuallyExclusiveGroup is nested inside another MutuallyExclusiveGroup the parsing effect is just one flat group.  Usage can be messed up - that's been the subject of another bug/issue.

A MutuallyExclusiveGroup may be put in an ArgumentGroup.  This is a way of giving the exclusive group a title and/or description in the help.

There is a bug/issue requesting some sort of inclusive group.  I tried to develop such a patch, implementing nesting, complete logic control (not just the current xor).  But the usage formatting needs a complete rewrite.  Overall this is too complex of an addition.  On StackOverFlow I tell people to implement their own post-parsing testing.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38590>
_______________________________________

From report at bugs.python.org  Tue Nov  5 01:20:17 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 05 Nov 2019 06:20:17 +0000
Subject: [issue38693] Use f-strings instead of str.format within importlib
Message-ID: <1572934817.34.0.695862725726.issue38693@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

importlib is full of str.format calls, modernizing it to use f-strings is a slight performance win and much more readable.

----------
assignee: gregory.p.smith
messages: 356005
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Use f-strings instead of str.format within importlib
type: performance
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38693>
_______________________________________

From report at bugs.python.org  Tue Nov  5 01:23:51 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 05 Nov 2019 06:23:51 +0000
Subject: [issue38693] Use f-strings instead of str.format within importlib
In-Reply-To: <1572934817.34.0.695862725726.issue38693@roundup.psfhosted.org>
Message-ID: <1572935031.08.0.232477166028.issue38693@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38693>
_______________________________________

From report at bugs.python.org  Tue Nov  5 02:04:46 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 05 Nov 2019 07:04:46 +0000
Subject: [issue38694] docs.python.org does not switch version properly
Message-ID: <1572937486.73.0.254978147517.issue38694@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

1. open https://docs.python.org/3.8/whatsnew/3.8.html
2. choose dev (3.9)
3. 3.9 whats news should be shown but still showing 3.8

----------
assignee: docs at python
components: Documentation
messages: 356006
nosy: corona10, docs at python
priority: normal
severity: normal
status: open
title: docs.python.org does not switch version properly
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38694>
_______________________________________

From report at bugs.python.org  Tue Nov  5 02:11:42 2019
From: report at bugs.python.org (pascalhofmann)
Date: Tue, 05 Nov 2019 07:11:42 +0000
Subject: [issue38655] ipaddress.ip_network('0.0.0.0/0').is_private == True
In-Reply-To: <1572530691.84.0.462430681921.issue38655@roundup.psfhosted.org>
Message-ID: <1572937902.25.0.593899052487.issue38655@roundup.psfhosted.org>


pascalhofmann <mail at pascalhofmann.de> added the comment:

0.0.0.0/0 is a network with addresses from 0.0.0.0 to 255.255.255.255.
0.0.0.0/8 is a network with addresses from 0.0.0.0 to 0.255.255.255.

So 4278190080 out of 4294967296 addresses in 0.0.0.0/0 clearly are no private addresses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38655>
_______________________________________

From report at bugs.python.org  Tue Nov  5 02:23:24 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Nov 2019 07:23:24 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1572938604.85.0.675598153566.issue38689@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since isinstance(Object.__call__, types.MethodType) is False, the 'fob' in 'inspect.signature(fob)' is Object.  (See the initial get_argspec code.)  Indeed, 'inspect.signature(Object)' results in the traceback following inspect.signature(fob) and 'isinstance(Object, types.MethodType)' results in the last line thereof.  Not returning 'False' strikes me as maybe a bug in 'isinstance'.  Have you opened a report for this?  

Directly importing and executing  idlelib code is not supported (its is 'private'), but entering 'Object(' to cause IDLE to make the same call is.  And the result is worse than the exception.  The IDLE gui process hangs, waiting for the response from the socket connection to the user code process that never comes.  This is clearly a bug, regardless of whether the user code is buggy.

The relevant section of get_argspec is

    try:
        argspec = str(inspect.signature(fob))
    except ValueError as err:
        msg = str(err)
        if msg.startswith(_invalid_method):
            return _invalid_method

Signature() is documented as returning either ValueError or TypeError, and with the 'bug' in isinstance, others are possible.  So any error should be caught.  (The default of falling through and checking for a docstring signature is correct.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38689>
_______________________________________

From report at bugs.python.org  Tue Nov  5 02:39:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Nov 2019 07:39:37 +0000
Subject: [issue38695] IDLE should restart instead of hanging when subprocess
 exits
Message-ID: <1572939577.48.0.797512840286.issue38695@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

This is a spinoff from #38689, about 'strange_callable(' in Shell hanging, because there is an uncaught exception is the run process.  (See issue for 'strange_callable'.)  Running IDLE from Windows Command Prompt, Windows eventually shows the circle cursor.  Clicking on the window turns it gray and trying to close it by clicking 'X' brings up 'Python is not responding' with options to Wait, Close, or Try to Restore.  I have seen this before with other code.

Restore results in the GUI process RESTARTing a run process and the following in the console.

Exception in Tkinter callback
Traceback (most recent call last):
  File "f:\dev\3x\lib\idlelib\rpc.py", line 359, in pollpacket
    s = self.sock.recv(BUFSIZE)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "f:\dev\3x\lib\idlelib\rpc.py", line 432, in pollresponse
    message = self.pollmessage(wait)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 384, in pollmessage
    packet = self.pollpacket(wait)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 361, in pollpacket
    raise EOFError
EOFError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "f:\dev\3x\lib\tkinter\__init__.py", line 1885, in __call__
    return self.func(*args)
  File "f:\dev\3x\lib\idlelib\multicall.py", line 176, in handler
    r = l[i](event)
  File "f:\dev\3x\lib\idlelib\calltip.py", line 51, in try_open_calltip_event
    self.open_calltip(False)
  File "f:\dev\3x\lib\idlelib\calltip.py", line 70, in open_calltip
    argspec = self.fetch_tip(expression)
  File "f:\dev\3x\lib\idlelib\calltip.py", line 95, in fetch_tip
    return rpcclt.remotecall("exec", "get_the_calltip",
  File "f:\dev\3x\lib\idlelib\rpc.py", line 219, in remotecall
    return self.asyncreturn(seq)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 248, in asyncreturn
    response = self.getresponse(seq, wait=0.05)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 291, in getresponse
    response = self._getresponse(myseq, wait)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 311, in _getresponse
    response = self.pollresponse(myseq, wait)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 436, in pollresponse
    self.handle_EOF()
  File "f:\dev\3x\lib\idlelib\pyshell.py", line 389, in handle_EOF
    raise EOFError
EOFError

(Close, after confirmation, results in nothing except the Windows > prompt.)

This suggests to me that the remote process running idlelib.run should have an outer try-except that catches everything and sends "I am stopping" before exiting.  The GUI process would then RESTART a new subprocess.  There are conditions under which this already happens, so it seems that the current trigger just needs to be broadened.

----------
assignee: terry.reedy
components: IDLE
messages: 356009
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE should restart instead of hanging when subprocess exits
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38695>
_______________________________________

From report at bugs.python.org  Tue Nov  5 02:55:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Nov 2019 07:55:42 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1572940542.14.0.0949870788622.issue38689@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Further experiments suggest a fix for the hang, which is not specific to this example.  See new issue #38695.

----------
stage:  -> test needed
type:  -> behavior
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38689>
_______________________________________

From report at bugs.python.org  Tue Nov  5 03:28:30 2019
From: report at bugs.python.org (Damien LEFEVRE)
Date: Tue, 05 Nov 2019 08:28:30 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
In-Reply-To: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>
Message-ID: <1572942510.91.0.403477769239.issue38680@roundup.psfhosted.org>


Damien LEFEVRE <lefevre.da at gmail.com> added the comment:

I see the same problem.

We call python functions from C++ and use this locking class within each call:

'''
#pragma once
#ifdef _DEBUG
    #undef _DEBUG
    #include <Python.h>
    #define _DEBUG
#else
    #include <Python.h>
#endif // _DEBUG

#include "gcc_helper.h"

GCC_DIAG_OFF(maybe-uninitialized)

class GIL_lock
{
public:
    GIL_lock()
    {
        m_wasPreviouslyLockedByThisThread = PyGILState_Check() == 1;

        // If already locked, we shouldn't lock again.
        if (m_wasPreviouslyLockedByThisThread == false)
        {
            m_state = PyGILState_Ensure();
        }
    }

    ~GIL_lock()
    {
        release();
    }

    void release()
    {
        // Release only if it wasn't locked previously and wasn't released during lifetime.
        if (m_released == false && m_wasPreviouslyLockedByThisThread == false)
        {
            PyGILState_Release(m_state);
        }

        m_released = true;
    }

private:
    PyGILState_STATE m_state;
    bool m_released = false;
    bool m_wasPreviouslyLockedByThisThread = false;
};
'''

Example:
'''
void PythonInterpreterPrivate::setPythonHome(const QString& path)
{
    GIL_lock gilLock;

#ifdef _WIN32
    wchar_t* pyHome = new wchar_t[MAX_PATH];
#else
    wchar_t* pyHome = new wchar_t[PATH_MAX];
#endif
    QDir pythonDir(path);

    if (pythonDir.exists())
    {
        path.toWCharArray(pyHome);
        pyHome[path.size()] = 0;
        Py_SetPythonHome(pyHome);
    }
}
'''

With Python3.6, the first instance of GIL_lock in the main thread goes to PyGILState_Ensure(). With Python3.7, still in the main thread PyGILState_Check() reports the lock is already taken while we don't take it.

In a new thread, with Python3.7 GIL_lock() goes to PyGILState_Ensure() and deadlocks there. With Python3.6 PyGILState_Ensure() returns the state.

----------
nosy: +Damien LEFEVRE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Tue Nov  5 04:00:14 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Nov 2019 09:00:14 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
In-Reply-To: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>
Message-ID: <1572944414.86.0.916920536427.issue38680@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't think this is a bug:

- PyGILState_Ensure() acquires the GIL when it is not already acquired (and can be called without checking).  

It cannot acquire the GIL when some other thread has already taken the GIL, but wait until the GIL is released.  The GIL will get released periodically when running Python code.  

If the thread holding the GIL is primarily running native code that doesn't use the Python API it should release the GIL (for example by bracketing the long-running C code with Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS)


- PyGILState_Release() restores the state from before the call to PyGILState_Ensure().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Tue Nov  5 04:51:07 2019
From: report at bugs.python.org (Stojan Jovic)
Date: Tue, 05 Nov 2019 09:51:07 +0000
Subject: [issue38696] HTTP modules documentation error
Message-ID: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>


New submission from Stojan Jovic <condor.js at gmail.com>:

I have found error in "Usage" section of HTTP modules documentation page, specifically line:
http.HTTPStatus.OK.value
should be fixed to:
HTTPStatus.OK.value
according to the import and other usage examples.

----------
assignee: docs at python
components: Documentation
messages: 356013
nosy: docs at python, stojan.jovic
priority: normal
severity: normal
status: open
title: HTTP modules documentation error
type: resource usage
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Tue Nov  5 04:56:02 2019
From: report at bugs.python.org (Stojan Jovic)
Date: Tue, 05 Nov 2019 09:56:02 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1572947762.88.0.558694381924.issue38696@roundup.psfhosted.org>


Stojan Jovic <condor.js at gmail.com> added the comment:

Page link:
https://docs.python.org/3/library/http.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Tue Nov  5 05:17:54 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Nov 2019 10:17:54 +0000
Subject: [issue38694] docs.python.org does not switch version properly
In-Reply-To: <1572937486.73.0.254978147517.issue38694@roundup.psfhosted.org>
Message-ID: <1572949074.98.0.029653937706.issue38694@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

That is working as designed because a particular release version of the Python docset contains the What's New documents of previous versions.  So when you use the version switcher to move from 3.8 to 3.9, you are now looking at the 3.8 What's New in the 3.9 docset.  To see the 3.9 What's New, you can then click on the Table of Contents in the left-hand tab and click on the 3.9 What's New.

----------
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38694>
_______________________________________

From report at bugs.python.org  Tue Nov  5 05:35:29 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 05 Nov 2019 10:35:29 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572950129.13.0.606214322207.issue38692@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Awesome!

I think the patch can be splitted in os.pidfd_open() and asyncio part itself.

os modification is clear.

asyncio part looks correct after the brief view. 
My the main question is: how to detect if the new watcher can be used or asyncio should fallback to threaded based solution?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 05:36:51 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 05 Nov 2019 10:36:51 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572950211.79.0.195241974359.issue38692@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Nathaniel, you may be interested in the pidfd_open(), at least in adding the function to os module.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 05:47:25 2019
From: report at bugs.python.org (Damien LEFEVRE)
Date: Tue, 05 Nov 2019 10:47:25 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
In-Reply-To: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>
Message-ID: <1572950845.0.0.1997358447.issue38680@roundup.psfhosted.org>


Damien LEFEVRE <lefevre.da at gmail.com> added the comment:

@ronaldoussoren

The issue here is that the behavior between Python 3.6 and 3.7 has changed.

Our code runs perfectly fine with 3.6. We release the lock each time our functions get out of scope and so we know for sure there is no lock left behind.

Starting with 3.7 GIL is acquired when we start the application, but not by us, maybe internally?, and never gets released; thus the deadlock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Tue Nov  5 05:49:07 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Nov 2019 10:49:07 +0000
Subject: [issue38690] Command line option with &/or without a space results in
 the same outcome
In-Reply-To: <1572912256.03.0.374020363309.issue38690@roundup.psfhosted.org>
Message-ID: <1572950947.78.0.945999930066.issue38690@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

That's an interesting question.  There is much prior art here dating back to the earliest days of Unix.  The Open Group Base Specification has a section dealing with the syntax of utility arguments with suggestions of when or when not a space between the option and the option argument is needed and how to document the difference, i.e.

[-c option_argument] vs [-f[option_argument]]
 
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_01

It looks like the Python man page already sort of uses this syntax but the Python Setup and Usage doc may have different conventions.  If someone wants to pursue this, they might check all the options and provide a PR with any needed updates to the man page and the doc page.  A change in behavior of the command option processing is probably not a good idea at this point unless there is some demonstrable error or ambiguity.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, ned.deily
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38690>
_______________________________________

From report at bugs.python.org  Tue Nov  5 05:58:52 2019
From: report at bugs.python.org (Wei-Cheng Pan)
Date: Tue, 05 Nov 2019 10:58:52 +0000
Subject: [issue38608] Undocumented behavior that IsolatedAsyncioTestCase would
 enable event loop debug mode
In-Reply-To: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>
Message-ID: <1572951532.64.0.182732204485.issue38608@roundup.psfhosted.org>


Wei-Cheng Pan <legnaleurc at gmail.com> added the comment:

Executing <Handle <TaskWakeupMethWrapper object at 0x10b31ec10>(<Future finis...events.py:418>) created at /.../lib/python3.8/asyncio/queues.py:70> took 0.104 seconds
Executing <Handle <TaskWakeupMethWrapper object at 0x10b31e9d0>(<Future finis...events.py:418>) created at /.../lib/python3.8/asyncio/queues.py:70> took 0.121 seconds

I was expecting it can display the stack of the awaitable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38608>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:00:27 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Nov 2019 11:00:27 +0000
Subject: [issue38662] Decouple ensurepip from pip's internals using runpy
In-Reply-To: <1572629064.24.0.519341934772.issue38662@roundup.psfhosted.org>
Message-ID: <1572951627.08.0.00218421202038.issue38662@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Can you explain how this would be rolled out?  Does this mean as of a planned release of pip the current ensurepip would break?  If so, when?  Is 2.7 still supported with that version of pip and, if so, have you tested the PR with it?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38662>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:01:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 11:01:25 +0000
Subject: [issue38697] test.support.find_unused_port() race condition:
 test_socket fails with OSError: [Errno 98] Address already in use
Message-ID: <1572951685.78.0.141334829591.issue38697@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

When two tests using support.find_unused_port() run in parallel, it's possible to get the same port number and so the first process using it wins, and the other one fails. Example with test_socket running in parallel of multiple many other tests.

Example of fix to avoid support.find_unused_port():

diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
index 1bf562a03d..4479a69943 100644
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -6202,10 +6202,11 @@ class CreateServerFunctionalTest(unittest.TestCase):
                      "dualstack_ipv6 not supported")
     @unittest.skipUnless(support.IPV6_ENABLED, 'IPv6 required for this test')
     def test_dual_stack_client_v6(self):
-        port = support.find_unused_port()
-        with socket.create_server(("", port), family=socket.AF_INET6,
+        with socket.create_server(("", 0), family=socket.AF_INET6,
                                   dualstack_ipv6=True) as sock:
             self.echo_server(sock)
+            port = sock.getsockname()[1]
+            print("PORT", port)
             self.echo_client(("::1", port), socket.AF_INET6)


AMD64 RHEL7 Refleaks 3.8:
https://buildbot.python.org/all/#/builders/299/builds/48

0:02:32 load avg: 7.37 [132/423] test_timeout passed (56.5 sec) -- running: test_regrtest (1 min 56 sec), test_logging (1 min 17 sec), test_mailbox (1 min 39 sec), test_statistics (33.8 sec), test_socket (55.8 sec)
...
0:02:56 load avg: 8.33 [153/423] test_urllib2net passed -- running: test_regrtest (2 min 20 sec), test_logging (1 min 40 sec), test_mailbox (2 min 2 sec), test_statistics (57.4 sec), test_socket (1 min 19 sec)
...
0:03:11 load avg: 8.30 [161/423] test_asyncore passed -- running: test_logging (1 min 55 sec), test_support (33.7 sec), test_mailbox (2 min 17 sec), test_statistics (1 min 12 sec), test_socket (1 min 34 sec)
...
0:03:24 load avg: 8.01 [167/423] test_support passed (46.7 sec) -- running: test_mailbox (2 min 31 sec), test_multiprocessing_forkserver (40.2 sec), test_socket (1 min 47 sec)
...
0:03:36 load avg: 7.78 [180/423] test_docxmlrpc passed -- running: test_decimal (30.7 sec), test_mailbox (2 min 42 sec), test_multiprocessing_forkserver (52.1 sec), test_socket (1 min 59 sec)
...
0:03:39 load avg: 7.88 [184/423/1] test_socket failed (2 min 2 sec) -- running: test_decimal (33.9 sec), test_mailbox (2 min 46 sec), test_multiprocessing_forkserver (55.2 sec)
...
0:03:39 load avg: 7.88 [184/423/1] test_socket failed (2 min 2 sec) -- running: test_decimal (33.9 sec), test_mailbox (2 min 46 sec), test_multiprocessing_forkserver (55.2 sec)
beginning 6 repetitions
123456
....

Warning -- threading._dangling was modified by test_socket
  Before: {<weakref at 0x7f08b2b48830; to '_MainThread' at 0x7f08b73a8140>}
  After:  {<weakref at 0x7f08b07258f0; to 'Thread' at 0x7f08aefb6a00>, <weakref at 0x7f08b07257d0; to 'Thread' at 0x7f08aefb6b40>, <weakref at 0x7f08b07259b0; to '_MainThread' at 0x7f08b73a8140>, <weakref at 0x7f08b0725710; to 'Thread' at 0x7f08aefb6be0>} 

test test_socket failed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.refleak/build/Lib/test/test_socket.py", line 6206, in test_dual_stack_client_v6
    with socket.create_server(("", port), family=socket.AF_INET6,
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.refleak/build/Lib/socket.py", line 886, in create_server
    raise error(err.errno, msg) from None
OSError: [Errno 98] Address already in use (while attempting to bind on address ('', 45626))

----------
components: Tests
messages: 356022
nosy: vstinner
priority: normal
severity: normal
status: open
title: test.support.find_unused_port() race condition: test_socket fails with OSError: [Errno 98] Address already in use
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38697>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:04:31 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Nov 2019 11:04:31 +0000
Subject: [issue38683] Installation failed - no privileges to access directory
In-Reply-To: <1572865376.09.0.193791469521.issue38683@roundup.psfhosted.org>
Message-ID: <1572951871.51.0.154613801094.issue38683@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38683>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:05:11 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 05 Nov 2019 11:05:11 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572951911.49.0.350411593981.issue38285@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

My point is: without a deep understanding we cannot "just enable" a new protocol.
The evidence that it works in some limited scenarios is not enough for opening the can of worms.
It is true for seqpacket, and especially true for other even not discussed protocols in general.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:08:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 11:08:16 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572952096.94.0.596621333107.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I like the idea of exposing pidfd_open() syscall as os.pidfd_open().

Benjamin: Would you mind to create a PR based on your patch, but without your asyncio change?

> +#ifndef __NR_pidfd_open

I would prefer to avoid this part of the patch.

You should accept an optional flags parameter, no?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:09:55 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 05 Nov 2019 11:09:55 +0000
Subject: [issue38608] Undocumented behavior that IsolatedAsyncioTestCase would
 enable event loop debug mode
In-Reply-To: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>
Message-ID: <1572952195.98.0.602568568125.issue38608@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks for the clarification.
I forgot about this thing; the output can be improved sure.
As a workaround you can use the following hack::

import asyncio.task
asyncio.task.Task = asyncio.task._PyTask

IIRC the pure python version prints a coroutine name at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38608>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:11:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 11:11:07 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572952267.73.0.65917771745.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

+        self._loop._remove_reader(pidfd)
+        os.close(pidfd)

Note: Maybe do these operations in the reverse order. I expect a higher risk of exception when calling Python self._loop._remove_reader(), than on closing a FD that we opened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:11:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 11:11:18 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572952278.2.0.923047666377.issue38692@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:12:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 11:12:09 +0000
Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not
 exported in python38.dll
In-Reply-To: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org>
Message-ID: <1572952329.0.0.923414833761.issue37633@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> closes bpo-37633: Re?xport some function compatibility wrappers for macros in ``pythonrun.h``. (GH-17056)

Aha, finally more diversity of languages in commit messages! :-D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37633>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:20:09 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 05 Nov 2019 11:20:09 +0000
Subject: [issue38608] Undocumented behavior that IsolatedAsyncioTestCase would
 enable event loop debug mode
In-Reply-To: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>
Message-ID: <1572952809.77.0.124375901731.issue38608@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I've assigned myself to never forget about the issue; if somebody wants to fix _CTask and TaskWakeupMethWrapper representation -- you are welcome

----------
assignee:  -> asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38608>
_______________________________________

From report at bugs.python.org  Tue Nov  5 06:23:37 2019
From: report at bugs.python.org (Wei-Cheng Pan)
Date: Tue, 05 Nov 2019 11:23:37 +0000
Subject: [issue38608] Undocumented behavior that IsolatedAsyncioTestCase would
 enable event loop debug mode
In-Reply-To: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>
Message-ID: <1572953017.54.0.814619743736.issue38608@roundup.psfhosted.org>


Wei-Cheng Pan <legnaleurc at gmail.com> added the comment:

I cannot import asyncio.task, so I did this instead:

import asyncio.tasks
asyncio.tasks.Task = asyncio.tasks._PyTask

Then it changed to this:

Executing <Task pending name='Task-1' coro=<IsolatedAsyncioTestCase._asyncioLoopRunner() running at /.../lib/python3.8/unittest/async_case.py:96> wait_for=<Future pending cb=[Task.__wakeup()] created at /.../lib/python3.8/asyncio/base_events.py:418> created at /.../lib/python3.8/unittest/async_case.py:118> took 0.187 seconds

I suppose this means the entire test case is slow?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38608>
_______________________________________

From report at bugs.python.org  Tue Nov  5 08:03:28 2019
From: report at bugs.python.org (Nikita Hoffmann)
Date: Tue, 05 Nov 2019 13:03:28 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
Message-ID: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>


New submission from Nikita Hoffmann <hoffmann.nikita at gmail.com>:

Parsing an invalid email message id can throw a header parser error. A bug in parse_message_ still tries to append the unset token to a variable.

File "/opt/python-3.8.0/lib/python3.8/email/_header_value_parser.py", line 2116, in parse_message_
id
    message_id.append(token)
UnboundLocalError: local variable 'token' referenced before assignment

Version 3.7 is not affected.

----------
components: email
messages: 356030
nosy: Nikita Hoffmann, barry, r.david.murray
priority: normal
severity: normal
status: open
title: While parsing email message id: UnboundLocalError
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38698>
_______________________________________

From report at bugs.python.org  Tue Nov  5 08:05:26 2019
From: report at bugs.python.org (Pradyun Gedam)
Date: Tue, 05 Nov 2019 13:05:26 +0000
Subject: [issue38662] Decouple ensurepip from pip's internals using runpy
In-Reply-To: <1572951627.08.0.00218421202038.issue38662@roundup.psfhosted.org>
Message-ID: <CAPA-EqsPQ+snzPSF5pY9-SUMDj4gdHyrkP0N91QqR5j68JLZ0w@mail.gmail.com>


Pradyun Gedam <pradyunsg at gmail.com> added the comment:

On Tue, 5 Nov 2019 at 4:30 PM, Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily <nad at python.org> added the comment:
>
> Can you explain how this would be rolled out?

This, as in? If you're referring to this specific change, I don't think
there's anything special needed for this change (it's backwards compatible
with past pip releases, but that doesn't matter).

ensurepip only installs the bundled wheel it already has, into the
environment. Thus, existing ensurepip releases won't be broken.

However, when we bump up to pip 19.3 [1], we'd need to be updating the
invocation since it's using a pip internal and pip's internals can change
without notice even in a patch version.

This change ensures that ensurepip is robust to changes in the location of
pip's main function, thus making those updates as simple as a bundled wheel
change.

[1]: IIUC we try to keep CPython's bundled wheel in sync with latest)

Does this mean as of a planned release of pip the current ensurepip would
> break?

Yes. pip 19.3 made a change and as can be seen in the PR for that (sorry,
it's a GitHub PR and my internet is ridiculously slow right now).

  If so, when?

That's already been released. ?

Is 2.7 still supported with that version of pip and, if so, have you tested
> the PR with it?

Yes, pip will support 2.7 at least until CPython does (and likely longer).

>
> ----------
> nosy: +ned.deily
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38662>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38662>
_______________________________________

From report at bugs.python.org  Tue Nov  5 08:07:36 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Nov 2019 13:07:36 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1572959256.31.0.0706228071958.issue38698@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Can you please attach a sample script to reproduce this error?

----------
nosy: +maxking, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38698>
_______________________________________

From report at bugs.python.org  Tue Nov  5 08:09:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Nov 2019 13:09:29 +0000
Subject: [issue38693] Use f-strings instead of str.format within importlib
In-Reply-To: <1572934817.34.0.695862725726.issue38693@roundup.psfhosted.org>
Message-ID: <1572959369.58.0.277423298476.issue38693@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38693>
_______________________________________

From report at bugs.python.org  Tue Nov  5 08:36:16 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 05 Nov 2019 13:36:16 +0000
Subject: [issue38159] PyState_AddModule docs should say that it's not
 necessary to call it.
In-Reply-To: <1568381139.47.0.152206625825.issue38159@roundup.psfhosted.org>
Message-ID: <1572960976.36.0.197748166076.issue38159@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4342af00d87de0a0d0ef3bfda4d6edb08ac2427a by Miss Islington (bot) in branch '3.7':
[3.7] bpo-38159: Clarify documentation of PyState_AddModule (GH-16101) (GH-17027)
https://github.com/python/cpython/commit/4342af00d87de0a0d0ef3bfda4d6edb08ac2427a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38159>
_______________________________________

From report at bugs.python.org  Tue Nov  5 09:12:57 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 05 Nov 2019 14:12:57 +0000
Subject: [issue38159] PyState_AddModule docs should say that it's not
 necessary to call it.
In-Reply-To: <1568381139.47.0.152206625825.issue38159@roundup.psfhosted.org>
Message-ID: <1572963177.13.0.0974435713633.issue38159@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1270d2cf1d17bfa581bf2a19f82c8cb43bf793d9 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-38159: Clarify documentation of PyState_AddModule (GH-16101) (GH-17026)
https://github.com/python/cpython/commit/1270d2cf1d17bfa581bf2a19f82c8cb43bf793d9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38159>
_______________________________________

From report at bugs.python.org  Tue Nov  5 09:23:18 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Nov 2019 14:23:18 +0000
Subject: [issue38495] print built-in function docs bug
In-Reply-To: <1571211401.15.0.283514863374.issue38495@roundup.psfhosted.org>
Message-ID: <1572963798.85.0.700686319261.issue38495@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38495>
_______________________________________

From report at bugs.python.org  Tue Nov  5 09:25:35 2019
From: report at bugs.python.org (=?utf-8?q?Malvers=C3=A1n?=)
Date: Tue, 05 Nov 2019 14:25:35 +0000
Subject: [issue38285] Asyncio BaseEventLoop can support socket types other
 than SOCK_STREAM
In-Reply-To: <1569499511.98.0.234005447809.issue38285@roundup.psfhosted.org>
Message-ID: <1572963935.21.0.841032814041.issue38285@roundup.psfhosted.org>


Malvers?n <malverspam at gmail.com> added the comment:

I agree. Your question about potential message size overflow should be tested (either for recv() and recvmsg()).

Could you please link the resource where you found the recommendation of using recvmsg() over recv() for SOCK_SEQ_PACKET?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38285>
_______________________________________

From report at bugs.python.org  Tue Nov  5 09:28:42 2019
From: report at bugs.python.org (Nikita Hoffmann)
Date: Tue, 05 Nov 2019 14:28:42 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1572964122.95.0.456643011221.issue38698@roundup.psfhosted.org>


Change by Nikita Hoffmann <hoffmann.nikita at gmail.com>:


Added file: https://bugs.python.org/file48696/samplescript.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38698>
_______________________________________

From report at bugs.python.org  Tue Nov  5 09:45:24 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Nov 2019 14:45:24 +0000
Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not
 exported in python38.dll
In-Reply-To: <1572952329.0.0.923414833761.issue37633@roundup.psfhosted.org>
Message-ID: <1a4b5a9d-ffac-454a-86ee-1546e8b75d0a@www.fastmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Tue, Nov 5, 2019, at 03:12, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
> > closes bpo-37633: Re?xport some function compatibility wrappers for macros in ``pythonrun.h``. (GH-17056)
> 
> Aha, finally more diversity of languages in commit messages! :-D

This kind of orthography is allowable if obscure in English. https://en.wikipedia.org/wiki/Diaeresis_(diacritic)#English

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37633>
_______________________________________

From report at bugs.python.org  Tue Nov  5 09:45:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 14:45:47 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
Message-ID: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Currently, socket.socket.listen() called with no argument limits the default backlog to 128:

    /* We try to choose a default backlog high enough to avoid connection drops
     * for common workloads, yet not too high to limit resource usage. */
    int backlog = Py_MIN(SOMAXCONN, 128);

I just saw an article suggesting to use 4096 instead:
https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

On my Fedora 30, listen() manual page says:

       The  behavior of the backlog argument on TCP sockets changed with Linux
       2.2.  Now it specifies the  queue  length  for  completely  established
       sockets  waiting  to  be  accepted, instead of the number of incomplete
       connection requests.  The maximum length of the  queue  for  incomplete
       sockets  can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog.  When
       syncookies are enabled there is no logical maximum length and this set?
       ting is ignored.  See tcp(7) for more information.

       If    the   backlog   argument   is   greater   than   the   value   in
       /proc/sys/net/core/somaxconn, then it is  silently  truncated  to  that
       value;  the  default  value  in  this  file  is 128.  In kernels before
       2.4.25, this limit was a hard coded value, SOMAXCONN,  with  the  value
       128.

Python 3.8 new socket.create_server() calls sock.listen() by default: so use Py_MIN(SOMAXCONN, 128) by default.

----------
components: Library (Lib)
messages: 356037
nosy: giampaolo.rodola, vstinner
priority: normal
severity: normal
status: open
title: socket: change listen() default backlog from 128 to 4096?
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38699>
_______________________________________

From report at bugs.python.org  Tue Nov  5 09:47:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 14:47:51 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
In-Reply-To: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>
Message-ID: <1572965271.54.0.670757196454.issue38699@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I just saw an article suggesting to use 4096 instead:

In fact, it's a change in the Linux kernel directly proposed by Eric Dumazet (Google) for Linux kernel 5.5:
https://lore.kernel.org/netdev/20191030163620.140387-1-edumazet at google.com/

The change has already been merged upstream:

/* Maximum queue length specifiable by listen.  */
#define SOMAXCONN	4096

https://github.com/torvalds/linux/blob/a99d8080aaf358d5d23581244e5da23b35e340b9/include/linux/socket.h#L265

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38699>
_______________________________________

From report at bugs.python.org  Tue Nov  5 10:14:56 2019
From: report at bugs.python.org (Arunkumar Mani)
Date: Tue, 05 Nov 2019 15:14:56 +0000
Subject: [issue38700] typo in unittest mock docs
Message-ID: <1572966896.92.0.264576167113.issue38700@roundup.psfhosted.org>


New submission from Arunkumar Mani <aruntonic at gmail.com>:

at various places in the docs for unittest mock[https://docs.python.org/3.7/library/unittest.mock.html#magic-mock], assert is wriiten as assret

----------
assignee: docs at python
components: Documentation
messages: 356039
nosy: Arunkumar Mani, docs at python
priority: normal
severity: normal
status: open
title: typo in unittest mock docs
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38700>
_______________________________________

From report at bugs.python.org  Tue Nov  5 10:24:28 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Nov 2019 15:24:28 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572967468.95.0.482220416277.issue38692@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +16571
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17063

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 10:44:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Nov 2019 15:44:23 +0000
Subject: [issue38700] typo in unittest mock docs
In-Reply-To: <1572966896.92.0.264576167113.issue38700@roundup.psfhosted.org>
Message-ID: <1572968663.61.0.848282448747.issue38700@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please add the specific piece of text? There is an illustration to say that it's common mistake to type assret instead of assert with which mock gives a new child mock. This can be made stricter with unsafe mode to detect this typo.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38700>
_______________________________________

From report at bugs.python.org  Tue Nov  5 10:48:39 2019
From: report at bugs.python.org (Serge Matveenko)
Date: Tue, 05 Nov 2019 15:48:39 +0000
Subject: [issue38701] datetime.timedelta string representation is ambiguous
Message-ID: <1572968919.3.0.316665305196.issue38701@roundup.psfhosted.org>


New submission from Serge Matveenko <serge at matveenko.ru>:

Negative `timedelta` string representation is ambiguous.

```
>>> from datetime import datetime, timedelta
>>> d2 = datetime.now()
>>> d1 = d2 - timedelta(days=42, seconds=5)
>>> str(d2 - d1)
'42 days, 0:00:05'
>>> str(d1 - d2)
'-43 days, 23:59:55'
```

I would expect `str(d1 - d2)` to be one of the following:
* '-42 days, 0:00:05'
* '-(42 days, 0:00:05)'
* '- 42 days, 0:00:05'

----------
components: Library (Lib)
messages: 356041
nosy: lig
priority: normal
severity: normal
status: open
title: datetime.timedelta string representation is ambiguous
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38701>
_______________________________________

From report at bugs.python.org  Tue Nov  5 10:55:06 2019
From: report at bugs.python.org (Arunkumar Mani)
Date: Tue, 05 Nov 2019 15:55:06 +0000
Subject: [issue38700] typo in unittest mock docs
In-Reply-To: <1572966896.92.0.264576167113.issue38700@roundup.psfhosted.org>
Message-ID: <1572969306.48.0.75518421687.issue38700@roundup.psfhosted.org>


Arunkumar Mani <aruntonic at gmail.com> added the comment:

my bad. i misread the docs. you are right

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38700>
_______________________________________

From report at bugs.python.org  Tue Nov  5 10:59:28 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 05 Nov 2019 15:59:28 +0000
Subject: [issue35381] posixmodule: convert statically allocated types
 (DirEntryType & ScandirIteratorType) to heap-allocated types
In-Reply-To: <1543818839.39.0.788709270274.issue35381@psf.upfronthosting.co.za>
Message-ID: <1572969568.85.0.981484674897.issue35381@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b3966639d28313809774ca3859a347b9007be8d2 by Miss Islington (bot) (Eddie Elizondo) in branch 'master':
bpo-35381 Remove all static state from posixmodule (GH-15892)
https://github.com/python/cpython/commit/b3966639d28313809774ca3859a347b9007be8d2


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35381>
_______________________________________

From report at bugs.python.org  Tue Nov  5 11:01:54 2019
From: report at bugs.python.org (Pete Wicken)
Date: Tue, 05 Nov 2019 16:01:54 +0000
Subject: [issue38655] ipaddress.ip_network('0.0.0.0/0').is_private == True
In-Reply-To: <1572530691.84.0.462430681921.issue38655@roundup.psfhosted.org>
Message-ID: <1572969714.45.0.965975763162.issue38655@roundup.psfhosted.org>


Pete Wicken <petewicken at gmail.com> added the comment:

Looks like this happens because the is_private method that gets called is from _BaseNetwork, which checks if the network address '0.0.0.0' and the broadcast address '255.255.255.255' are both private, which they are as 0.0.0.0 falls into 0.0.0.0/8.

I think for this to get it right, you would have to change the is_private check for networks to iterate over each possible subnet and check if that is in the private networks list. This takes an unfeasibly long time.

So, we would probably have to add special cases for these networks, unless people have better ideas.

----------
nosy: +Wicken

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38655>
_______________________________________

From report at bugs.python.org  Tue Nov  5 11:53:52 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 05 Nov 2019 16:53:52 +0000
Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org>
Message-ID: <1572972832.29.0.481985361017.issue37645@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bf17d41826a8bb4bc1e34ba6345da98aac779e41 by Miss Islington (bot) (Jeroen Demeyer) in branch 'master':
bpo-37645: add new function _PyObject_FunctionStr() (GH-14890)
https://github.com/python/cpython/commit/bf17d41826a8bb4bc1e34ba6345da98aac779e41


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37645>
_______________________________________

From report at bugs.python.org  Tue Nov  5 11:54:18 2019
From: report at bugs.python.org (Joshua Root)
Date: Tue, 05 Nov 2019 16:54:18 +0000
Subject: [issue38360] single-argument form of -isysroot should be supported
In-Reply-To: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>
Message-ID: <1572972858.28.0.880114442157.issue38360@roundup.psfhosted.org>


Joshua Root <josh+python at root.id.au> added the comment:

Ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38360>
_______________________________________

From report at bugs.python.org  Tue Nov  5 11:59:46 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Nov 2019 16:59:46 +0000
Subject: [issue38701] datetime.timedelta string representation is ambiguous
In-Reply-To: <1572968919.3.0.316665305196.issue38701@roundup.psfhosted.org>
Message-ID: <1572973186.83.0.179929625921.issue38701@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38701>
_______________________________________

From report at bugs.python.org  Tue Nov  5 12:31:33 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 05 Nov 2019 17:31:33 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572975093.0.0.628840164698.issue38692@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Thanks for the CC.

It would be nice to get `pidfd_send_signal` as well, while we're at it. But that could be a separate PR.

AFAICT the other bits of the pidfd API right now are some extra flags to clone, and an extra flag to waitid. The waitid flag is nice-to-have but not really urgent, since it's easy enough to use a flag even if the stdlib doesn't explicitly expose it. The clone flags are super interesting, but before we can use them, we need to have some way to access clone itself, and that's a big complicated project, so we definitely shouldn't worry about it here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 12:35:00 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Nov 2019 17:35:00 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572975300.64.0.333205648575.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, I will be submitting followup changes for pidfd_send_signal and the other goodies.

I would like to use pidfds in subprocess, but as you as you say, that's another kettle of fish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 13:04:07 2019
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 05 Nov 2019 18:04:07 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
In-Reply-To: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>
Message-ID: <1572977047.28.0.315260033162.issue38699@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Just for some more reference points from "production" python web servers:

* gunicorn - 2048 (https://github.com/benoitc/gunicorn/blob/678b326dc030b450717ec505df69863dcd6fb716/docs/source/settings.rst#backlog)

* tornado - 128 (https://github.com/tornadoweb/tornado/blob/c50aed0f96d92f9b0ef4cd0837c0104f140ca77e/tornado/tcpserver.py#L178)

* uwsgi - 100 (https://github.com/unbit/uwsgi/blob/3149df02ed443131c54ea6afb29fcbb0ed4d1139/core/init.c#L115)

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38699>
_______________________________________

From report at bugs.python.org  Tue Nov  5 13:17:06 2019
From: report at bugs.python.org (Julin)
Date: Tue, 05 Nov 2019 18:17:06 +0000
Subject: [issue38702] Adding new types to parser/unparse.py
Message-ID: <1572977826.42.0.982480683243.issue38702@roundup.psfhosted.org>


New submission from Julin <julinshaji02 at gmail.com>:

The parser/unparse.py file lacks functions to handle the `Str`, `Num`, `Bytes` and `NameConstant` types.

Can we add them since it seems to be simple enough?

----------
components: Demos and Tools
messages: 356050
nosy: ju-sh
priority: normal
severity: normal
status: open
title: Adding new types to parser/unparse.py
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38702>
_______________________________________

From report at bugs.python.org  Tue Nov  5 13:21:24 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Nov 2019 18:21:24 +0000
Subject: [issue38702] Adding new types to parser/unparse.py
In-Reply-To: <1572977826.42.0.982480683243.issue38702@roundup.psfhosted.org>
Message-ID: <1572978084.86.0.978618856224.issue38702@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

These types are obsolete. The compiler never generates an AST tree containing them.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38702>
_______________________________________

From report at bugs.python.org  Tue Nov  5 13:26:38 2019
From: report at bugs.python.org (Julin)
Date: Tue, 05 Nov 2019 18:26:38 +0000
Subject: [issue38702] Adding new types to parser/unparse.py
In-Reply-To: <1572977826.42.0.982480683243.issue38702@roundup.psfhosted.org>
Message-ID: <1572978398.8.0.72504931036.issue38702@roundup.psfhosted.org>


Julin <julinshaji02 at gmail.com> added the comment:

Okay. 

But can lines like

    if first:first = False
    else: self.write(", ")

be changed to span across more number of lines?

Because things like

    first:first

looks like a type hint.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38702>
_______________________________________

From report at bugs.python.org  Tue Nov  5 13:55:28 2019
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 05 Nov 2019 18:55:28 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1572980128.13.0.989327065462.issue16575@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
pull_requests: +16572
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17064

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Tue Nov  5 13:58:02 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Nov 2019 18:58:02 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1572980282.44.0.811818526799.issue38691@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Tue Nov  5 13:58:13 2019
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 05 Nov 2019 18:58:13 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1572980293.44.0.602655349165.issue16575@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Opened https://github.com/python/cpython/pull/17064 to fix this. Essentially it's a tiny little oversight in the back-porting. In the 3.7 branch, we perform an attribute lookup for `from_param` before the union checking code, so we must remember to DECREF it. This is unlike master where the attribute lookup happens after the union checking code.



? win32\python_d.exe -m test -R 3:3 test_ctypes
0:00:00 Run tests sequentially
0:00:00 [1/1] test_ctypes
beginning 6 repetitions
123456
......

== Tests result: SUCCESS ==

1 test OK.

Total duration: 14.8 sec
Tests result: SUCCESS

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Tue Nov  5 14:53:04 2019
From: report at bugs.python.org (Yudong Liu)
Date: Tue, 05 Nov 2019 19:53:04 +0000
Subject: [issue38703] should we expect round(0.95, 1) to be 1.0,
 instead of 0.9?
Message-ID: <1572983584.27.0.706501027569.issue38703@roundup.psfhosted.org>


New submission from Yudong Liu <michael_chnc at hotmail.com>:

Python 3.7.0 (default, Aug 22 2018, 20:50:05) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> round(0.95,1)
0.9
>>> round(0.95)
1
>>> round(0.96,1)
1.0

----------
components: Library (Lib)
messages: 356054
nosy: yudongliu
priority: normal
severity: normal
status: open
title: should we expect round(0.95,1) to be 1.0, instead of 0.9?
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38703>
_______________________________________

From report at bugs.python.org  Tue Nov  5 14:54:38 2019
From: report at bugs.python.org (Arseniy)
Date: Tue, 05 Nov 2019 19:54:38 +0000
Subject: [issue38704] No `GetActiveProcessorCount` on Windows Vista
Message-ID: <1572983678.12.0.905160936522.issue38704@roundup.psfhosted.org>


New submission from Arseniy <senyai at gmail.com>:

This[https://www.python.org/downloads/windows/] page says "Note that Python 3.8.0 cannot be used on Windows XP or earlier.". I tried to install it on Windows Vista and got a message that `GetActiveProcessorCount` is missing from `KERNEL32.DLL`. This message appears when running python.exe.
I don't think anyone besides me cares about Vista, so I'd change the text to: "Note that Python 3.8.0 requires Windows 7 or later". It's more positive this way ;)

----------
messages: 356055
nosy: senyai
priority: normal
severity: normal
status: open
title: No `GetActiveProcessorCount` on Windows Vista
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38704>
_______________________________________

From report at bugs.python.org  Tue Nov  5 15:02:40 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 05 Nov 2019 20:02:40 +0000
Subject: [issue38693] Use f-strings instead of str.format within importlib
In-Reply-To: <1572934817.34.0.695862725726.issue38693@roundup.psfhosted.org>
Message-ID: <1572984160.31.0.593577884032.issue38693@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38693>
_______________________________________

From report at bugs.python.org  Tue Nov  5 15:08:27 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Nov 2019 20:08:27 +0000
Subject: [issue38703] should we expect round(0.95, 1) to be 1.0,
 instead of 0.9?
In-Reply-To: <1572983584.27.0.706501027569.issue38703@roundup.psfhosted.org>
Message-ID: <1572984507.12.0.889442479478.issue38703@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

0.95 is actually 278419646001971/4503599627370496 which is smaller than 95/100.

>>> from fractions import Fraction
>>> Fraction(0.95)
Fraction(4278419646001971, 4503599627370496)
>>> Fraction(0.95) - Fraction(95, 100)
Fraction(-1, 22517998136852480)

It is closer to 0.9 than to 1.0.

>>> Fraction(0.95) - Fraction(0.9)
Fraction(450359962737049, 9007199254740992)
>>> Fraction(1) - Fraction(0.95)
Fraction(225179981368525, 4503599627370496)
>>> (Fraction(1) - Fraction(0.95)) - (Fraction(0.95) - Fraction(0.9))
Fraction(1, 9007199254740992)

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38703>
_______________________________________

From report at bugs.python.org  Tue Nov  5 15:08:29 2019
From: report at bugs.python.org (Arseniy)
Date: Tue, 05 Nov 2019 20:08:29 +0000
Subject: [issue38704] No `GetActiveProcessorCount` on Windows Vista
In-Reply-To: <1572983678.12.0.905160936522.issue38704@roundup.psfhosted.org>
Message-ID: <1572984509.76.0.942999027518.issue38704@roundup.psfhosted.org>


Arseniy <senyai at gmail.com> added the comment:

just tested, CPython 3.7.5 Successfully runs on Windows Vista.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38704>
_______________________________________

From report at bugs.python.org  Tue Nov  5 15:25:55 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Nov 2019 20:25:55 +0000
Subject: [issue38704] No `GetActiveProcessorCount` on Windows Vista
In-Reply-To: <1572983678.12.0.905160936522.issue38704@roundup.psfhosted.org>
Message-ID: <1572985555.9.0.806379133034.issue38704@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Added our 3.8 RM to adjust the download page.

Steve, can or should we adjust the installer to refuse to install on Vista?  Is there other documentation we need to adjust?

----------
components: +Installation, Windows
nosy: +lukasz.langa, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38704>
_______________________________________

From report at bugs.python.org  Tue Nov  5 15:29:41 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Nov 2019 20:29:41 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
In-Reply-To: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>
Message-ID: <1572985781.21.0.194022109573.issue38680@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm afraid it will be close to impossible to determine what's going on without a reproducer. 

There's not enough context in the issue to understand the report, in particular what the main thread is doing and how that's releasing the GIL. 

BTW. The code in msg356011 is too complex, it can be simplified to:

// START

class GIL_lock
{
public:
    GIL_lock()
    {
        m_state = PyGILState_Ensure();
    }

    ~GIL_lock()
    {
       PyGILState_Release(m_state);
    }

private:
    PyGILState_STATE m_state;
};

// END

This is always safe, even if the thread currently owns the GIL. This will block when another thread owns the GIL, and will block forever when that other thread is not running Python code (and will therefore not release the GIL)

Is the problem also present with Python 3.8, or only 3.7? 

And for what it is worth, I don't have problems in my own code that uses these APIs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Tue Nov  5 15:39:34 2019
From: report at bugs.python.org (Pedro Lacerda)
Date: Tue, 05 Nov 2019 20:39:34 +0000
Subject: [issue22253] ConfigParser does not handle files without sections
In-Reply-To: <1408731768.17.0.221948826268.issue22253@psf.upfronthosting.co.za>
Message-ID: <1572986374.59.0.885451283234.issue22253@roundup.psfhosted.org>


Pedro Lacerda <pslacerda at gmail.com> added the comment:

Hi, there is a working PR at https://github.com/python/cpython/pull/2735. 

I was in doubt about get the default section with `__init__(..., allow_unnamed_section=True)` and `config.get('', 'option')` or with `config.get(DEFAULT_SECTION, 'option')`. I'd prefer the later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22253>
_______________________________________

From report at bugs.python.org  Tue Nov  5 15:58:06 2019
From: report at bugs.python.org (Den Delimarsky)
Date: Tue, 05 Nov 2019 20:58:06 +0000
Subject: [issue38705] venv creation on macOS Catalina is failing
Message-ID: <1572987486.08.0.312821972581.issue38705@roundup.psfhosted.org>


New submission from Den Delimarsky <me at den.dev>:

I have a project, where I am working inside a virtual environment (on macOS Catalina). Inside said project, I am attempting to create a new virtual environment with:

venv.create(virtual_environment_directory, with_pip=True)

This, however, errors out:

  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/user1/Documents/repos/adg/src/adg/__main__.py", line 35, in <module>
    CommandProcessor.validate(args, current_os)
  File "/Users/user1/Documents/repos/adg/src/adg/helpers/commandprocessor.py", line 21, in validate
    LibraryProcessor.process_libraries(command.library, command.platform, command.out)
  File "/Users/user1/Documents/repos/adg/src/adg/helpers/coreutil.py", line 79, in process_libraries
    LibraryInstaller.create_environment()
  File "/Users/user1/Documents/repos/adg/src/adg/helpers/coreutil.py", line 40, in create_environment
    venv.create(virtual_environment_directory, with_pip=True)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/venv/__init__.py", line 363, in create
    builder.create(env_dir)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/venv/__init__.py", line 68, in create
    self._setup_pip(context)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/venv/__init__.py", line 261, in _setup_pip
    subprocess.check_output(cmd, stderr=subprocess.STDOUT)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/subprocess.py", line 395, in check_output
    **kwargs).stdout
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/subprocess.py", line 487, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/Users/user1/Documents//repos/adg/src/dtemp/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' died with <Signals.SIGABRT: 6>.

Seems like attempting to run this both from inside and outside the virtual environment results in the error.

----------
components: macOS
messages: 356061
nosy: dend, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: venv creation on macOS Catalina is failing
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38705>
_______________________________________

From report at bugs.python.org  Tue Nov  5 16:05:54 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Nov 2019 21:05:54 +0000
Subject: [issue38609] Trashcan mechanism segfault during interpreter
 finalization in Python 3.7.5
In-Reply-To: <1572230692.1.0.462220822628.issue38609@roundup.psfhosted.org>
Message-ID: <1572987954.17.0.607782669591.issue38609@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached code creates a static (global) C++ object that owns a reference to a Python object, and releases that reference in its destructor. That destructor runs at program termination, which is after interpreter shutdown (that is after Py_FinalizeEx is called).  

After the call to Py_FinalizeEx() the interpreter no longer exists, and it is unsafe to call Python API functions (other than the ones listed as safe to call before a call to Py_Initialize).  Py_DECREF is not on that safe list.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38609>
_______________________________________

From report at bugs.python.org  Tue Nov  5 16:07:57 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Nov 2019 21:07:57 +0000
Subject: [issue38703] should we expect round(0.95, 1) to be 1.0,
 instead of 0.9?
In-Reply-To: <1572983584.27.0.706501027569.issue38703@roundup.psfhosted.org>
Message-ID: <1572988077.35.0.629623733744.issue38703@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What Serhiy said. round is behaving as intended and as designed here.

Note: you can also see the actual value of a float object easily by using Decimal:

    >>> from decimal import Decimal
    >>> Decimal(0.95)
    Decimal('0.9499999999999999555910790149937383830547332763671875')

... which demonstrates clearly that the value being rounded is closer to 0.9 than to 1.0.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38703>
_______________________________________

From report at bugs.python.org  Tue Nov  5 16:10:03 2019
From: report at bugs.python.org (Den Delimarsky)
Date: Tue, 05 Nov 2019 21:10:03 +0000
Subject: [issue38705] venv creation on macOS Catalina is failing
In-Reply-To: <1572987486.08.0.312821972581.issue38705@roundup.psfhosted.org>
Message-ID: <1572988203.06.0.668765545868.issue38705@roundup.psfhosted.org>


Den Delimarsky <me at den.dev> added the comment:

Should also mention that this is working as expected in Python 3.8.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38705>
_______________________________________

From report at bugs.python.org  Tue Nov  5 16:16:19 2019
From: report at bugs.python.org (Mikeli Karotsieri)
Date: Tue, 05 Nov 2019 21:16:19 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
Message-ID: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>


New submission from Mikeli Karotsieri <michael.karotsieris at gmail.com>:

The error messages included in the exceptions raised when assertTrue and assertFalse fail are respectively:  

'False is not true' 
'True is not false '

This issue's goal is to find out if it would be more correct or/and beneficial for those messages to be: 

'False is not True' 
'True is not False'

As a side note, the suggested error message is syntactically correct Python. 

The assosciated file is Lib/unittest/case.py .

----------
components: Library (Lib)
messages: 356065
nosy: brandtbucher, mkarotsieris
priority: normal
pull_requests: 16573
severity: normal
status: open
title: What should the error message in the exception raised by assertTrue and assertFalse be?
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Tue Nov  5 16:20:16 2019
From: report at bugs.python.org (Mikeli Karotsieri)
Date: Tue, 05 Nov 2019 21:20:16 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1572988816.91.0.0264414939112.issue38706@roundup.psfhosted.org>


Change by Mikeli Karotsieri <michael.karotsieris at gmail.com>:


----------
pull_requests:  -16573

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Tue Nov  5 16:20:47 2019
From: report at bugs.python.org (Mikeli Karotsieri)
Date: Tue, 05 Nov 2019 21:20:47 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1572988847.91.0.315242076878.issue38706@roundup.psfhosted.org>


Change by Mikeli Karotsieri <michael.karotsieris at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Tue Nov  5 16:28:45 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Nov 2019 21:28:45 +0000
Subject: [issue38705] venv creation on macOS Catalina is failing
In-Reply-To: <1572987486.08.0.312821972581.issue38705@roundup.psfhosted.org>
Message-ID: <1572989325.7.0.0130831282615.issue38705@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report but without a supplying a reproducible test case it's really difficult to say what issue you might be seeing. FWIW, I was not able to reproduce a failure but I was just guessing what your project code really does.  Also be aware that you appear to be using the Apple-supple Python 3.7.3 that is included with Apple's Xcode 11 Command Line Tools for 10.15 Catalina and is not part of a standard macOS installation.  I believe that Python3 is there only to support other parts of the Command Line Tools and it is not recommended that you use it for your own projects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38705>
_______________________________________

From report at bugs.python.org  Tue Nov  5 16:33:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Nov 2019 21:33:13 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1572989593.38.0.518738387995.issue38706@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

assertTrue() does not assert that the value is True. It asserts that it is true. For example, non-zero number or non-empty collections will pass the check.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Tue Nov  5 17:02:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 22:02:10 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572991330.26.0.000850198785874.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-38630 "subprocess.Popen.send_signal() should poll the process".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 17:07:22 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 05 Nov 2019 22:07:22 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572991642.53.0.478032431664.issue38692@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> My the main question is: how to detect if the new watcher can be used or asyncio should fallback to threaded based solution?

Perhaps in the __init__ we could do something like this:

class PidfdChildWatcher(AbstractChildWatcher):

    def __init__(self):
        if not hasattr(os, "pidfd_open"):
             raise RuntimeError("os.pidfd_open() is unavailable.")
        ...

Thoughts?

> My WIP progress patch is attached. It passes all asyncio tests.

I think we could also specifically look for race conditions with `./python -m test test_asyncio.test_subprocess -F -j4`, rather than relying on the tests passing with a single job. The other child watchers have been particularly infamous when it comes race conditions and resource leaks. 

I'd be glad to work on testing and opening a PR to asyncio if needed (while giving Benjamin credit for the patch of course).

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 17:36:39 2019
From: report at bugs.python.org (Jake Tesler)
Date: Tue, 05 Nov 2019 22:36:39 +0000
Subject: [issue36084] Threading: add builtin TID attribute to Thread objects
In-Reply-To: <1550875571.41.0.297490361597.issue36084@roundup.psfhosted.org>
Message-ID: <1572993399.63.0.877411584143.issue36084@roundup.psfhosted.org>


Change by Jake Tesler <jake.tesler at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36084>
_______________________________________

From report at bugs.python.org  Tue Nov  5 17:39:46 2019
From: report at bugs.python.org (Jake Tesler)
Date: Tue, 05 Nov 2019 22:39:46 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
Message-ID: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>


New submission from Jake Tesler <jake.tesler at gmail.com>:

I have encountered a minor bug with the new `threading.get_native_id()` featureset in Python 3.8. The bug occurs when creating a new multiprocessing.Process object on Unix (or on any platform where the multiprocessing start_method is 'fork' or 'forkserver').

When creating a new process via fork, the Native ID in the new MainThread is incorrect. The new forked process' threading.MainThread object inherits the Native ID from the parent process' MainThread instead of capturing/updating its own (new) Native ID.

See the following snippet:

>>> import threading, multiprocessing
>>> multiprocessing.set_start_method('fork') # or 'forkserver'
>>> def proc(): print(threading.get_native_id(), threading.main_thread().native_id) # get_native_id(), mainthread.native_id
>>> proc()
22605 22605 # get_native_id(), mainthread.native_id
>>> p = multiprocessing.Process(target=proc)
>>> p.start()
22648 22605 # get_native_id(), mainthread.native_id
>>>
>>> def update(): threading.main_thread()._set_native_id()
>>> def print_and_update(): proc(); update(); proc()
>>> print_and_update()
22605 22605 # get_native_id(), mainthread.native_id
22605 22605 
>>> p2=multiprocessing.Process(target=print_and_update); p2.start()
22724 22605 # get_native_id(), mainthread.native_id
22724 22724
>>> print_and_update()
22605 22605 # get_native_id(), mainthread.native_id
22605 22605

As you can see, the new Process object's MainThread.native_id attribute matches that of the MainThread of its parent process. 

Unfortunately, I'm not too familiar with the underlying mechanisms that Multiprocessing uses to create forked processes. 
I believe this behavior occurs because (AFAIK) a forked multiprocessing.Process copies the MainThread object from its parent process, rather than reinitializing a new one. Looking further into the multiprocessing code, it appears the right spot to fix this would be in the multiprocessing.Process.bootstrap() function. 

I've created a branch containing a working fix - I'm also open to suggestions of how a fix might otherwise be implemented. 
If it looks correct I'll create a PR against the CPython 3.8 branch. 

See the branch here: https://github.com/jaketesler/cpython/tree/fix-mp-native-id

Thanks all!
-Jake

----------
components: Library (Lib)
messages: 356070
nosy: jaketesler, vstinner
priority: normal
severity: normal
status: open
title: Multiprocessing: bug with Native ID for threading.mainthread()
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Tue Nov  5 17:39:52 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 05 Nov 2019 22:39:52 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572993592.49.0.0569756353814.issue38692@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

hasattr is useful for supporting old versions of the os module, but asyncio doesn't have to care about that. You should probably try calling pidfd_open and see whether you get -ESYSCALL, and also maybe try passing it to poll(), since I think there might have been a release where the syscall existed but it wasn't pollable. Not sure what the error for that looks like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 17:42:59 2019
From: report at bugs.python.org (Jake Tesler)
Date: Tue, 05 Nov 2019 22:42:59 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1572993779.08.0.607263228217.issue38707@roundup.psfhosted.org>


Change by Jake Tesler <jake.tesler at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Tue Nov  5 17:48:04 2019
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Tue, 05 Nov 2019 22:48:04 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
Message-ID: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>


New submission from Dimitri John Ledkov <dimitri.ledkov at canonical.com>:

email module has recently got parse_message_id which is more strict now, then before.

However, it's not programmed as defensively as expected. Given bogus message-id, it crashes with unbound local variable, or like accessing a non-existing index.

So hyperkitty had a Message-ID "X"*260 in the testsuite that used to pass with 3.7, but fails with 3.8.

======================================================================
ERROR: test_long_message_id (hyperkitty.tests.lib.test_incoming.TestAddToList)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./hyperkitty/tests/lib/test_incoming.py", line 295, in test_long_message_id
    msg["Message-ID"] = "X" * 260
  File "/usr/lib/python3.8/email/message.py", line 409, in __setitem__
    self._headers.append(self.policy.header_store_parse(name, val))
  File "/usr/lib/python3.8/email/policy.py", line 148, in header_store_parse
    return (name, self.header_factory(name, value))
  File "/usr/lib/python3.8/email/headerregistry.py", line 602, in __call__
    return self[name](name, value)
  File "/usr/lib/python3.8/email/headerregistry.py", line 197, in __new__
    cls.parse(value, kwds)
  File "/usr/lib/python3.8/email/headerregistry.py", line 530, in parse
    kwds['parse_tree'] = parse_tree = cls.value_parser(value)
  File "/usr/lib/python3.8/email/_header_value_parser.py", line 2116, in parse_message_id
    message_id.append(token)
UnboundLocalError: local variable 'token' referenced before assignment

Similarly another user, surkova reports that value[0] in get_msg_id function is buggy too (doesn't check that value has a member)

First reported https://github.com/python/cpython/pull/13397#discussion_r341968031

Ideally, I'd like the function to raise a documented Exception for invalid Message-id, but not fail with what look like regular programming bugs in the email module. Expectation is that email module is either more permissive or is coded more defence-in-depth with more checking in place.

----------
messages: 356072
nosy: xnox
priority: normal
severity: normal
status: open
title: parse_message_id in email module is very buggy / crashy
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38708>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:07:40 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 05 Nov 2019 23:07:40 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572995260.36.0.30336358649.issue38630@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

It sounds like there's actually nothing to do here? (Except maybe eventually switch to pidfd or similar, but Victor says he wants to use a different issue for that.) Can this be closed?

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:10:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 23:10:39 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572995439.63.0.260461992962.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It sounds like there's actually nothing to do here? (Except maybe eventually switch to pidfd or similar, but Victor says he wants to use a different issue for that.) Can this be closed?

I opened this issue to propose PR 16984. Did you notice the PR?

In short, I propose to call poll() before calling os.kill() in send_signal().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:12:49 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 05 Nov 2019 23:12:49 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572995569.05.0.899964057125.issue38630@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

But then deeper in the thread it sounded like you concluded that this didn't actually help anything, which is what I would expect :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:17:22 2019
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 05 Nov 2019 23:17:22 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1572995842.39.0.597612408788.issue38696@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:19:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 23:19:01 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572995941.04.0.837816923674.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> But then deeper in the thread it sounded like you concluded that this didn't actually help anything, which is what I would expect :-).

The PR contains a test which demonstrate one race condition. It fails  without the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:19:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 23:19:32 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1572995972.07.0.549572528758.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> (Except maybe eventually switch to pidfd or similar, but Victor says he wants to use a different issue for that.)

pidfd is not available on all platforms (ex: Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:29:43 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Nov 2019 23:29:43 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1572996583.15.0.735919527818.issue38696@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset 56698d57691af2272f695f8c17c835ed99545cde by Zachary Ware (Ammar Askar) in branch 'master':
bpo-38696: Fix usage example of HTTPStatus (GH-17066)
https://github.com/python/cpython/commit/56698d57691af2272f695f8c17c835ed99545cde


----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:30:05 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 05 Nov 2019 23:30:05 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1572996605.53.0.610078192139.issue38696@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Tue Nov  5 18:30:13 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 05 Nov 2019 23:30:13 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1572996613.41.0.381106098038.issue38696@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Tue Nov  5 19:05:45 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 00:05:45 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1572998745.13.0.715245278991.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

pidfd_open was added after pidfd pollling, so it should suffice to make sure pidfd_open doesn't ENOSYS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 19:15:16 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 06 Nov 2019 00:15:16 +0000
Subject: [issue38703] should we expect round(0.95, 1) to be 1.0,
 instead of 0.9?
In-Reply-To: <1572983584.27.0.706501027569.issue38703@roundup.psfhosted.org>
Message-ID: <1572999316.65.0.282566155421.issue38703@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Possibly even easier than using Decimal:

py> '%.17f' % 0.95
'0.94999999999999996'

BTW, this is a FAQ:

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38703>
_______________________________________

From report at bugs.python.org  Tue Nov  5 19:23:26 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 06 Nov 2019 00:23:26 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1572999806.56.0.651362173489.issue38706@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm reopening this as an enhancement, because I think Mikeli is onto something here. I'd like to propose making the messages:

    "False is not a truthy value."
    "True is not a falsey value."

to make it explicit that we are testing not for the singletons True and False by identity, but for any truthy or falsey value.

If you don't like the terms "truthy" and "falsey", lower-case true and false would also be acceptable.

----------
nosy: +steven.daprano
resolution: not a bug -> 
status: closed -> open
type:  -> enhancement
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Tue Nov  5 19:25:28 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 06 Nov 2019 00:25:28 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1572999928.21.0.886626924965.issue38706@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Since error messages aren't part of the API and backwards-compatibility doesn't apply to them, this could still go into 3.8.

----------
stage: resolved -> 
versions: +Python 3.8 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Tue Nov  5 19:26:54 2019
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 06 Nov 2019 00:26:54 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573000014.23.0.975760231932.issue38706@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

I like Steven's "truthy value" or "true value" proposal. Another alternative:

"x does not evaluate to true"
"x does not evaluate to false"

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Tue Nov  5 19:35:37 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 06 Nov 2019 00:35:37 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1573000537.54.0.818000458293.issue38630@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

You can't solve a time-of-check-to-time-of-use race by adding another check. I guess your patch might narrow the race window slightly, but it was a tiny window before and it's a tiny window after, so I don't really get it.

The test doesn't demonstrate a race condition. What it demonstrates is increased robustness against user code that corrupts Popen's internal state by reaping one of its processes behind its back.

That kind of robustness might be a good motivation on its own! (I actually just did a bunch of work to make trio more robust against user code closing fds behind its back, which is a similar kind of thing.) But it's a very different motivation than what you say in this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Tue Nov  5 19:43:48 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 06 Nov 2019 00:43:48 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1573001028.13.0.28225085185.issue38630@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Hmm, you know, on further thought, it is actually possible to close this race for real, without pidfd.

What you do is split 'wait' into two parts: first it waits for me process to become reapable without actually reaping it. On Linux you can do this with waitid+WNOWAIT. On kqueue platforms you can do it with kqueue.

Then, you take a lock, and use it to atomically call waitpid/waitid to reap the process + update self.returncode to record that you've done so.

In send_signal, we use the same lock to atomically check whether the process has been reaped, and then send the signal if it hasn't.

That doesn't fix your test, but it does fix the race condition: as long as users only interact with the process through the Popen API, it guarantees that send_signal will never rather the wrong process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Tue Nov  5 20:47:20 2019
From: report at bugs.python.org (Den Delimarsky)
Date: Wed, 06 Nov 2019 01:47:20 +0000
Subject: [issue38705] venv creation on macOS Catalina is failing
In-Reply-To: <1572987486.08.0.312821972581.issue38705@roundup.psfhosted.org>
Message-ID: <1573004840.62.0.726607692766.issue38705@roundup.psfhosted.org>


Den Delimarsky <me at den.dev> added the comment:

@ned.deily actually you bring up a very good point, I did not notice that it was using the default Catalina Python 3 install. I've chatted with @brett.cannon about this earlier and it seemed like the issue was in that the Python version I was using is no longer supported, with the fix likely being in one of the later branches. I've updated my installation from python.org and everything works as expected now. Let me know if you want me to close this issue, and thank you for your insights!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38705>
_______________________________________

From report at bugs.python.org  Tue Nov  5 22:21:43 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 03:21:43 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573010503.64.0.178721213252.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 6c4c45efaeb40f4f837570f57d90a0b3429c6ae9 by Benjamin Peterson in branch 'master':
bpo-38692: Add os.pidfd_open. (GH-17063)
https://github.com/python/cpython/commit/6c4c45efaeb40f4f837570f57d90a0b3429c6ae9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 22:23:58 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 03:23:58 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573010638.29.0.88342311235.issue38692@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +16578
pull_request: https://github.com/python/cpython/pull/17069

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov  5 22:49:12 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 03:49:12 +0000
Subject: [issue38709] distutils - setuptools - alias command removes comments
 from setup.cfg
Message-ID: <1573012152.1.0.450153006571.issue38709@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

The command 'alias' rewrites the configuration file completely when a new alias is added. The default file is 'setup.cfg'. All comments of the original file are stripped off before, though the new 'setup.cfg' does not contain any comments.

The comments should be kept literally, just the section '[aliases]' should be modified.

The comments in the section '[aliases]' should be basically kept, even though a manual modification by the user could cause problems e.g. in case of deleting an alias by the 'setup.py alias' command.

Anyhow, at least the only section modified should - must - be the '[aliases]' section.

Even though this involves 'setuptools', I write this issue here because of the tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' parameter.

I have tested 3.8.0, but as far as I can see this is the case for all releases.

----------
components: Distutils
messages: 356088
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils - setuptools - alias command removes comments from setup.cfg
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38709>
_______________________________________

From report at bugs.python.org  Tue Nov  5 23:04:15 2019
From: report at bugs.python.org (=?utf-8?q?Manuel_Ignacio_P=C3=A9rez_Alcolea?=)
Date: Wed, 06 Nov 2019 04:04:15 +0000
Subject: [issue38710] unsynchronized write pointer in io.TextIOWrapper in 'r+'
 mode
Message-ID: <1573013055.2.0.421780617853.issue38710@roundup.psfhosted.org>


New submission from Manuel Ignacio P?rez Alcolea <perezalcoleam at gmail.com>:

There seems to be a bug in the `io.TextIOWrapper` class while working in 'r+' mode, although I can't say the source of the problem is right there.

The write pointer doesn't match `file.tell()` after performing a read operation.

For example, this file, consisting of 3 lines:

  line one
  line two
  line three

Doesn't result in the expected modification running the following program:

with open('file', 'r+', buffering=1) as f:
    print(f.tell())                  # => 0
    print(f.readline().strip())      # we read 1 line
    print(f.tell())                  # => 9  
    print('Hello', file=f)           # we write "Hello\n"
    print(f.tell())                  # => 34

Instad of

  line one
  Hello
  wo
  line three

It results in

  line one
  line two
  line threeHello

But it works just fine if `f.seek(f.tell())` is added the program, right before the write operation.

There are several possible explanations on StackOverflow, involving the buffering for IO in text files:

https://stackoverflow.com/a/58722058/11601118

----------
components: IO
messages: 356089
nosy: Manuel Ignacio P?rez Alcolea
priority: normal
severity: normal
status: open
title: unsynchronized write pointer in io.TextIOWrapper in 'r+' mode
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38710>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:02:37 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 05:02:37 +0000
Subject: [issue38711] setup parameter 'distclass' ignored for configuration
 files
Message-ID: <1573016557.67.0.586139729549.issue38711@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

Even though this involves 'setuptools', I write this issue here because of the tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' parameter.

The central API 'setup()' - 'setuptools.init.setup()' - provides the parameter 'distclass=<distribution-class>'. This allows to define a custom 'Distribution' class to be used as a replacement of the 'Distribution' class.

First of all for an ordinary user it is not clear whether 'distutils.dist.Distribution', and/or 'setuptools.dist.Distribution' is replaced. Even more confusing, the 'self' parameter is cross-passed between the classes by using a derived instance provided by:

   _Distribution = get_unpatched(distutils.core.Distribution)

The second is the integration of the initialization bootstrap, which completely ignores the user defined custom class. The main API 'setup()' defined in 'setuptools.init.setup()' calls first the local private function '_install_setup_requires' - 'setuptools.init._install_setup_requires()', which calls the instanciates the hardcoded 'distutils.core.Distribution()', and therein calls the methods 'dist.parse_config_files()', and 'dist.fetch_build_eggs()', which - as far as I can see - finally prohibits the use of a custom version of these, or easily add another one.

The consequence is that the configuration file parameters could basically not be fully customized by the custom class.

The association with the parameter 'distclass' for me - and I guess for others too - is that the 'complete' 'Distribution' class could be customized by this API. But this is currently not possible. So, even though I see the problems that can arise from the use of the modified 'self' parameter - I would propose the application of the 'distclass' for the initial bootstrap by the read of the configuration file too. In case this prooves too risky - due to 'distutils' coupling with 'setuptools', at least a parameter for the initial read of the configuration files should be offered.


The best of course would be the fusion of both parts, probably in a future release.

I have tested 3.8.0, but as far as I can see this is the case for all releases.

PS: I am writing now another issue for the 'alias' command and going add the number as an possible example for the required custom class.

----------
components: Distutils
messages: 356090
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: setup parameter 'distclass' ignored for configuration files
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38711>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:08:47 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 05:08:47 +0000
Subject: [issue38712] add signal.pidfd_send_signal
Message-ID: <1573016926.97.0.785552850869.issue38712@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:

Add signal.pidfd_send_signal, which will wrap the Linux 5.1 syscall of the same name.

----------
components: Library (Lib)
messages: 356091
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: add signal.pidfd_send_signal
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38712>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:10:42 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 05:10:42 +0000
Subject: [issue38712] add signal.pidfd_send_signal
In-Reply-To: <1573016926.97.0.785552850869.issue38712@roundup.psfhosted.org>
Message-ID: <1573017042.06.0.452625108936.issue38712@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38712>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:12:25 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 05:12:25 +0000
Subject: [issue38712] add signal.pidfd_send_signal
In-Reply-To: <1573016926.97.0.785552850869.issue38712@roundup.psfhosted.org>
Message-ID: <1573017145.92.0.255358941478.issue38712@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38712>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:21:11 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 05:21:11 +0000
Subject: [issue38713] expose P_PIDFD
Message-ID: <1573017671.76.0.0466411119444.issue38713@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:

On Linux 5.4, P_PIDFD allows using waitid with a pidfd.

----------
components: Library (Lib)
messages: 356092
nosy: benjamin.peterson, njs
priority: normal
severity: normal
status: open
title: expose P_PIDFD
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38713>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:23:30 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 05:23:30 +0000
Subject: [issue38713] expose P_PIDFD
In-Reply-To: <1573017671.76.0.0466411119444.issue38713@roundup.psfhosted.org>
Message-ID: <1573017810.71.0.186565250132.issue38713@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38713>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:31:25 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 06 Nov 2019 05:31:25 +0000
Subject: [issue38712] add signal.pidfd_send_signal
In-Reply-To: <1573016926.97.0.785552850869.issue38712@roundup.psfhosted.org>
Message-ID: <1573018285.96.0.197727554046.issue38712@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

I guess a bikeshed question is whether it should be `os.pidfd_send_signal` (like `os.kill`) or `signal.pidfd_send_signal` (like `signal.pthread_kill`).

I don't actually care either way myself :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38712>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:33:35 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 05:33:35 +0000
Subject: [issue38714] setup command alias erroneous for names with hyphens
Message-ID: <1573018415.75.0.591711986593.issue38714@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

Even though this involves 'setuptools', I write this issue here because of the tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' parameter.

The aliases as represented by the command 'setup.py alias' are internally treated by 'setuptools' as options.

See code:

   setuptools.dist._parse_config_files()
   in Python-3.8.0:  line 604 - line 608

The consequence is the processing of the standard replacement of hyphens by underscores for alias names.

The resulting behaviour is here three folded.


1. The technical behaviour of the alias replacement for valid
   aliases id flawless.

2. The technical behaviour of the display representation for alias
   names containing a hyphen is erroneous.

   For example:

      python setup.py alias my-alias alias

   Results flawless in:

      [aliases]
      my-alias = alias

   The display:

      python setup.py alias

   is erroneous:

      (3.8.0)$ python setup.py alias
      running alias
      Command Aliases
      ---------------
      setup.py alias my_alias alias

   because the modified internal values are displayed - with replaced
   hyphens in alias names.


3. The call of the alias as command replacement is erroneous in general:

  3.0. the original call is flawless:

     (3.8.0)$ python setup.py alias

        running alias
        Command Aliases
        ---------------
        setup.py alias my_alias alias


  3.1. the call by defined literal alias is erroneous:

        (3.8.0)$ python setup.py my-alias

        invalid command name 'my-alias'

  3.2. the call by modified alias is also erroneous,
     as though the alias is not detected, resulting here in the
     display of an empty list:

        (3.8.0)$ python setup.py my_alias

        running alias
        Command Aliases
        ---------------


Another example to mention here is the acceptance of alias names including spaces, which prbably should be suppressed, because as far as I can see command name could not contain spaces at all.

E.g. the alias 'ls -l' is handeled erroneous in accordance to the previous remarks, but is basically not valid at all.

   (3.8.0)$ python setup.py 'ls -l' alias

Results in the flawless configuration entry:

   [aliases]
   ls -l = alias

The erroneous display:

    (3.8.0)$ python setup.py alias

    running alias
    Command Aliases
    ---------------
    setup.py alias ls _l alias

The behaviour should be fixed to be consistent to allow valid names and reject others. The accepted names should be fully functional, and displayed and made available for custom representation literally as provided by the user. A simple reverse-replacement is here not reliable.

The alternative of the caching of the original input is currently not possible for a simple public command API due to the lack of fully customization of the 'distclass' see issue Issue38711. Thus this seems currently to require a complete second scan including eventually selected user files as eventually selected by the provided call parameters.

----------
components: Distutils
messages: 356094
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: setup command alias erroneous for names with hyphens
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38714>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:33:52 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 05:33:52 +0000
Subject: [issue38714] setup command alias erroneous for names with hyphens
In-Reply-To: <1573018415.75.0.591711986593.issue38714@roundup.psfhosted.org>
Message-ID: <1573018432.6.0.865118720952.issue38714@roundup.psfhosted.org>


Change by Arno-Can Uestuensoez <acue.opensource at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38714>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:38:13 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 05:38:13 +0000
Subject: [issue38714] setup command alias erroneous for names with hyphens
In-Reply-To: <1573018415.75.0.591711986593.issue38714@roundup.psfhosted.org>
Message-ID: <1573018693.33.0.344948787098.issue38714@roundup.psfhosted.org>


Arno-Can Uestuensoez <acue.opensource at gmail.com> added the comment:

Current related issues are:

issue 38714
issue 38711
issue 38709

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38714>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:38:31 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 05:38:31 +0000
Subject: [issue38711] setup parameter 'distclass' ignored for configuration
 files
In-Reply-To: <1573016557.67.0.586139729549.issue38711@roundup.psfhosted.org>
Message-ID: <1573018711.92.0.00797546738121.issue38711@roundup.psfhosted.org>


Arno-Can Uestuensoez <acue.opensource at gmail.com> added the comment:

Current related issues are:

issue 38714
issue 38711
issue 38709

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38711>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:38:43 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 05:38:43 +0000
Subject: [issue38709] distutils - setuptools - alias command removes comments
 from setup.cfg
In-Reply-To: <1573012152.1.0.450153006571.issue38709@roundup.psfhosted.org>
Message-ID: <1573018723.95.0.354777746345.issue38709@roundup.psfhosted.org>


Arno-Can Uestuensoez <acue.opensource at gmail.com> added the comment:

Current related issues are:

issue 38714
issue 38711
issue 38709

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38709>
_______________________________________

From report at bugs.python.org  Wed Nov  6 00:58:38 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 06 Nov 2019 05:58:38 +0000
Subject: [issue38713] expose P_PIDFD
In-Reply-To: <1573017671.76.0.0466411119444.issue38713@roundup.psfhosted.org>
Message-ID: <1573019918.45.0.814168314832.issue38713@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5c0c325453a175350e3c18ebb10cc10c37f9595c by Miss Islington (bot) (Benjamin Peterson) in branch 'master':
closes bpo-38713: Expose P_PIDFD in os if it's defined. (GH-17071)
https://github.com/python/cpython/commit/5c0c325453a175350e3c18ebb10cc10c37f9595c


----------
nosy: +miss-islington
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38713>
_______________________________________

From report at bugs.python.org  Wed Nov  6 01:10:10 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 06 Nov 2019 06:10:10 +0000
Subject: [issue38684] hashlib: build fails when blake2 is disabled in OpenSSL
In-Reply-To: <1572870250.89.0.269143912742.issue38684@roundup.psfhosted.org>
Message-ID: <1573020610.93.0.130239845366.issue38684@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7c20888e71304ecbf4bd3d595f364b7c691d30a0 by Miss Islington (bot) in branch '3.8':
bpo-38684: haslib: fix build when Blake2 not enabled in OpenSSL (GH-17043)
https://github.com/python/cpython/commit/7c20888e71304ecbf4bd3d595f364b7c691d30a0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38684>
_______________________________________

From report at bugs.python.org  Wed Nov  6 01:14:43 2019
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Nov 2019 06:14:43 +0000
Subject: [issue38684] hashlib: build fails when blake2 is disabled in OpenSSL
In-Reply-To: <1572870250.89.0.269143912742.issue38684@roundup.psfhosted.org>
Message-ID: <1573020883.84.0.156530315534.issue38684@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38684>
_______________________________________

From report at bugs.python.org  Wed Nov  6 01:42:46 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 06:42:46 +0000
Subject: [issue38712] add signal.pidfd_send_signal
In-Reply-To: <1573016926.97.0.785552850869.issue38712@roundup.psfhosted.org>
Message-ID: <1573022566.61.0.358998263172.issue38712@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, I thought about that a bit. I choose signal because:

1. signal already has some specialized functions that send signals pthread_kill and raise_signal.
2. If we every do want to implement the third parameter of pidfd_send_signal, the signal module already defines a siginfo structseq.
3. (least convincing) os/posix has way too much stuff. I generally think that we should strive to find a good home for new OS-level functionality that isn't the os module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38712>
_______________________________________

From report at bugs.python.org  Wed Nov  6 02:12:13 2019
From: report at bugs.python.org (hetman)
Date: Wed, 06 Nov 2019 07:12:13 +0000
Subject: [issue38715] Regression in compileall ddir parameter when recursing
Message-ID: <1573024333.47.0.536430294956.issue38715@roundup.psfhosted.org>


New submission from hetman <hetmankp at outlook.com>:

There appears to have been a regression introduced in the compileall library back with Python 3.5 as a result of commit f1a8df0ac98 .

The issues appears when compiling a hierarchy of directories with the 'ddir' parameter specified (either in the compile_dir() function or via the '-d' command line parameter).

Examining the code before the f1a8df0ac98 commit suggests the original intent for the 'ddir' parameter, when recursing into subdirectories, was to alter the root of the path displayed in exception traces. That means that the hierarchical directory structure of the reported source path in each compiled file was maintained, and only the root directory being compiled was replaced with ddir.

More recently two new parameters, 'stripdir' and 'prependdir', have been added with commit 8e7bb991de7 which seem to largely reimplement the missing behaviour in a different way.

The current behaviour does not seem very useful or expected. I think it would be helpful to restore the original behaviour and would be happy to contribute a PR to do so. Additionally it may be worth consulting the submitter of bpo-38112 whether the alternative arguments are still necessary once the regression is fixed, though this is optional and not needed to fix the core issue.



Here's a simple script to demonstrate the above:

mkdir -p library/a/a

cat <<'EOF' > library/__init__.py
def go():
  raise AssertionError('dummy')
EOF
cp library/__init__.py library/a/__init__.py
cp library/__init__.py library/a/a/__init__.py

python3 -m compileall -b -d /usr/lib library
rm library/**/*.py

python3 -c 'from library import go; go()'
python3 -c 'from library.a import go; go()'
python3 -c 'from library.a.a import go; go()'



And the resulting output which shows that each module is claiming to be raised from the same location:

Listing 'library'...
Compiling 'library/__init__.py'...
Listing 'library/a'...
Compiling 'library/a/__init__.py'...
Listing 'library/a/a'...
Compiling 'library/a/a/__init__.py'...

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/__init__.py", line 2, in go
AssertionError: dummy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/__init__.py", line 2, in go
AssertionError: dummy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/__init__.py", line 2, in go
AssertionError: dummy

----------
components: Library (Lib)
messages: 356102
nosy: hetman
priority: normal
severity: normal
status: open
title: Regression in compileall ddir parameter when recursing
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38715>
_______________________________________

From report at bugs.python.org  Wed Nov  6 02:35:21 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Nov 2019 07:35:21 +0000
Subject: [issue38705] venv creation on macOS Catalina is failing
In-Reply-To: <1572987486.08.0.312821972581.issue38705@roundup.psfhosted.org>
Message-ID: <1573025721.9.0.934605696602.issue38705@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38705>
_______________________________________

From report at bugs.python.org  Wed Nov  6 03:07:31 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Nov 2019 08:07:31 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573027651.93.0.872201001142.issue38706@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am not English expert, but traditionally "true" is used as a synonym of a truthy value everywhere in the Python documentation and code. There are almost 2000 occurrences. If it is a wrong word, it should be fixed in all these cases.

----------
nosy: +ezio.melotti, michael.foord, r.david.murray, rbcollins, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 03:11:22 2019
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 06 Nov 2019 08:11:22 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573027882.94.0.0469563241312.issue38706@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

I don't think the word "true" is really the issue here. It's the fact that "is" in this context is ambiguous, is it referring to the English "is" or the python operator `is`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 03:15:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Nov 2019 08:15:41 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573028141.58.0.581208867224.issue38706@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There are almost 500 occurrences of "is true".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 03:28:47 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Nov 2019 08:28:47 +0000
Subject: [issue38715] Regression in compileall ddir parameter when recursing
In-Reply-To: <1573024333.47.0.536430294956.issue38715@roundup.psfhosted.org>
Message-ID: <1573028927.13.0.733737795638.issue38715@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38715>
_______________________________________

From report at bugs.python.org  Wed Nov  6 04:13:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Nov 2019 09:13:22 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1573031602.04.0.756341228686.issue38656@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It seems that there is a list of files from which the mime types are also added at https://github.com/python/cpython/blob/5c0c325453a175350e3c18ebb10cc10c37f9595c/Lib/mimetypes.py#L42. "video/x-matroska" is not present in CPython repo's list of suffixes so it should be inferring from the list of known files. Can you please run the below script on 3.7.4 and 3.7.5 on the same machine? I am using Mac and 3.7.4 and 3.7.5 report video/x-matroska correctly.

import mimetypes
print(mimetypes.guess_type('E01.mkv'))
print(mimetypes.types_map['.mkv'])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Wed Nov  6 04:35:12 2019
From: report at bugs.python.org (lorb)
Date: Wed, 06 Nov 2019 09:35:12 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
Message-ID: <1573032912.48.0.408728963846.issue38716@roundup.psfhosted.org>


New submission from lorb <ritzer.christoph at gmail.com>:

When subclassing the rotating handlers of the logging module and implementing a namer or rotator method they are silently set to None in __init__. This is surprising behaviour and currently the set a specific namer or rotator it is required to create an instance first and than set them.

----------
messages: 356107
nosy: lorb
priority: normal
severity: normal
status: open
title: logging: rotating handlers set namer and rotator null

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 04:39:40 2019
From: report at bugs.python.org (lorb)
Date: Wed, 06 Nov 2019 09:39:40 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573032912.48.0.408728963846.issue38716@roundup.psfhosted.org>
Message-ID: <1573033180.72.0.660823638306.issue38716@roundup.psfhosted.org>


Change by lorb <ritzer.christoph at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 04:45:31 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Nov 2019 09:45:31 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1573033531.83.0.305699202128.issue38698@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This was also reported in issue38708 with the original code added in issue35805. Commenting out the except clause also doesn't raise any error in test suite so I assume the code path was not tested. Maybe the script could be added as part of the test suite.

$ git diff
diff --git a/Lib/email/_header_value_parser.py b/Lib/email/_header_value_parser.py
index 1668b4a14e..9b6ca3a268 100644
--- a/Lib/email/_header_value_parser.py
+++ b/Lib/email/_header_value_parser.py
@@ -2110,10 +2110,10 @@ def parse_message_id(value):
     message_id = MessageID()
     try:
         token, value = get_msg_id(value)
+        message_id.append(token)
     except errors.HeaderParseError:
         message_id.defects.append(errors.InvalidHeaderDefect(
             "Expected msg-id but found {!r}".format(value)))
-    message_id.append(token)
     return message_id

 #

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38698>
_______________________________________

From report at bugs.python.org  Wed Nov  6 04:46:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Nov 2019 09:46:56 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
In-Reply-To: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>
Message-ID: <1573033616.48.0.970946626478.issue38708@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to be the same as issue38698.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38708>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:04:48 2019
From: report at bugs.python.org (=?utf-8?q?Patrick_Schneewei=C3=9F?=)
Date: Wed, 06 Nov 2019 10:04:48 +0000
Subject: [issue38717] csv DictWriter's internal _dict_to_list raise error
 unsupported operand
Message-ID: <1573034688.04.0.163382933915.issue38717@roundup.psfhosted.org>


New submission from Patrick Schneewei? <afflictorx at gmail.com>:

I switched over to Python 3.7 and still using my csv DictWriter.

No I'm receiving an error when calling the writerow() method. 
unsupported operand type(s) for -: 'list' and 'list'

Digging deeped in the problem I found out, that the internal _dict_to_list(self, rowdict) method works different compared to Python 2.7
It tries to substract the fieldnames list and the keys of the dict to find keys not included.

But substracting lists is not possible. As a workaround I defined the Dictwriter with the option extrasaction="ignore".

I would be better to use the method like in Python 2.7. I will output my versions of the method:

Python 3.7:
    def _dict_to_list(self, rowdict):
        if self.extrasaction == "raise":
            wrong_fields = rowdict.keys() - self.fieldnames
            if wrong_fields:
                raise ValueError("dict contains fields not in fieldnames: "
                                 + ", ".join([repr(x) for x in wrong_fields]))
        return (rowdict.get(key, self.restval) for key in self.fieldnames)

Python 2.7:
    def _dict_to_list(self, rowdict):
        if self.extrasaction == "raise":
            wrong_fields = [k for k in rowdict if k not in self.fieldnames]
            if wrong_fields:
                raise ValueError("dict contains fields not in fieldnames: "
                                 + ", ".join([repr(x) for x in wrong_fields]))
        return [rowdict.get(key, self.restval) for key in self.fieldnames]

----------
components: Library (Lib)
messages: 356110
nosy: afflictor
priority: normal
severity: normal
status: open
title: csv DictWriter's internal _dict_to_list raise error unsupported operand
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38717>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:23:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Nov 2019 10:23:36 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573035816.25.0.961354156221.issue38706@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +16583
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17073

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:30:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Nov 2019 10:30:38 +0000
Subject: [issue38717] csv DictWriter's internal _dict_to_list raise error
 unsupported operand
In-Reply-To: <1573034688.04.0.163382933915.issue38717@roundup.psfhosted.org>
Message-ID: <1573036238.89.0.632992524325.issue38717@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I guess you try to write not a dict, but an object whose keys() method returns a list.

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38717>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:35:10 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 06 Nov 2019 10:35:10 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573032912.48.0.408728963846.issue38716@roundup.psfhosted.org>
Message-ID: <1573036510.69.0.195234474956.issue38716@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The namer and rotator attributes are callables, not methods to be overridden. You can certainly do this with methods and set them accordingly:

class MyHandler(BaseRotatingHandler):
    def __init__(self, *args, **kwargs):
        super(MyHandler, self).__init__(*args, **kwargs)
        self.namer = self.my_namer
        self.rotator = self.my_rotator

    def my_namer(self, default_name):
        return default_name  # or whatever you want here

    def my_rotator(self, source, dest):
        os.rename(source, dest)  # or whatever you want here

Having namer and rotator be callables avoids the need to subclass a handler just to override naming and rotating functionality. So, I think this issue should be closed as "not a bug", and the corresponding PR closed. Thanks for your effort, though - I just think you may have misunderstood the intent of the design.

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:39:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Nov 2019 10:39:04 +0000
Subject: [issue38717] csv DictWriter's internal _dict_to_list raise error
 unsupported operand
In-Reply-To: <1573034688.04.0.163382933915.issue38717@roundup.psfhosted.org>
Message-ID: <1573036744.98.0.410943570306.issue38717@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please attach a sample script to reproduce the behavior difference? With below script a dictionary is passed then dict.keys() supports subtraction over a list to return the difference. I am not sure how you have received a list with dict.keys() in Python 3.7.

import csv

fields = ["c", "d"]
with open('test.csv', 'w') as f:
    writer = csv.DictWriter(f, fieldnames=fields, extrasaction='raise')
    writer.writeheader()
    writer.writerow({"n": 1})

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38717>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:41:00 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 06 Nov 2019 10:41:00 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573036860.39.0.0378111779544.issue38706@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I also feel that lower case true and false are synonymous with any truthy and falsey values, as I'm sure many others do, so things in this area should in general stay as they are. Certainly -1 for a search-and-replace approach!

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:44:36 2019
From: report at bugs.python.org (=?utf-8?q?Patrick_Schneewei=C3=9F?=)
Date: Wed, 06 Nov 2019 10:44:36 +0000
Subject: [issue38717] csv DictWriter's internal _dict_to_list raise error
 unsupported operand
In-Reply-To: <1573034688.04.0.163382933915.issue38717@roundup.psfhosted.org>
Message-ID: <1573037076.95.0.139923198616.issue38717@roundup.psfhosted.org>


Patrick Schneewei? <afflictorx at gmail.com> added the comment:

Hello all,

This is my dict:
{'rule': 'WAN-2-Web|unknown (Barracuda Networks CloudGen Firewall)', 'April (2018)': '', 'May (2018)': '', 'June (2018)': '', 'July (2018)': '', 'August (2018)': '', 'April (2019)': '', 'May (2019)': '14', 'June (2019)': '', 'July (2019)': '', 'August (2019)': ''}

And this was my fieldnames list:
['rule', 'April (2018)', 'May (2018)', 'June (2018)', 'July (2018)', 'August (2018)', 'April (2019)', 'May (2019)', 'June (2019)', 'July (2019)', 'August (2019)']


when I call the keys Method on this dict, I receive this:
dict_keys(['rule', 'April (2018)', 'May (2018)', 'June (2018)', 'July (2018)', 'August (2018)', 'April (2019)', 'May (2019)', 'June (2019)', 'July (2019)', 'August (2019)'])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38717>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:49:07 2019
From: report at bugs.python.org (=?utf-8?q?Patrick_Schneewei=C3=9F?=)
Date: Wed, 06 Nov 2019 10:49:07 +0000
Subject: [issue38717] csv DictWriter's internal _dict_to_list raise error
 unsupported operand
In-Reply-To: <1573034688.04.0.163382933915.issue38717@roundup.psfhosted.org>
Message-ID: <1573037347.26.0.955836473113.issue38717@roundup.psfhosted.org>


Patrick Schneewei? <afflictorx at gmail.com> added the comment:

Ok in a new sample Script it is working. 

As I used my normal script in a software called Splunk, I saw they are using a custom class OrderedDict.

I will take a look on this first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38717>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:52:19 2019
From: report at bugs.python.org (lorb)
Date: Wed, 06 Nov 2019 10:52:19 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573036510.69.0.195234474956.issue38716@roundup.psfhosted.org>
Message-ID: <CAEmRbkvetBeEOS_U9VxA+29u9T5MmGx_xSB2EeOp8a=U30ZYOA@mail.gmail.com>


lorb <ritzer.christoph at gmail.com> added the comment:

Thanks for the review and response. I don't understand yet why not to
allow the following while keeping the existing functionality. This
could also be achieved by turning the namer and rotator into class
attributes. I recently created a subclass of the timed rotating
handler where it is beneficial for the handler to be able to access to
self to use the rollover time in the naming.

class MyHandler(BaseRotatingHandler):
    def namer(self, default_name):
        return default_name  # or whatever you want here

    def rotator(self, source, dest):
        os.rename(source, dest)  # or whatever you want here

Am Mi., 6. Nov. 2019 um 11:35 Uhr schrieb Vinay Sajip <report at bugs.python.org>:
>
>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> The namer and rotator attributes are callables, not methods to be overridden. You can certainly do this with methods and set them accordingly:
>
> class MyHandler(BaseRotatingHandler):
>     def __init__(self, *args, **kwargs):
>         super(MyHandler, self).__init__(*args, **kwargs)
>         self.namer = self.my_namer
>         self.rotator = self.my_rotator
>
>     def my_namer(self, default_name):
>         return default_name  # or whatever you want here
>
>     def my_rotator(self, source, dest):
>         os.rename(source, dest)  # or whatever you want here
>
> Having namer and rotator be callables avoids the need to subclass a handler just to override naming and rotating functionality. So, I think this issue should be closed as "not a bug", and the corresponding PR closed. Thanks for your effort, though - I just think you may have misunderstood the intent of the design.
>
> ----------
> nosy: +vinay.sajip
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38716>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 05:54:10 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 06 Nov 2019 10:54:10 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573037650.63.0.295912891976.issue38706@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 06:05:04 2019
From: report at bugs.python.org (=?utf-8?q?Patrick_Schneewei=C3=9F?=)
Date: Wed, 06 Nov 2019 11:05:04 +0000
Subject: [issue38717] csv DictWriter's internal _dict_to_list raise error
 unsupported operand
In-Reply-To: <1573034688.04.0.163382933915.issue38717@roundup.psfhosted.org>
Message-ID: <1573038304.47.0.672999659555.issue38717@roundup.psfhosted.org>


Patrick Schneewei? <afflictorx at gmail.com> added the comment:

Sorry guys, it was an issue with the cusotm Splunk Library. They treated the keys Method a little different.

Thanks all for the hints.

Will close this

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38717>
_______________________________________

From report at bugs.python.org  Wed Nov  6 06:14:39 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 06 Nov 2019 11:14:39 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573032912.48.0.408728963846.issue38716@roundup.psfhosted.org>
Message-ID: <1573038879.33.0.632539143637.issue38716@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

They can be methods, but don't need to be. In my example, I showed how you can set the namer and rotator attributes to methods which do have access to self. I don't want to encourage the idea that namer and rotator *have* to be methods that have to be overridden. You can do this in your own code, but I don't especially want to encourage that way of doing things - which is why I specifically didn't make them (namer and rotator) methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 06:48:14 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 06 Nov 2019 11:48:14 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573040894.34.0.119271296265.issue38706@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I pretty strongly dislike 'truthy' and 'falsey'.  They look slangy and https://en.wiktionary.org/wiki/truthy gives the main meaning as 
  (US, colloquial) Only superficially true; ...

The computer language usage is credited to Javascript here and some other sites (with the same meaning as in Python).

To be a bit pedantic, the current failure message for assertTrue(x) appears to be f'{repr(x)} is not true'.

Exception messages are English phrases and sentences, not Python code, so 'is' in exception messages is always the English 'is', as in
  NameError: name 'true' is not defined
I do not see any ambiguity.  Somewhat ironically, the original suggestion 'False is not True', which should better be written '<x> is not True' *could* be misinterpreted as code.

'x does not evaluate to true' strikes me as wrong because in this context, the evaluation by calling bool(x) is to True or False, not 'true' or 'false'.

'assertTrue' is an abbreviation for something like 'assertBoolTrue(x)' or more properly, assert_bool(x)_is_True.  A correct failure message, correct both as English and Python, should be something like 'bool(x) is not True'.  I see 'x is not true' as an informal English equivalent of the full claim.  Perhaps this should be better explained somewhere in the doc.  I do not really see 'x is not a true value' as adding anything.

We don't usually change exception messages in bugfix releases unless the message is buggy, as in actively misleading.  I also think making a change would need discussion on pydev.

----------
nosy:  -eric.smith, vinay.sajip
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 06:55:05 2019
From: report at bugs.python.org (lorb)
Date: Wed, 06 Nov 2019 11:55:05 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573038879.33.0.632539143637.issue38716@roundup.psfhosted.org>
Message-ID: <CAEmRbkvRd+TP7JLSQBdcVQD0F8+2pxZA-x+HTBZRYUjkBSz6yA@mail.gmail.com>


lorb <ritzer.christoph at gmail.com> added the comment:

This PR certainly does not turn them into methods. I believe it also
doesn't encourage the idea that they would have to be. All it does is
preventing __init__ from setting them to None in the case they are
defined as methods. Would you consider it more acceptable to just turn
them into class level attributes of BaseRotatingHandler instead of
setting them in init?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 07:07:59 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 12:07:59 +0000
Subject: [issue38718] query of global options delivers error messages even
 when successful
Message-ID: <1573042079.22.0.765143606638.issue38718@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

The 'setup.py' interface offers some global options, which could be queried. For example among numerous others the 'classifiers'.

The current implementation displays for example for the following call::

   python setup.py --description

The result::

  (3.8.0) $ python setup.py --description
   <description-text>
   usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
      or: setup.py --help [cmd1 cmd2 ...]
      or: setup.py --help-commands
      or: setup.py cmd --help

   error: no commands supplied
   (3.8.0) $ echo $?
   1
   (3.8.0) $


I would like to propose some minor enhancements here.

1. The error message is here an error itself, because the
   query was flawless successful.

   This is due to the implementation by relying on an
   exception for the termination condition, when no
   command was given. This is for the global query options
   for the global metadata perfectly allright.

   Thus the error message must not occur.

2. The resulting exit code of '1' is due to the same execption
   for the missing command.

   Thus the exit code must be '0' on Posix based and alike
   systems.

3. The usage message, which is also based on a private method,
   is basically an error itself. This is due to the fact, that
   actually nothing has failed.

   Thus the usage message must not be displayed here.

4. I also would like to propose some layout enhancements at
   this occasion.

   The  value of the queried attribute - here the description,
   should be separated by a <CR>.
   E.g. by 'USAGE', or 'global_+usage()' within 'distutils.core'.

   The resulting layout and exit value  would be:

      (3.8.0) $ python setup.py --description

      <description-text>

      (3.8.0) $ echo $?
      0
      (3.8.0) $

----------
components: Distutils
messages: 356122
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: query of global options delivers error messages even when successful
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38718>
_______________________________________

From report at bugs.python.org  Wed Nov  6 07:11:27 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 12:11:27 +0000
Subject: [issue38718] query of global metadata options delivers error messages
 even when successful
In-Reply-To: <1573042079.22.0.765143606638.issue38718@roundup.psfhosted.org>
Message-ID: <1573042287.05.0.289455082382.issue38718@roundup.psfhosted.org>


Change by Arno-Can Uestuensoez <acue.opensource at gmail.com>:


----------
title: query of global options delivers error messages even when successful -> query of global metadata options delivers error messages even when successful

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38718>
_______________________________________

From report at bugs.python.org  Wed Nov  6 07:22:07 2019
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Wed, 06 Nov 2019 12:22:07 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
In-Reply-To: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>
Message-ID: <1573042927.4.0.483633531311.issue38708@roundup.psfhosted.org>


Dimitri John Ledkov <dimitri.ledkov at canonical.com> added the comment:

Yes, issue38698 covers the UnboundLocalError,

but doesn't cover inside get_msg_id there is also this gem:

    def get_msg_id(value):
        msg_id = MsgID()
        if value[0] in CFWS_LEADER:

It should test value before accessing value[0] like it is done in other places, ie.:

    if value and value[0] in CFWS_LEADER:

or indent the whole block to iterate over value with:

    while value:
        ...

which also tests that value has [0] index.

I guess I want to repurpose this issue for the value[0] indexerror in get_msg_id().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38708>
_______________________________________

From report at bugs.python.org  Wed Nov  6 07:47:21 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 06 Nov 2019 12:47:21 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573044441.58.0.959920712873.issue38706@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I have tried sending this message by email twice, and both times it seems to have disappeared. So I'm commenting via the web, and my apologies in advance if the message shows up later.

*****

> There are almost 500 occurrences of "is true".

We can worry about them if and when somebody raises them as a "bug
report" or feature request. Without reading each one in context, I have
no idea whether they are good, bad or indifferent. Doing a massive
search and replace would be a bad idea.

Right now we have a simple feature request: improve the assertTrue and
assertFalse messages. There is a simple way to improve them. We don't
have to touch any other message, just these two.

Personally, I prefer "truthy and falsey" or "true-like and false-like"
over "true and false" to distinguish between "duck-typed bools" and the
actual bool singletons True and False. But I don't prefer them enough to
fight over the terms. If you prefer "true and false", that's okay with
me too :-)

"False is not true" suggests to the user that the test is doing an
identity check. We have proof from the OP's bug report that at least one
person thought that. I had to read the source code to check that it doesn't.

A better failure message would be helpful to make it clear that it
checks by value not identity ``if value is True``.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 07:47:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Nov 2019 12:47:26 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
In-Reply-To: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>
Message-ID: <1573044446.81.0.143561199582.issue38708@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +email
nosy: +barry, maxking, r.david.murray
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38708>
_______________________________________

From report at bugs.python.org  Wed Nov  6 07:50:00 2019
From: report at bugs.python.org (Aaron Ecay)
Date: Wed, 06 Nov 2019 12:50:00 +0000
Subject: [issue38719] Surprising and possibly incorrect passing of InitVar to
 __post_init__ method of data classes
Message-ID: <1573044600.53.0.155776883054.issue38719@roundup.psfhosted.org>


New submission from Aaron Ecay <aaronecay at gmail.com>:

I have discovered that InitVar's are passed in a surprising way to the __post_init__ method of python dataclasses.  The following program illustrates the problem:

=====

from dataclasses import InitVar, dataclass

@dataclass
class Foo:
    bar: InitVar[str]
    quux: InitVar[str]

    def __post_init__(self, quux: str, bar: str) -> None:
        print(f"bar is {bar}; quux is {quux}")

Foo(bar="a", quux="b")

=====

The output (on python 3.7.3 and 3.8.0a3) is (incorrectly):

bar is b; quux is a

This behavior seems like a bug to me, do you agree?

I have not looked into the reason why it behaves this way, but I suspect that the InitVar args are passed positionally, rather than as key words, to __post_init__.  This requires the order of arguments in the definition of __post_init__ to be identical to the order in which they are specified in the class.  I would expect the arguments to be passed as keywords instead, which would remove the ordering dependency.  If there is agreement that the current behavior is undesirable, I can look into creating a patch to change it.

----------
components: Library (Lib)
messages: 356125
nosy: Aaron Ecay
priority: normal
severity: normal
status: open
title: Surprising and possibly incorrect passing of InitVar to __post_init__ method of data classes
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38719>
_______________________________________

From report at bugs.python.org  Wed Nov  6 07:58:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Nov 2019 12:58:09 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573045089.6.0.0645738359803.issue38706@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If there is anything wrong with terms "true" and "false" (I don't know), we should fix this not only in one particular place, but everywhere. If there is nothing wrong with them, there is nothing to "improve". If this depends of the context, we should consider every occurrence case by case. Hope PR 17073 will help with this. It marks 665 of possible bugs so you can easily review these changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Wed Nov  6 08:03:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Nov 2019 13:03:19 +0000
Subject: [issue38719] Surprising and possibly incorrect passing of InitVar to
 __post_init__ method of data classes
In-Reply-To: <1573044600.53.0.155776883054.issue38719@roundup.psfhosted.org>
Message-ID: <1573045399.46.0.0870637649408.issue38719@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38719>
_______________________________________

From report at bugs.python.org  Wed Nov  6 08:08:52 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Nov 2019 13:08:52 +0000
Subject: [issue38703] should we expect round(0.95, 1) to be 1.0,
 instead of 0.9?
In-Reply-To: <1572983584.27.0.706501027569.issue38703@roundup.psfhosted.org>
Message-ID: <1573045732.55.0.166942081915.issue38703@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Steven]

py> '%.17f' % 0.95
'0.94999999999999996'

That's tricky to use correctly: it's not a priori clear how many digits after the point are needed to give you a faithful representation (the "17" in "%.17f" isn't going to be the right thing for most values). You really want to specify the number of significant digits rather than the number of places after the point, and even then there are going to be cases where 17 significant digits aren't enough to show you which side of a tie the exact value lies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38703>
_______________________________________

From report at bugs.python.org  Wed Nov  6 08:14:11 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 06 Nov 2019 13:14:11 +0000
Subject: [issue38719] Surprising and possibly incorrect passing of InitVar to
 __post_init__ method of data classes
In-Reply-To: <1573044600.53.0.155776883054.issue38719@roundup.psfhosted.org>
Message-ID: <1573046051.11.0.497184962436.issue38719@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think using named parameters in the call to __post_init__ is reasonable. It's currently positional.

----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38719>
_______________________________________

From report at bugs.python.org  Wed Nov  6 08:29:49 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Nov 2019 13:29:49 +0000
Subject: [issue38719] Surprising and possibly incorrect passing of InitVar to
 __post_init__ method of data classes
In-Reply-To: <1573044600.53.0.155776883054.issue38719@roundup.psfhosted.org>
Message-ID: <1573046989.95.0.517007925506.issue38719@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Should we also be checking for __post_init__ to have positional only arguments / syntax in the signature. I tried a simple fix of f.name + "=" + f.name to pass them as keyword always where current tests and reported example passes but with positional arguments it could be a problem.

https://github.com/python/cpython/blob/5c0c325453a175350e3c18ebb10cc10c37f9595c/Lib/dataclasses.py#L516

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38719>
_______________________________________

From report at bugs.python.org  Wed Nov  6 08:36:38 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 06 Nov 2019 13:36:38 +0000
Subject: [issue38719] Surprising and possibly incorrect passing of InitVar to
 __post_init__ method of data classes
In-Reply-To: <1573044600.53.0.155776883054.issue38719@roundup.psfhosted.org>
Message-ID: <1573047398.04.0.173069541257.issue38719@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think that's necessary. We should just document that parameters are passed by name to __post_init__. This would have to be a 3.9 feature, since it's not strictly backward compatible.

----------
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38719>
_______________________________________

From report at bugs.python.org  Wed Nov  6 09:02:59 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Nov 2019 14:02:59 +0000
Subject: [issue38704] Prevent installation on unsupported Windows versions
In-Reply-To: <1572983678.12.0.905160936522.issue38704@roundup.psfhosted.org>
Message-ID: <1573048979.1.0.378686745215.issue38704@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

We can, and we probably should, but it's not a high priority.

Technically the download page is correct, but updating it to specify Windows Vista as the 3.8 cutoff (and for 3.9, Windows 8.1) won't hurt.

----------
stage:  -> needs patch
title: No `GetActiveProcessorCount` on Windows Vista -> Prevent installation on unsupported Windows versions
type:  -> enhancement
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38704>
_______________________________________

From report at bugs.python.org  Wed Nov  6 09:07:53 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Nov 2019 14:07:53 +0000
Subject: [issue38683] Installation failed - no privileges to access directory
In-Reply-To: <1572865376.09.0.193791469521.issue38683@roundup.psfhosted.org>
Message-ID: <1573049273.95.0.0471403092463.issue38683@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

To change the install location to Program Files, you should select the "Install for All Users" option at the top of the page where you modified the install location. This will cause the installer to elevate.

Generic access errors should not trigger elevation - we have to treat them as an error.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38683>
_______________________________________

From report at bugs.python.org  Wed Nov  6 09:20:44 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 06 Nov 2019 14:20:44 +0000
Subject: [issue35381] posixmodule: convert statically allocated types
 (DirEntryType & ScandirIteratorType) to heap-allocated types
In-Reply-To: <1543818839.39.0.788709270274.issue35381@psf.upfronthosting.co.za>
Message-ID: <1573050044.52.0.214254797689.issue35381@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

The module still uses tp_new directly, so it's not limited to only stable ABI, but that's for another issue.

Thanks for the contribution!

----------
nosy: +petr.viktorin
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35381>
_______________________________________

From report at bugs.python.org  Wed Nov  6 09:23:10 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 06 Nov 2019 14:23:10 +0000
Subject: [issue38159] PyState_AddModule docs should say that it's not
 necessary to call it.
In-Reply-To: <1568381139.47.0.152206625825.issue38159@roundup.psfhosted.org>
Message-ID: <1573050190.17.0.582857005003.issue38159@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38159>
_______________________________________

From report at bugs.python.org  Wed Nov  6 09:27:20 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 06 Nov 2019 14:27:20 +0000
Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org>
Message-ID: <1573050440.32.0.512889689685.issue37645@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

With this change, CPython no longer uses PyEval_GetFuncName/PyEval_GetFuncDesc internally.
Shall we deprecate/discourage them?
Shall we expose PyObject_FunctionStr publicly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37645>
_______________________________________

From report at bugs.python.org  Wed Nov  6 09:27:28 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 06 Nov 2019 14:27:28 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1573050448.47.0.692584519968.issue38696@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 30da387df193b9f05c2891ae601ae5a1d669a5c1 by Miss Islington (bot) in branch '3.8':
bpo-38696: Fix usage example of HTTPStatus (GH-17066)
https://github.com/python/cpython/commit/30da387df193b9f05c2891ae601ae5a1d669a5c1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Wed Nov  6 09:27:28 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 06 Nov 2019 14:27:28 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1573050448.64.0.681732461926.issue38696@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 91f4b9282fe7cdc51c6612002d033da654f422c1 by Miss Islington (bot) in branch '3.7':
bpo-38696: Fix usage example of HTTPStatus (GH-17066)
https://github.com/python/cpython/commit/91f4b9282fe7cdc51c6612002d033da654f422c1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Wed Nov  6 09:29:01 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 06 Nov 2019 14:29:01 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1573050541.6.0.0088164760441.issue38696@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks for the report, Stojan, and for the patch, Ammar!

----------
nosy: +ammar2
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: resource usage -> behavior
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Wed Nov  6 10:10:27 2019
From: report at bugs.python.org (xtobes)
Date: Wed, 06 Nov 2019 15:10:27 +0000
Subject: [issue38720] Logging failure with timestamp messages
Message-ID: <1573053027.67.0.846988059067.issue38720@roundup.psfhosted.org>


New submission from xtobes <tobiasstrmoljan at gmail.com>:

This only happings on Windows, the scripts runs some seconds and then stops and exit with: Process finished with exit code -1073740940 (0xC0000374). This happens when the format variable of a logging config object contains the identifier '%(asctime)s'.

----------
components: Windows
messages: 356138
nosy: paul.moore, steve.dower, tim.golden, xtobes, zach.ware
priority: normal
severity: normal
status: open
title: Logging failure with timestamp messages
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38720>
_______________________________________

From report at bugs.python.org  Wed Nov  6 10:11:54 2019
From: report at bugs.python.org (Stojan Jovic)
Date: Wed, 06 Nov 2019 15:11:54 +0000
Subject: [issue38696] HTTP modules documentation error
In-Reply-To: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>
Message-ID: <1573053114.9.0.636188188062.issue38696@roundup.psfhosted.org>


Stojan Jovic <condor.js at gmail.com> added the comment:

Thank you, guys, for really quick fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38696>
_______________________________________

From report at bugs.python.org  Wed Nov  6 10:36:43 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 06 Nov 2019 15:36:43 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573032912.48.0.408728963846.issue38716@roundup.psfhosted.org>
Message-ID: <1573054603.59.0.621680961068.issue38716@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Would you consider it more acceptable to just turn
them into class level attributes of BaseRotatingHandler instead of
setting them in init?

Yes, that would be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 10:40:14 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 06 Nov 2019 15:40:14 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1573054814.02.0.367030323701.issue16575@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 484edbf9bf1a9e6bae0fcb10a0c165b89ea79295 by Vinay Sajip (Ammar Askar) in branch '3.7':
bpo-16575: Fix refleak on passing unions in ctypes (GH-17064)
https://github.com/python/cpython/commit/484edbf9bf1a9e6bae0fcb10a0c165b89ea79295


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Wed Nov  6 10:45:43 2019
From: report at bugs.python.org (lorb)
Date: Wed, 06 Nov 2019 15:45:43 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573054603.59.0.621680961068.issue38716@roundup.psfhosted.org>
Message-ID: <CAEmRbkt+rc-tAF6CmcHzQHzzKcZcCeHDtik=x9sTKVYCGHVWPQ@mail.gmail.com>


lorb <ritzer.christoph at gmail.com> added the comment:

I have changed the PR accordingly.

Am Mi., 6. Nov. 2019 um 16:36 Uhr schrieb Vinay Sajip <report at bugs.python.org>:
>
>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> > Would you consider it more acceptable to just turn
> them into class level attributes of BaseRotatingHandler instead of
> setting them in init?
>
> Yes, that would be better.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38716>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 11:05:22 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Wed, 06 Nov 2019 16:05:22 +0000
Subject: [issue38721] modulefinder should use io.open_code() instead of open()
Message-ID: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>


New submission from Dominic Littlewood <11dlittlewood at gmail.com>:

modulefinder currently will detect modules imported by a script dynamically by running the script, and to do this it has to open the script as a file.

This would also fix what appears to be a bug where modulefinder failed to open files in bytes mode sometimes, causing it to fail for some modules (like functools) if the wrong encoding is used. I say "appears to be", because the structure of the module seems to imply this was intended behaviour, but I can't think why anyone would want this.

This is similar to two other issues I'm posting, but they're in different modules, so different bugs.

----------
components: Library (Lib)
messages: 356143
nosy: plokmijnuhby
priority: normal
severity: normal
status: open
title: modulefinder should use io.open_code() instead of open()
type: security
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Wed Nov  6 11:05:25 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Wed, 06 Nov 2019 16:05:25 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
Message-ID: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>


New submission from Dominic Littlewood <11dlittlewood at gmail.com>:

Fairly obviously, if you're using something called runpy you're probably trying to run some code. To do this it has to open the script as a file.

This is similar to two other issues I'm posting, but they're in different modules, so different bugs.

----------
components: Library (Lib)
messages: 356144
nosy: plokmijnuhby
priority: normal
severity: normal
status: open
title: runpy should use io.open_code() instead of open()
type: security
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Wed Nov  6 11:05:27 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Wed, 06 Nov 2019 16:05:27 +0000
Subject: [issue38723] Pdb._runscript should use io.open_code() instead of
 open()
Message-ID: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>


New submission from Dominic Littlewood <11dlittlewood at gmail.com>:

Fairly obviously, if you're using something called _runscript you're probably trying to run some code. To do this it has to open the script as a file.

This is similar to two other issues I'm posting, but they're in different modules, so different bugs.

----------
messages: 356145
nosy: plokmijnuhby
priority: normal
severity: normal
status: open
title: Pdb._runscript should use io.open_code() instead of open()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38723>
_______________________________________

From report at bugs.python.org  Wed Nov  6 11:05:59 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Wed, 06 Nov 2019 16:05:59 +0000
Subject: [issue38723] Pdb._runscript should use io.open_code() instead of
 open()
In-Reply-To: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>
Message-ID: <1573056359.58.0.134093380454.issue38723@roundup.psfhosted.org>


Change by Dominic Littlewood <11dlittlewood at gmail.com>:


----------
components: +Library (Lib)
type:  -> security
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38723>
_______________________________________

From report at bugs.python.org  Wed Nov  6 11:36:02 2019
From: report at bugs.python.org (Mo)
Date: Wed, 06 Nov 2019 16:36:02 +0000
Subject: [issue38583] The activate script in Windows is not correct for venvs
 created in git-bash
In-Reply-To: <1571927523.33.0.935819222823.issue38583@roundup.psfhosted.org>
Message-ID: <1573058162.78.0.359930716888.issue38583@roundup.psfhosted.org>


Mo <moabrahams at dashavoo.com> added the comment:

I had also tested with pathlib and posixpath and come to the same conclusion.

As suggested by you, I looked into `activate` determining path when run. I believe this should do the trick (My bashfoo isn't strong, this is mostly from https://stackoverflow.com/a/179231):

pushd . > /dev/null
SCRIPT_PATH="${BASH_SOURCE[0]}"
if ([ -h "${SCRIPT_PATH}" ]); then
  while([ -h "${SCRIPT_PATH}" ]); do cd `dirname "$SCRIPT_PATH"`; 
  SCRIPT_PATH=`readlink "${SCRIPT_PATH}"`; done
fi
cd `dirname ${SCRIPT_PATH}` > /dev/null
cd .. > /dev/null
SCRIPT_PATH=`pwd`;
popd  > /dev/null

VIRTUAL_ENV="$SCRIPT_PATH"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38583>
_______________________________________

From report at bugs.python.org  Wed Nov  6 12:35:07 2019
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 06 Nov 2019 17:35:07 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1573061707.73.0.0559558820178.issue16575@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Will close after https://buildbot.python.org/all/#/builders?tags=%2Brefleak&tags=%2B3.7 go back to green.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Wed Nov  6 12:56:04 2019
From: report at bugs.python.org (Daniel King)
Date: Wed, 06 Nov 2019 17:56:04 +0000
Subject: [issue33450] unexpected EPROTOTYPE returned by sendto on MAC OSX
In-Reply-To: <1525892699.63.0.682650639539.issue33450@psf.upfronthosting.co.za>
Message-ID: <1573062964.15.0.100035998191.issue33450@roundup.psfhosted.org>


Change by Daniel King <dking at broadinstitute.org>:


----------
nosy: +Daniel King

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33450>
_______________________________________

From report at bugs.python.org  Wed Nov  6 12:57:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Nov 2019 17:57:20 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573063040.62.0.1225717436.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Would it be useful to use a pidfd in subprocess.Popen to fix bpo-38630 root issue, when pidfd is available?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov  6 14:44:32 2019
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 06 Nov 2019 19:44:32 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
Message-ID: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

I was working with a Popen object recently in the shell and it was annoying to see the `<subprocess.Popen at 0x4f83898>` display. It would be nice to get some kind of minimal detail about the Popen, for example its args and return code, if finished.

----------
components: Library (Lib)
messages: 356149
nosy: cool-RR, pitrou
priority: normal
severity: normal
status: open
title: Implement subprocess.Popen.__repr__
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Wed Nov  6 14:45:07 2019
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 06 Nov 2019 19:45:07 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573069507.89.0.275252356218.issue38724@roundup.psfhosted.org>


Change by Ram Rachum <ram at rachum.com>:


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Wed Nov  6 14:46:00 2019
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 06 Nov 2019 19:46:00 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573069560.29.0.459844282504.issue38724@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Wed Nov  6 15:06:31 2019
From: report at bugs.python.org (Zack Weinberg)
Date: Wed, 06 Nov 2019 20:06:31 +0000
Subject: [issue38725] Documented equivalent of `gzip -n` (omit timestamp and
 original file name) in gzip module
Message-ID: <1573070791.08.0.617845732948.issue38725@roundup.psfhosted.org>


New submission from Zack Weinberg <zackw at panix.com>:

Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero.  Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ).

Right now, the gzip module lets you set MTIME to zero explicitly by passing `mtime=0` to the GzipFile constructor, but this is not documented.  You can avoid writing out a filename by opening the output file yourself:

    with gzip.GzipFile(fileobj=open("foo.gz", "wb"),
                       filename='', mtime=0) as ofp:
        ... write to ofp ...

but that's awkward and, again, not documented.  I'd like to be able to write something like this instead:

    with gzip.open("foo.gz", mtime=0, record_filename=False) as ofp:

with this being the documented way to achieve the same effect as `gzip -n`.

----------
components: Library (Lib)
messages: 356150
nosy: zwol
priority: normal
severity: normal
status: open
title: Documented equivalent of `gzip -n` (omit timestamp and original file name) in gzip module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38725>
_______________________________________

From report at bugs.python.org  Wed Nov  6 15:12:04 2019
From: report at bugs.python.org (Zack Weinberg)
Date: Wed, 06 Nov 2019 20:12:04 +0000
Subject: [issue38726] Add equivalent of `gzip -n` (omit timestamp and original
 file name) to tarfile module's auto-compression support
Message-ID: <1573071124.37.0.34941021587.issue38726@roundup.psfhosted.org>


New submission from Zack Weinberg <zackw at panix.com>:

Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero.  Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ).

Right now, it's possible to get the `gzip` module to do the same thing (it's not documented, but it's possible; see bug 38725) but, as far as I can tell, if you use `tarfile`'s "w:gz" or "w|gz" modes you will always get a timestamp and a filename in the output.  Please add `w[:|]gzn`, or something like that, that behaves as-if the output were piped through `gzip -n`.

(It might make sense to remove the manual creation of a gzip file header from the tarfile module at the same time; it looks like this code predates the addition of the gzip module to the stdlib.)

----------
messages: 356151
nosy: zwol
priority: normal
severity: normal
status: open
title: Add equivalent of `gzip -n` (omit timestamp and original file name) to tarfile module's auto-compression support

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38726>
_______________________________________

From report at bugs.python.org  Wed Nov  6 15:14:38 2019
From: report at bugs.python.org (Zack Weinberg)
Date: Wed, 06 Nov 2019 20:14:38 +0000
Subject: [issue38727] setup.py sdist --format=gztar should use (equivalent of)
 `gzip -n`
Message-ID: <1573071278.89.0.711333419595.issue38727@roundup.psfhosted.org>


New submission from Zack Weinberg <zackw at panix.com>:

Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero.  Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ).

An sdist tarball is a build artifact and it should be created as reproducibly as possible.  In particular, --format=gztar should behave as-if `gzip -n` were in use.  (The stdlib's gzip module can produce output equivalent to what gzip -n does, but this is not currently documented nor is it accessible via `tarfile`.  Both of those should be easy fixes.  See bug 38725 and bug 38726.)

----------
components: Distutils
messages: 356152
nosy: dstufft, eric.araujo, zwol
priority: normal
severity: normal
status: open
title: setup.py sdist --format=gztar should use (equivalent of) `gzip -n`

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38727>
_______________________________________

From report at bugs.python.org  Wed Nov  6 15:25:57 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 06 Nov 2019 20:25:57 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573071956.99.0.11784985766.issue36906@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Another option not using a new letter: A triple-backtick token.


def foo():
    value = ```this is a
 
    long multi line string i don't want indented.
    ```

A discuss thread was started so I reconnected it with this issue.  See
 https://discuss.python.org/t/trimmed-multiline-string/2600/8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Wed Nov  6 15:36:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Nov 2019 20:36:17 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573072577.73.0.72469454723.issue36906@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it would be better to use use backtick quotes for f-strings instead of the f prefix. This would stress the special nature of f-strings (they are not literals, but expressions). But there was strong opposition to using backticks anywhere in Python syntax.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Wed Nov  6 15:59:19 2019
From: report at bugs.python.org (Marco Sulla)
Date: Wed, 06 Nov 2019 20:59:19 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573073959.17.0.86004771744.issue36906@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

If I can say my two cents:

1. I preferred that the default behaviour of multi-line was to dedent. But breaking old code, even if for a little percentage of code, IMHO is never a good idea. Py2->Py3 should have proved it.

2. ``` remembers me too much the Markdown for add a code block, not a text block

3. yes, the new prefix is really useless, because it's significant only for multiline strings. Anyway, if this solution is accepted, I propose `t` for `trim`.

----------
nosy: +Marco Sulla

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Wed Nov  6 16:22:03 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 06 Nov 2019 21:22:03 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573032912.48.0.408728963846.issue38716@roundup.psfhosted.org>
Message-ID: <1573075323.18.0.292042797222.issue38716@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 519cb8772a9745b1c7d8218cabcd2f96ceda4d62 by Vinay Sajip (l0rb) in branch 'master':
bpo-38716: stop rotating handlers from setting inherited namer and rotator to None (GH-17072)
https://github.com/python/cpython/commit/519cb8772a9745b1c7d8218cabcd2f96ceda4d62


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Wed Nov  6 16:48:10 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 06 Nov 2019 21:48:10 +0000
Subject: [issue38599] Deprecate creation of asyncio object when the loop is
 not running
In-Reply-To: <1572160085.79.0.39835517746.issue38599@roundup.psfhosted.org>
Message-ID: <1573076890.92.0.672382815499.issue38599@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38599>
_______________________________________

From report at bugs.python.org  Wed Nov  6 17:31:38 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 06 Nov 2019 22:31:38 +0000
Subject: [issue38599] Deprecate creation of asyncio object when the loop is
 not running
In-Reply-To: <1572160085.79.0.39835517746.issue38599@roundup.psfhosted.org>
Message-ID: <1573079498.7.0.744723416107.issue38599@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi, 

@asvetlov are you thinking something like the patch attached?

----------
keywords: +patch
Added file: https://bugs.python.org/file48697/0001-Add-a-deprectation-warning-for-queue-w-o-event-runni.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38599>
_______________________________________

From report at bugs.python.org  Wed Nov  6 17:41:31 2019
From: report at bugs.python.org (Jean-Christophe Fillion-Robin)
Date: Wed, 06 Nov 2019 22:41:31 +0000
Subject: [issue38728] Update PC/pyconfig.h to support disabling auto linking
Message-ID: <1573080091.42.0.697826916573.issue38728@roundup.psfhosted.org>


New submission from Jean-Christophe Fillion-Robin <jchris.fillionr at kitware.com>:

When configuring project using build-system generator like CMake, the linking is explicitly handled and does not to be implicitly hard-coded in pyconfig.h

Having the "pythonXY.lib" library hard-coded in pyconfig.h currently requires to explicitly specify a link directory. While possible, this require to increase the complexity of our build-system.

I suggest we introduce a new macro (e.g PY_CONFIG_AUTOLINK_DISABLED)

----------
components: Windows
messages: 356158
nosy: Jean-Christophe Fillion-Robin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update PC/pyconfig.h to support disabling auto linking
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38728>
_______________________________________

From report at bugs.python.org  Wed Nov  6 17:59:48 2019
From: report at bugs.python.org (Ben Reilly)
Date: Wed, 06 Nov 2019 22:59:48 +0000
Subject: [issue38729] mock.create_autospec generates incorrect signature for
 some decorated methods
Message-ID: <1573081188.35.0.210639381989.issue38729@roundup.psfhosted.org>


New submission from Ben Reilly <breilly at box.com>:

mock.create_autospec is meant to create a mock that will ensure, among other things, that method calls on the mock correspond to real methods on the original object and that the arguments match the signature of the original method. However, if the original method is decorated with a method that returns a callable object, the signature check may fail.

Attached is a script that demonstrates the error.

The essential part of the script looks like this:
====
def decorator(m):
    return Wrapper(m)

class Wrapper(object):
    def __init__(self, method):
        self.method = method
        update_wrapper(self, method)

    def __call__(self, instance, *args, **kwargs):
        return self.__get__(instance, type(instance))(*args, **kwargs)

    def __get__(self, instance, owner):
        ... # do the wrapping
====

The `decorator` method returns an instance of the `Wrapper` class, which is callable. Mock will calculate the signature of a method wrapped with `decorator` to be equal to that of `Wrapper.__call__`, namely `(instance, *args, **kwargs)`. Consequently, calls to the mocked method...

1. will incorrectly fail if the method usually takes no arguments, and
2. will incorrectly pass if the method takes at least one argument but too many arguments are provided.

This list of incorrect behaviour is not exhaustive, but hopefully you get the point.

If anyone's concerned about real-life examples, this kind of wrapper is used, for example, in the public Box SDK, as shown here: https://github.com/box/box-python-sdk/blob/b7f41d9a3f8be0ff3622a0c417bf31d2fbbee969/boxsdk/util/api_call_decorator.py#L10

----------
files: decorator.py
messages: 356159
nosy: breilly_box
priority: normal
severity: normal
status: open
title: mock.create_autospec generates incorrect signature for some decorated methods
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48698/decorator.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38729>
_______________________________________

From report at bugs.python.org  Wed Nov  6 18:03:05 2019
From: report at bugs.python.org (Ben Reilly)
Date: Wed, 06 Nov 2019 23:03:05 +0000
Subject: [issue38729] mock.create_autospec generates incorrect signature for
 some decorated methods
In-Reply-To: <1573081188.35.0.210639381989.issue38729@roundup.psfhosted.org>
Message-ID: <1573081385.76.0.174264621593.issue38729@roundup.psfhosted.org>


Change by Ben Reilly <breilly at box.com>:


----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38729>
_______________________________________

From report at bugs.python.org  Wed Nov  6 19:25:47 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 07 Nov 2019 00:25:47 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573086347.2.0.280349568815.issue36906@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Is there a reason folks are supporting a textwrap.dedent-like behavior over the generally cleaner inspect.cleandoc behavior? The main advantage to the latter being that it handles:

    '''First
    Second
    Third
    '''

just fine (removing the common indentation from Second/Third), and produces identical results with:

    '''
    First
    Second
    Third
    '''

where textwrap.dedent behavior would leave the first string unmodified (because it removes the largest common indentation, and First has no leading indentation), and dedenting the second, but leaving a leading newline in place (where cleandoc removes it), that can only be avoided by using the typically discouraged line continuation character to make it:

    '''\
    First
    Second
    Third
    '''

cleandoc behavior means the choice of whether the text begins and ends on the same line at the triple quote doesn't matter, and most use cases seem like they'd benefit from that flexibility.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Wed Nov  6 19:29:02 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 07 Nov 2019 00:29:02 +0000
Subject: [issue38710] unsynchronized write pointer in io.TextIOWrapper in 'r+'
 mode
In-Reply-To: <1573013055.2.0.421780617853.issue38710@roundup.psfhosted.org>
Message-ID: <1573086542.02.0.724855786236.issue38710@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38710>
_______________________________________

From report at bugs.python.org  Wed Nov  6 19:36:28 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 07 Nov 2019 00:36:28 +0000
Subject: [issue38710] unsynchronized write pointer in io.TextIOWrapper in 'r+'
 mode
In-Reply-To: <1573013055.2.0.421780617853.issue38710@roundup.psfhosted.org>
Message-ID: <1573086988.75.0.487837348605.issue38710@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38710>
_______________________________________

From report at bugs.python.org  Wed Nov  6 19:41:34 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Nov 2019 00:41:34 +0000
Subject: [issue13214] Cmd: list available completions from the cmd.Cmd
 subclass and filter out EOF handler(s)
In-Reply-To: <1318965366.62.0.48247525728.issue13214@psf.upfronthosting.co.za>
Message-ID: <1573087294.07.0.117081332803.issue13214@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +16584
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17074

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13214>
_______________________________________

From report at bugs.python.org  Wed Nov  6 20:36:13 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Nov 2019 01:36:13 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573090573.23.0.238673810494.issue38440@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

A new intermittent problem has arisen on macOS since I updated to Catalina.  It occurs on both 10.15.0 and 10.15.1.  I'm using the 3.8.0 mac 64-bit install taken directly from python.org.

In a long-running session of IDLE, the process freezes-up during File/SaveAs.  The file save dialog comes-up.  When typing the filename, the dialog window greys-out, the list of files goes blank, and the situation is unrecoverable (see the attached screenshot).

And see below for the core dump in the terminal session.


----------------------------------------------------------------

$ python3.8 -m idlelib.idle
2019-11-06 13:52:34.765 Python[38668:423017] WARNING: <NSSavePanel: 0x7ffd7d70ceb0> running implicitly; please run panels using NSSavePanel rather than NSApplication.
2019-11-06 13:52:40.958 Python[38668:423017] *** Assertion failure in -[NSSavePanel _attachSandboxExtensions:toURL:orURLs:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.10.126/Nav.subproj/OpenAndSavePanelRemote/NSVBOpenAndSavePanels.m:711
2019-11-06 13:52:40.963 Python[38668:423017] -[NSSavePanel observeValueForKeyPath:ofObject:change:context:] caught non-fatal NSInternalInconsistencyException 'unexpected class type for sandbox extension string!' with backtrace (
	0   CoreFoundation                      0x00007fff3b080f53 __exceptionPreprocess + 250
	1   libobjc.A.dylib                     0x00007fff71146835 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff3b09c810 +[NSException raise:format:arguments:] + 88
	3   Foundation                          0x00007fff3d77c5d1 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191
	4   AppKit                              0x00007fff38be944c __53-[NSSavePanel _attachSandboxExtensions:toURL:orURLs:]_block_invoke + 240
	5   CoreFoundation                      0x00007fff3b0d15a7 __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 7
	6   CoreFoundation                      0x00007fff3b00923d -[__NSSingleObjectArrayI enumerateObjectsWithOptions:usingBlock:] + 80
	7   AppKit                              0x00007fff38be925c -[NSSavePanel _attachSandboxExtensions:toURL:orURLs:] + 125
	8   AppKit                              0x00007fff38bedf4b -[NSSavePanel _URLsWithSecurityScoped:] + 193
	9   AppKit                              0x00007fff38be9481 -[NSSavePanel _attachSandboxExtensionsAndStartAccessing] + 48
	10  AppKit                              0x00007fff38bea7ce -[NSSavePanel completeWithReturnCode:url:urls:] + 164
	11  AppKit                              0x00007fff38bec787 -[NSSavePanel observeValueForKeyPath:ofObject:change:context:] + 341
	12  Foundation                          0x00007fff3d672412 NSKeyValueNotifyObserver + 335
	13  Foundation                          0x00007fff3d7faf56 NSKeyValueDidChange.llvm.18255262684423441536 + 434
	14  Foundation                          0x00007fff3d7fa761 NSKeyValueDidChangeWithPerThreadPendingNotifications.llvm.18255262684423441536 + 146
	15  ViewBridge                          0x00007fff6d7d8adc __41-[NSViewBridge setObject:forKey:withKVO:]_block_invoke + 360
	16  ViewBridge                          0x00007fff6d860b5c withHintInProgress + 472
	17  ViewBridge                          0x00007fff6d7cf17b -[NSViewBridge setObject:forKey:withKVO:] + 856
	18  ViewBridge                          0x00007fff6d7d087a -[NSViewBridge nonLocalChangeInProgress:block:] + 352
	19  ViewBridge                          0x00007fff6d7d04d7 -[NSRemoteViewMarshal exceptionSafeSetRemoteObject:forKey:withReply:] + 264
	20  ViewBridge                          0x00007fff6d7d038b -[NSRemoteViewMarshal setRemoteObject:forKey:withReply:] + 56
	21  CoreFoundation                      0x00007fff3afdf1dc __invoking___ + 140
	22  CoreFoundation                      0x00007fff3afdf07f -[NSInvocation invoke] + 305
	23  ViewBridge                          0x00007fff6d7cdb1e __deferNSXPCInvocationOntoMainThread_block_invoke + 228
	24  ViewBridge                          0x00007fff6d7c33ec __wrapBlockWithVoucher_block_invoke + 37
	25  ViewBridge                          0x00007fff6d7c31b1 __deferBlockOntoMainThread_block_invoke_2 + 507
	26  CoreFoundation                      0x00007fff3b00cd6b __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
	27  CoreFoundation                      0x00007fff3afcffdd __CFRunLoopDoBlocks + 379
	28  CoreFoundation                      0x00007fff3afcfd50 __CFRunLoopRun + 2792
	29  CoreFoundation                      0x00007fff3afcefe3 CFRunLoopRunSpecific + 499
	30  HIToolbox                           0x00007fff39b5667d RunCurrentEventLoopInMode + 292
	31  HIToolbox                           0x00007fff39b563bd ReceiveNextEventCommon + 600
	32  HIToolbox                           0x00007fff39b56147 _BlockUntilNextEventMatchingListInModeWithFilter + 64
	33  AppKit                              0x00007fff381db864 _DPSNextEvent + 990
	34  AppKit                              0x00007fff381da5d4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
	35  libtk8.6.dylib                      0x00000001021dc387 -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 42
	36  AppKit                              0x00007fff383ecb52 -[NSApplication _doModalLoop:peek:] + 315
	37  AppKit                              0x00007fff383eb699 __35-[NSApplication runModalForWindow:]_block_invoke_2 + 64
	38  AppKit                              0x00007fff383eb646 __35-[NSApplication runModalForWindow:]_block_invoke + 70
	39  AppKit                              0x00007fff383eaed8 _NSTryRunModal + 100
	40  AppKit                              0x00007fff383eadbd -[NSApplication runModalForWindow:] + 128
	41  libtk8.6.dylib                      0x00000001021cb18b Tk_GetSaveFileObjCmd + 2945
	42  libtcl8.6.dylib                     0x0000000101fc46dc TclNRRunCallbacks + 80
	43  _tkinter.cpython-38-darwin.so       0x0000000101fa2049 Tkapp_Call + 585
	44  Python                              0x0000000101847bc2 cfunction_call_varargs + 290
	45  Python                              0x0000000101911c6b _PyEval_EvalFrameDefault + 27339
	46  Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	47  Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	48  Python                              0x000000010184a59a method_vectorcall + 170
	49  Python                              0x00000001019147dc call_function + 444
	50  Python                              0x0000000101911714 _PyEval_EvalFrameDefault + 25972
	51  Python                              0x0000000101847ed0 function_code_fastcall + 128
	52  Python                              0x00000001019147dc call_function + 444
	53  Python                              0x00000001019115c9 _PyEval_EvalFrameDefault + 25641
	54  Python                              0x0000000101847ed0 function_code_fastcall + 128
	55  Python                              0x000000010184a67c method_vectorcall + 396
	56  Python                              0x00000001018478ad PyVectorcall_Call + 109
	57  Python                              0x0000000101911af8 _PyEval_EvalFrameDefault + 26968
	58  Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	59  Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	60  Python                              0x000000010184a67c method_vectorcall + 396
	61  Python                              0x00000001018478ad PyVectorcall_Call + 109
	62  _tkinter.cpython-38-darwin.so       0x0000000101fa4bf1 PythonCmd + 209
	63  libtcl8.6.dylib                     0x0000000101fc46dc TclNRRunCallbacks + 80
	64  libtcl8.6.dylib                     0x0000000101fc593a TclEvalEx + 1953
	65  libtcl8.6.dylib                     0x0000000101fc5193 Tcl_EvalEx + 26
	66  libtk8.6.dylib                      0x000000010211a39f Tk_BindEvent + 3956
	67  libtk8.6.dylib                      0x000000010211fb6d TkBindEventProc + 347
	68  libtk8.6.dylib                      0x0000000102127636 Tk_HandleEvent + 1108
	69  libtk8.6.dylib                      0x000000010211beb0 Tk_EventObjCmd + 5203
	70  libtcl8.6.dylib                     0x0000000101fc46dc TclNRRunCallbacks + 80
	71  _tkinter.cpython-38-darwin.so       0x0000000101fa2049 Tkapp_Call + 585
	72  Python                              0x0000000101850739 method_vectorcall_VARARGS + 265
	73  Python                              0x00000001019147dc call_function + 444
	74  Python                              0x00000001019115c9 _PyEval_EvalFrameDefault + 25641
	75  Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	76  Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	77  Python                              0x00000001019147dc call_function + 444
	78  Python                              0x00000001019115c9 _PyEval_EvalFrameDefault + 25641
	79  Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	80  Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	81  Python                              0x00000001018478ad PyVectorcall_Call + 109
	82  Python                              0x0000000101911af8 _PyEval_EvalFrameDefault + 26968
	83  Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	84  Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	85  Python                              0x000000010184a5db method_vectorcall + 235
	86  Python                              0x00000001018478ad PyVectorcall_Call + 109
	87  _tkinter.cpython-38-darwin.so       0x0000000101fa4bf1 PythonCmd + 209
	88  libtcl8.6.dylib                     0x0000000101fc46dc TclNRRunCallbacks + 80
	89  libtk8.6.dylib                      0x0000000102154311 TkInvokeMenu + 470
	90  libtk8.6.dylib                      0x00000001021d6f3e -[TKMenu(TKMenuActions) tkMenuItemInvoke:] + 184
	91  AppKit                              0x00007fff3848e8d4 -[NSApplication(NSResponder) sendAction:to:from:] + 299
	92  AppKit                              0x00007fff384e3a4e -[NSMenuItem _corePerformAction] + 312
	93  AppKit                              0x00007fff384e37ca -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 106
	94  AppKit                              0x00007fff3853b9c0 -[NSMenu performActionForItemAtIndex:] + 114
	95  AppKit                              0x00007fff3853b945 -[NSMenu _internalPerformActionForItemAtIndex:] + 82
	96  AppKit                              0x00007fff3853b78c -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 101
	97  AppKit                              0x00007fff384b5b20 NSSLMMenuEventHandler + 908
	98  HIToolbox                           0x00007fff39b54701 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1419
	99  HIToolbox                           0x00007fff39b53ad0 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 338
	100 HIToolbox                           0x00007fff39b71108 SendEventToEventTarget + 39
	101 HIToolbox                           0x00007fff39bc20a4 _ZL18SendHICommandEventjPK9HICommandjjhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef + 368
	102 HIToolbox                           0x00007fff39be96ce SendMenuCommandWithContextAndModifiers + 45
	103 HIToolbox                           0x00007fff39be9673 SendMenuItemSelectedEvent + 339
	104 HIToolbox                           0x00007fff39be94c7 _ZL19FinishMenuSelectionP13SelectionDataP10MenuResultS2_ + 96
	105 HIToolbox                           0x00007fff39be9ef3 _ZL14MenuSelectCoreP8MenuData5PointdjPP13OpaqueMenuRefPt + 603
	106 HIToolbox                           0x00007fff39be9bfc _HandleMenuSelection2 + 452
	107 AppKit                              0x00007fff381e5085 _NSHandleCarbonMenuEvent + 215
	108 AppKit                              0x00007fff381e4ef2 _DPSEventHandledByCarbon + 54
	109 AppKit                              0x00007fff381dac1e -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2962
	110 libtk8.6.dylib                      0x00000001021dc387 -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 42
	111 libtk8.6.dylib                      0x00000001021dc6fc TkMacOSXEventsCheckProc + 295
	112 libtcl8.6.dylib                     0x0000000102073d06 Tcl_DoOneEvent + 316
	113 _tkinter.cpython-38-darwin.so       0x0000000101fa43de _tkinter_tkapp_mainloop + 382
	114 Python                              0x0000000101850ace method_vectorcall_FASTCALL + 254
	115 Python                              0x00000001019147dc call_function + 444
	116 Python                              0x00000001019115c9 _PyEval_EvalFrameDefault + 25641
	117 Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	118 Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	119 Python                              0x000000010184a59a method_vectorcall + 170
	120 Python                              0x00000001019147dc call_function + 444
	121 Python                              0x00000001019115ed _PyEval_EvalFrameDefault + 25677
	122 Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	123 Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	124 Python                              0x00000001019147dc call_function + 444
	125 Python                              0x000000010191167a _PyEval_EvalFrameDefault + 25818
	126 Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	127 Python                              0x000000010190b0c4 PyEval_EvalCode + 100
	128 Python                              0x00000001019084b2 builtin_exec + 626
	129 Python                              0x000000010188381f cfunction_vectorcall_FASTCALL + 175
	130 Python                              0x00000001019147dc call_function + 444
	131 Python                              0x000000010191167a _PyEval_EvalFrameDefault + 25818
	132 Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	133 Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	134 Python                              0x00000001019147dc call_function + 444
	135 Python                              0x000000010191167a _PyEval_EvalFrameDefault + 25818
	136 Python                              0x0000000101915624 _PyEval_EvalCodeWithName + 2804
	137 Python                              0x000000010184806e _PyFunction_Vectorcall + 270
	138 Python                              0x00000001018478ad PyVectorcall_Call + 109
	139 Python                              0x0000000101977a96 pymain_run_module + 182
	140 Python                              0x000000010197705d Py_RunMain + 1085
	141 Python                              0x00000001019777cf pymain_main + 223
	142 Python                              0x00000001019779cb Py_BytesMain + 43
	143 libdyld.dylib                       0x00007fff724a92e5 start + 1
	144 ???                                 0x0000000000000003 0x0 + 3
)

----------
Added file: https://bugs.python.org/file48699/Screen Shot 2019-11-06 at 5.29.32 PM.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Wed Nov  6 20:54:41 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 07 Nov 2019 01:54:41 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573091681.61.0.0583566249278.issue36906@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

.cleandoc is _probably_ more of what people want than .dedent?  I hadn't bothered to even try to pick between the two yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Wed Nov  6 21:01:00 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 07 Nov 2019 02:01:00 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573092060.61.0.727945887161.issue38440@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

That's quite a stack trace, bouncing back and forth between Python and Tk and macOS.  I don't really have any experience with the flow of control there with call outs to file save dialogs.  CCing Kevin Walzer on the off chance that this might be familiar and hopefully fixed in the forthcoming Tk 8.6.10 release.  Kevin, we are still running with a vanilla 8.6.8 release built on macOS 10.9.

----------
nosy: +wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Wed Nov  6 21:04:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 07 Nov 2019 02:04:10 +0000
Subject: [issue38729] mock.create_autospec generates incorrect signature for
 some decorated methods
In-Reply-To: <1573081188.35.0.210639381989.issue38729@roundup.psfhosted.org>
Message-ID: <1573092250.34.0.559394580586.issue38729@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Library (Lib) -Tests
nosy: +cjw296, lisroach, mariocj89, michael.foord, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38729>
_______________________________________

From report at bugs.python.org  Wed Nov  6 21:24:58 2019
From: report at bugs.python.org (Jack Wong)
Date: Thu, 07 Nov 2019 02:24:58 +0000
Subject: [issue11588] Add "necessarily inclusive" groups to argparse
In-Reply-To: <1300377092.03.0.159307937388.issue11588@psf.upfronthosting.co.za>
Message-ID: <1573093498.72.0.0431955680401.issue11588@roundup.psfhosted.org>


Change by Jack Wong <ajackwong at gmail.com>:


----------
nosy: +iforapsy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11588>
_______________________________________

From report at bugs.python.org  Wed Nov  6 21:39:27 2019
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 07 Nov 2019 02:39:27 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1573094367.15.0.275920727199.issue16575@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Wed Nov  6 21:57:22 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 02:57:22 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1573063040.62.0.1225717436.issue38692@roundup.psfhosted.org>
Message-ID: <eb754be7-bcef-4cc5-b83f-a5636ee32b6a@www.fastmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Wed, Nov 6, 2019, at 09:57, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
> Would it be useful to use a pidfd in subprocess.Popen to fix bpo-38630 
> root issue, when pidfd is available?

Probably, but as noted above, we need to figure out the best way to integrate pidfds into subprocess. (Probably not in this issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov  6 23:06:10 2019
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 07 Nov 2019 04:06:10 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573099570.01.0.0336091898786.issue38440@roundup.psfhosted.org>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

On macOS, Tk 8.6.8 is considered ancient, even obsolete, on 10.14 or later. Tk has required huge re-work to accommodate changes in the Mac's drawing API's on 10.14, mostly done by Marc Culler; these issues are not observable with the current tip of 8.6 development and IDLE 3.7.4. An RC of 8.6.10 has just gone out and we are anticipating the final release by Nov. 21, which includes too many changes to enumerate here. In any case, it should be considerably more stable than what is being reported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Wed Nov  6 23:53:19 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 04:53:19 +0000
Subject: [issue38730] 2.7 modern compiler warnings
Message-ID: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:

GCC 9's -Wstringop-truncation warnings trigger several times in 2.7. Some of these instances are all actual bugs. In all cases, we should clarify the code to make the compiler happy.

----------
components: Build
messages: 356166
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: 2.7 modern compiler warnings
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38730>
_______________________________________

From report at bugs.python.org  Wed Nov  6 23:55:21 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 04:55:21 +0000
Subject: [issue38730] 2.7 modern compiler warnings
In-Reply-To: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>
Message-ID: <1573102521.6.0.442651693882.issue38730@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38730>
_______________________________________

From report at bugs.python.org  Wed Nov  6 23:59:48 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Nov 2019 04:59:48 +0000
Subject: [issue37731] Possible redifinition of _POSIX_C_SOURCE in ./pyconfig.h
In-Reply-To: <1564582479.63.0.743037360682.issue37731@roundup.psfhosted.org>
Message-ID: <1573102788.86.0.606162565011.issue37731@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16586
pull_request: https://github.com/python/cpython/pull/17076

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37731>
_______________________________________

From report at bugs.python.org  Thu Nov  7 00:10:14 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Nov 2019 05:10:14 +0000
Subject: [issue37731] Possible redifinition of _POSIX_C_SOURCE in ./pyconfig.h
In-Reply-To: <1564582479.63.0.743037360682.issue37731@roundup.psfhosted.org>
Message-ID: <1573103414.63.0.587714757636.issue37731@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 30114c7119a9ae0e610d6974f57f22d8d05ed50d by Miss Islington (bot) in branch '2.7':
bpo-37731: Reorder includes in xmltok.c to avoid redefinition of _POSIX_C_SOURCE (GH-16733)
https://github.com/python/cpython/commit/30114c7119a9ae0e610d6974f57f22d8d05ed50d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37731>
_______________________________________

From report at bugs.python.org  Thu Nov  7 00:19:16 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 05:19:16 +0000
Subject: [issue37731] Possible redifinition of _POSIX_C_SOURCE in ./pyconfig.h
In-Reply-To: <1564582479.63.0.743037360682.issue37731@roundup.psfhosted.org>
Message-ID: <1573103956.67.0.450629869969.issue37731@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +16587
pull_request: https://github.com/python/cpython/pull/17077

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37731>
_______________________________________

From report at bugs.python.org  Thu Nov  7 00:29:52 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 05:29:52 +0000
Subject: [issue37731] Possible redifinition of _POSIX_C_SOURCE in ./pyconfig.h
In-Reply-To: <1564582479.63.0.743037360682.issue37731@roundup.psfhosted.org>
Message-ID: <1573104592.54.0.794100144977.issue37731@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 089e5f52a34377193a9e6c03088114b14c8507af by Benjamin Peterson in branch '2.7':
bpo-37731: Squish another _POSIX_C_SOURCE redefinition problem in expat. (GH-17077)
https://github.com/python/cpython/commit/089e5f52a34377193a9e6c03088114b14c8507af


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37731>
_______________________________________

From report at bugs.python.org  Thu Nov  7 00:49:44 2019
From: report at bugs.python.org (larabrian)
Date: Thu, 07 Nov 2019 05:49:44 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1573105784.63.0.926114799222.issue36406@roundup.psfhosted.org>


larabrian <larabrian at protonmail.com> added the comment:

A subscriptable object is any object that implements the __getitem__ special method (think lists, dictionaries). It is an object that records the operations done to it and it can store them as a "script" which can be replayed. You are trying to subscript an object which you think is a list or dict, but actually is None. NoneType is the type of the None object which represents a lack of value, for example, a function that does not explicitly return a value will return None. 'NoneType' object is not subscriptable is the one thrown by python when you use the square bracket notation object[key] where an object doesn't define the __getitem__ method . You might have noticed that the method sort() that only modify the list have no return value printed ? they return the default None. This is a design principle for all mutable data structures in Python. http://net-informations.com/python/err/nonetype.htm

----------
nosy: +larabrian

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Thu Nov  7 00:50:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Nov 2019 05:50:51 +0000
Subject: [issue38382] statistics.harmonic_mean fails to raise error with
 negative input that follows a 0
In-Reply-To: <1570326378.93.0.0728676630318.issue38382@roundup.psfhosted.org>
Message-ID: <1573105851.32.0.57190460268.issue38382@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 7f460494d2309ace004a400bae8fc59134dc325c by Raymond Hettinger in branch 'master':
bpo-38382: Document the early-out behavior for a zero (GH-17037)
https://github.com/python/cpython/commit/7f460494d2309ace004a400bae8fc59134dc325c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38382>
_______________________________________

From report at bugs.python.org  Thu Nov  7 00:50:57 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Nov 2019 05:50:57 +0000
Subject: [issue38382] statistics.harmonic_mean fails to raise error with
 negative input that follows a 0
In-Reply-To: <1570326378.93.0.0728676630318.issue38382@roundup.psfhosted.org>
Message-ID: <1573105857.88.0.385669741441.issue38382@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16588
pull_request: https://github.com/python/cpython/pull/17078

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38382>
_______________________________________

From report at bugs.python.org  Thu Nov  7 00:58:16 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Nov 2019 05:58:16 +0000
Subject: [issue38382] statistics.harmonic_mean fails to raise error with
 negative input that follows a 0
In-Reply-To: <1570326378.93.0.0728676630318.issue38382@roundup.psfhosted.org>
Message-ID: <1573106296.66.0.589998235151.issue38382@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 6b66dc387935df432cdbc01397ddef534a84ade9 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-38382: Document the early-out behavior for a zero (GH-17037) (GH-17078)
https://github.com/python/cpython/commit/6b66dc387935df432cdbc01397ddef534a84ade9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38382>
_______________________________________

From report at bugs.python.org  Thu Nov  7 00:58:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Nov 2019 05:58:50 +0000
Subject: [issue38382] statistics.harmonic_mean fails to raise error with
 negative input that follows a 0
In-Reply-To: <1570326378.93.0.0728676630318.issue38382@roundup.psfhosted.org>
Message-ID: <1573106330.78.0.721471215619.issue38382@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38382>
_______________________________________

From report at bugs.python.org  Thu Nov  7 01:35:33 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 07 Nov 2019 06:35:33 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573108533.23.0.296979518469.issue38440@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for the report on the freezes, Raymond! My mac was recently fixed and I've upgraded to the latest OS version, so I'll take a look at this as well.

Thanks for the update on the Tk side, Kevin. It's very unfortunate that we've found 3.6.9 unusable with Python, and I certainly hope that 3.6.10 will not be like that. How can we work with the Tk developers to ensure it works with Python across platforms?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Thu Nov  7 01:53:38 2019
From: report at bugs.python.org (Kaoru Esashika)
Date: Thu, 07 Nov 2019 06:53:38 +0000
Subject: [issue38731] bad input crashes py_compile library
Message-ID: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>


New submission from Kaoru Esashika <kaoru.esashika at gmail.com>:

How to reproduction:
Step 1: make bad source code
Step 2: run "python -m py_compile bad_source_code.py"
Step 3: errors printed

It seems that this problem is introduced at issue 22640 (commit https://github.com/python/cpython/commit/2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1)
and it have not fixed yet.

variable 'quiet' is not defined in main function as far as I can see.

```
Traceback (most recent call last):
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 144, in compile
    code = loader.source_to_code(source_bytes, dfile or file,
  File "<frozen importlib._bootstrap_external>", line 846, in source_to_code
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "c:/Users/<USERNAME>/AppData/Local/Temp/flycheckrIYLj4/test.py", line 25
    def calc_entropy(self):
    ^
IndentationError: expected an indented block

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 209, in main
    compile(filename, doraise=True)
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 150, in compile
    raise py_exc
__main__.PyCompileError: Sorry: IndentationError: expected an indented block (c:/Users/<USERNAME>/AppData/Local/Temp/flycheckrIYLj4/test.py, line 25)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 218, in <module>
    sys.exit(main())
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 213, in main
    if quiet < 2:
NameError: name 'quiet' is not defined

```

----------
components: Library (Lib)
messages: 356173
nosy: Kaoru Esashika
priority: normal
severity: normal
status: open
title: bad input crashes py_compile library
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Thu Nov  7 01:59:06 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 07 Nov 2019 06:59:06 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573109946.64.0.822217142111.issue38440@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks, Kevin.  I do see that 8.6.10rc1 is now available.  Yay!

Tal:
> How can we work with the Tk developers to ensure it works with Python across platforms?

We have the first 3.9.0 alpha scheduled in about 10 days. I will try to build 8.6.10rc1 (or later release) and include it in 3.9.0a1. I could also try to make a 3.8.0 and/or 3.7.5 with 8.6.10rc1 installer available informally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Thu Nov  7 02:07:17 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 07 Nov 2019 07:07:17 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573110437.11.0.940324977226.issue38440@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Ned:
- I could also try to make a 3.8.0 and/or 3.7.5 with 8.6.10rc1 installer available informally.

That would be very helpful! If you do so I'd be happy to test on Windows, macOS. I'm also able to test on Ubuntu if that would help.

I suggest we somehow collect new issues we find with the 3.6.10 release candidates and follow up those with the Tk developers - perhaps we could use a dedicated issue here or some other shared document?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Thu Nov  7 02:12:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Nov 2019 07:12:44 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573110764.49.0.999506152471.issue38440@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Quick summary and opinions so far:
* Jump to top: general IDLE bug, fixed.

* Repeated quit message: never seen by me, likely IDLE bug.  I need to check code where message emitted.

* Arrow keys emit ? replacement char: never seen by me, likely tcl bug. IDLE only binds <Key-Up> and <Key-Down> for completion, font, and path/browser lists, but not editor.  So if bug happens in editor, as implied, IDLE likely not involved.

* SaveFile crash: never seen by me with this dialog that I remember, likely tcl or even macOS bug.  The dialog matches Safari SaveAs box with Python-specific formats.  It results from IDLE tkinter call, which calls tcl, which calls AppKit -- lines 41-40 in C call stack.  Line 35 is the only non-OS (tcl) call thereafter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Thu Nov  7 02:17:16 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 07 Nov 2019 07:17:16 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573111036.77.0.852356088062.issue38440@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> That would be very helpful! If you do so I'd be happy to test on Windows, macOS.

Sorry, I meant for macOS only.  I'm not getting into the business of building Windows installers, too. :)  As for Ubuntu, you should be able to build that yourself.  But I think Kevin's point is that there are a lot of macOS-specific changes in Tk 8.6.10 and that's what we can really help to test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Thu Nov  7 03:18:15 2019
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 07 Nov 2019 08:18:15 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1573114695.86.0.993684920525.issue38731@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> needs patch
type: crash -> behavior
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Thu Nov  7 03:42:03 2019
From: report at bugs.python.org (Marco)
Date: Thu, 07 Nov 2019 08:42:03 +0000
Subject: [issue38732] Adding relp support as a new logging handler
Message-ID: <1573116123.59.0.255595636575.issue38732@roundup.psfhosted.org>


New submission from Marco <m.faverof at gmail.com>:

Hello, a pyrelp module was released to send messages over RELP to a RELP server, such as rsylog:

   https://github.com/mathias-nyman/pyrelp
   https://github.com/rsyslog/librelp

It should be very useful the possibility to add this feature as a logging handler.

A SyslogHandler already exists, but it support only normal TCP. You could add the RELP support.

Thank you to consider this.

----------
components: Extension Modules
messages: 356178
nosy: falon
priority: normal
severity: normal
status: open
title: Adding relp support as a new logging handler
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38732>
_______________________________________

From report at bugs.python.org  Thu Nov  7 03:45:30 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 07 Nov 2019 08:45:30 +0000
Subject: [issue38732] Adding relp support as a new logging handler
In-Reply-To: <1573116123.59.0.255595636575.issue38732@roundup.psfhosted.org>
Message-ID: <1573116330.51.0.899680508381.issue38732@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38732>
_______________________________________

From report at bugs.python.org  Thu Nov  7 03:54:31 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 07 Nov 2019 08:54:31 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1573116871.28.0.15701760487.issue38731@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Thu Nov  7 04:22:16 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 07 Nov 2019 09:22:16 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573118536.41.0.902566389354.issue38706@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Generally, ?true? and ?false? refer to ?truthiness?, while the actual ``True`` and ``False`` literals should be capitalized. And in monospace font if possible.

I think this is a good convention, but it's quite subtle, and I don't think it's explicitly mentioned in the docs.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Thu Nov  7 04:29:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 09:29:32 +0000
Subject: [issue38733] PyErr_Occurred(): tstate must be non-NULL
Message-ID: <1573118972.06.0.487473179974.issue38733@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

bpo-3605 modified PyErr_Occurred() to return NULL if the current Python thread state ("tstate") is NULL:

commit 8e0bdfd1d473ddffaf3501768678f8a970019da8
Author: Jeffrey Yasskin <jyasskin at gmail.com>
Date:   Thu May 13 18:31:05 2010 +0000

    Make PyErr_Occurred return NULL if there is no current thread.  Previously it
    would Py_FatalError, which called PyErr_Occurred, resulting in a semi-infinite
    recursion.
    
    Fixes issue 3605.

This change made PyErr_Occurred() inefficient: PyErr_Occurred() was a simple attribute read (tstate->curexc_type), and now there is an additional if per call.

I recently added _PyErr_Occurred(tstate) which is similar to PyErr_Occurred() but requires to pass tstate explicitly. I expected this function to be as simple as:

static inline PyObject* _PyErr_Occurred(PyThreadState *tstate)
{
    return tstate->curexc_type;
}

but the current implementation is:

static inline PyObject* _PyErr_Occurred(PyThreadState *tstate)
{
    return tstate == NULL ? NULL : tstate->curexc_type;
}


--

PyErr_Occurred() is currently implemented as:

PyObject* _Py_HOT_FUNCTION
PyErr_Occurred(void)
{
    PyThreadState *tstate = _PyThreadState_GET();
    return _PyErr_Occurred(tstate);
}

_PyThreadState_GET() must only be called with the GIL hold. This macro is designed to be efficient: it doesn't check if tstate is NULL.

_PyThreadState_GET() is only NULL if the thread has no Python thread state yet, or if the GIL is released.

IMHO PyErr_Occurred() must not be called if the GIL is released.

----------
components: Interpreter Core
messages: 356180
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyErr_Occurred(): tstate must be non-NULL
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38733>
_______________________________________

From report at bugs.python.org  Thu Nov  7 05:09:19 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Nov 2019 10:09:19 +0000
Subject: [issue36876] Global C variables are a problem.
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1573121359.06.0.548815081498.issue36876@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 9def81aa52adc3cc89554156e40742cf17312825 by Vinay Sajip in branch 'master':
bpo-36876: Moved Parser/listnode.c statics to interpreter state. (GH-16328)
https://github.com/python/cpython/commit/9def81aa52adc3cc89554156e40742cf17312825


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Thu Nov  7 05:22:32 2019
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 07 Nov 2019 10:22:32 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573122152.87.0.502699760098.issue36906@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Anyway there's something strange in string escaping and `inspect.cleandoc()`:

>>> a = """
... \nciao
...     bello
... \ ciao
... """
>>> print(inspect.cleandoc(a))
ciao
    bello
\ ciao
>>> print("\ ciao")
\ ciao

I expected:

>>> print(inspect.cleandoc(a))

ciao
bello
 ciao
>>> print("\ ciao")
 ciao

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Thu Nov  7 05:28:14 2019
From: report at bugs.python.org (Paul Anton Letnes)
Date: Thu, 07 Nov 2019 10:28:14 +0000
Subject: [issue38734] Python 3.7 and 3.8 in Windows Store do not start under
 git bash
Message-ID: <1573122494.13.0.703066612304.issue38734@roundup.psfhosted.org>


New submission from Paul Anton Letnes <pa at letnes.com>:

Python 3.7 and 3.8 installed from the  Windows Store do not start under git bash. Rather, they give some variation of this error message:

bash: /c/Users/pa/AppData/Local/Microsoft/WindowsApps/python: Permission denied

However, the permissions are rwxr-xr-x, or 755 if you prefer. The same error occurs if I try to run pip.

How can I run python under git bash? I use python and various pip-installed executables (e.g. black) for git hooks, so this has to work for my workflow.

----------
components: Windows
messages: 356183
nosy: paul.moore, pletnes, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.7 and 3.8 in Windows Store do not start under git bash
type: crash
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38734>
_______________________________________

From report at bugs.python.org  Thu Nov  7 05:32:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 10:32:10 +0000
Subject: [issue38733] PyErr_Occurred(): tstate must be non-NULL
In-Reply-To: <1573118972.06.0.487473179974.issue38733@roundup.psfhosted.org>
Message-ID: <1573122730.18.0.316258339208.issue38733@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38733>
_______________________________________

From report at bugs.python.org  Thu Nov  7 05:32:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 10:32:10 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1573122730.27.0.0897794832724.issue3605@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16590
pull_request: https://github.com/python/cpython/pull/17080

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Thu Nov  7 06:42:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 11:42:22 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1573126942.04.0.201603568757.issue3605@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d12d0e7c0fe2b49c40ac4d66365147c619d6c475 by Victor Stinner in branch 'master':
bpo-38733: PyErr_Occurred() caller must hold the GIL (GH-17080)
https://github.com/python/cpython/commit/d12d0e7c0fe2b49c40ac4d66365147c619d6c475


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Thu Nov  7 06:42:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 11:42:21 +0000
Subject: [issue38733] PyErr_Occurred(): tstate must be non-NULL
In-Reply-To: <1573118972.06.0.487473179974.issue38733@roundup.psfhosted.org>
Message-ID: <1573126941.95.0.523746135052.issue38733@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d12d0e7c0fe2b49c40ac4d66365147c619d6c475 by Victor Stinner in branch 'master':
bpo-38733: PyErr_Occurred() caller must hold the GIL (GH-17080)
https://github.com/python/cpython/commit/d12d0e7c0fe2b49c40ac4d66365147c619d6c475


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38733>
_______________________________________

From report at bugs.python.org  Thu Nov  7 06:45:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 11:45:51 +0000
Subject: [issue38733] PyErr_Occurred(): tstate must be non-NULL
In-Reply-To: <1573118972.06.0.487473179974.issue38733@roundup.psfhosted.org>
Message-ID: <1573127151.38.0.779542289118.issue38733@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In 2018 with bpo-26558, I fixed Py_FatalError() to no longer access the current exception of the current Python thread state, if the current thread doesn't not hold the GIL:

commit 3a228ab17c2a9cffd1a2f15f30d6209768de20a6
Author: Victor Stinner <vstinner at redhat.com>
Date:   Thu Nov 1 00:26:41 2018 +0100

    bpo-26558: Fix Py_FatalError() with GIL released (GH-10267)
    
    Don't call _Py_FatalError_PrintExc() nor flush_std_files() if the
    current thread doesn't hold the GIL, or if the current thread
    has no Python state thread.


Extract of Py_FatalError() code:

    /* Check if the current thread has a Python thread state
       and holds the GIL.

       tss_tstate is NULL if Py_FatalError() is called from a C thread which
       has no Python thread state.

       tss_tstate != tstate if the current Python thread does not hold the GIL.
       */
    PyThreadState *tss_tstate = PyGILState_GetThisThreadState();
    int has_tstate_and_gil = (tss_tstate != NULL && tss_tstate == tstate);
    if (has_tstate_and_gil) {
        /* If an exception is set, print the exception with its traceback */
        if (!_Py_FatalError_PrintExc(fd)) {
            /* No exception is set, or an exception is set without traceback */
            _Py_FatalError_DumpTracebacks(fd, interp, tss_tstate);
        }
    }
    else {
        _Py_FatalError_DumpTracebacks(fd, interp, tss_tstate);
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38733>
_______________________________________

From report at bugs.python.org  Thu Nov  7 06:47:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 11:47:14 +0000
Subject: [issue38733] PyErr_Occurred(): tstate must be non-NULL
In-Reply-To: <1573118972.06.0.487473179974.issue38733@roundup.psfhosted.org>
Message-ID: <1573127234.15.0.00755256522004.issue38733@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I merged my change, I close the issue.

The change is a little bit backward incompatible, so I prefer to not backport it. PyErr_Occurred() checks tstate==NULL for 9 years, there is no urgency to change it :-) It can wait for Python 3.9.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38733>
_______________________________________

From report at bugs.python.org  Thu Nov  7 07:06:03 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Thu, 07 Nov 2019 12:06:03 +0000
Subject: [issue38735] PYTHONPYCACHEPREFIX fails when importing a module from
 the root ("/")
Message-ID: <1573128363.33.0.885325437125.issue38735@roundup.psfhosted.org>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

On the manylinux docker images, the current directory is "/".

If I create a file there and try to import it with PYTHONPYCACHEPREFIX set, I get a stack trace:

$ docker run -it --init --rm -v `pwd`:/io quay.io/pypa/manylinux1_x86_64 bash
[root at 29d75403d7d1 /]# cat > foo.py
a = 1
[root at 29d75403d7d1 /]# /opt/python/cp38-cp38/bin/python
Python 3.8.0 (default, Oct 30 2019, 22:13:22)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
>>> foo.a
1
>>>
[root at 29d75403d7d1 /]# PYTHONPYCACHEPREFIX=/opt/pyc /opt/python/cp38-cp38/bin/python
Python 3.8.0 (default, Oct 30 2019, 22:13:22)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 657, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 562, in module_from_spec
  File "<frozen importlib._bootstrap>", line 541, in _init_module_attrs
  File "<frozen importlib._bootstrap>", line 382, in cached
  File "<frozen importlib._bootstrap_external>", line 427, in _get_cached
  File "<frozen importlib._bootstrap_external>", line 352, in cache_from_source
IndexError: string index out of range
>>>

----------
messages: 356188
nosy: nedbat
priority: normal
severity: normal
status: open
title: PYTHONPYCACHEPREFIX fails when importing a module from the root ("/")

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38735>
_______________________________________

From report at bugs.python.org  Thu Nov  7 07:11:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 12:11:41 +0000
Subject: [issue38735] PYTHONPYCACHEPREFIX fails when importing a module from
 the root ("/")
In-Reply-To: <1573128363.33.0.885325437125.issue38735@roundup.psfhosted.org>
Message-ID: <1573128701.35.0.513653491347.issue38735@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The bug occurs on this line:

    if sys.pycache_prefix is not None:
        if not _path_isabs(head):
            head = _path_join(_os.getcwd(), head)
        if head[1] == ':' and head[0] not in path_separators: # <==== HERE
            head = head[2:]
        ...

I guess that head="/" in your case: so head[1] raises an IndexError.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38735>
_______________________________________

From report at bugs.python.org  Thu Nov  7 07:46:29 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Nov 2019 12:46:29 +0000
Subject: [issue38732] Adding relp support as a new logging handler
In-Reply-To: <1573116123.59.0.255595636575.issue38732@roundup.psfhosted.org>
Message-ID: <1573130789.43.0.0936001808831.issue38732@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Why does this need to be in the stdlib, useful though it may be for some use cases? As I understand it, RELP is mainly for communication between rsyslog servers, not specifically/especially for client-rsyslog communication. From the PyRELP link you posted, that library doesn't seem to support Python 3.x. Also, the fact that it relies on an optional OS package (librelp) makes it unsuitable for inclusion in the stdlib.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38732>
_______________________________________

From report at bugs.python.org  Thu Nov  7 07:46:50 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Nov 2019 12:46:50 +0000
Subject: [issue38716] logging: rotating handlers set namer and rotator null
In-Reply-To: <1573032912.48.0.408728963846.issue38716@roundup.psfhosted.org>
Message-ID: <1573130810.73.0.596142695441.issue38716@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38716>
_______________________________________

From report at bugs.python.org  Thu Nov  7 09:57:49 2019
From: report at bugs.python.org (Juliette Monsel)
Date: Thu, 07 Nov 2019 14:57:49 +0000
Subject: [issue38661] Changes to tkinter result in (unexpected) widget map
 call return changes wrt. 3.7
In-Reply-To: <1572618747.95.0.320564330748.issue38661@roundup.psfhosted.org>
Message-ID: <1573138669.95.0.200579211308.issue38661@roundup.psfhosted.org>


Change by Juliette Monsel <j_4321 at protonmail.com>:


----------
nosy: +j-4321-i

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38661>
_______________________________________

From report at bugs.python.org  Thu Nov  7 10:06:35 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 15:06:35 +0000
Subject: [issue38730] 2.7 modern compiler warnings
In-Reply-To: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>
Message-ID: <1573139195.33.0.61920066128.issue38730@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset f32bcf8c27f3681407707bbb029323eb340d3c4b by Benjamin Peterson in branch '2.7':
[2.7] bpo-38730: Fix -Wstringop-truncation warnings. (GH-17075)
https://github.com/python/cpython/commit/f32bcf8c27f3681407707bbb029323eb340d3c4b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38730>
_______________________________________

From report at bugs.python.org  Thu Nov  7 10:14:52 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 15:14:52 +0000
Subject: [issue38730] 2.7 modern compiler warnings
In-Reply-To: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>
Message-ID: <1573139692.98.0.422142117668.issue38730@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +16591
pull_request: https://github.com/python/cpython/pull/17081

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38730>
_______________________________________

From report at bugs.python.org  Thu Nov  7 10:27:12 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 15:27:12 +0000
Subject: [issue38730] 2.7 modern compiler warnings
In-Reply-To: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>
Message-ID: <1573140432.79.0.310537680384.issue38730@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 9f94e52e8d38092520a3bfb1bf1ef9cbb0836584 by Benjamin Peterson in branch '2.7':
bpo-38730: Remove usage of stpncpy as it's not supported on MSVC 2008. (GH-17081)
https://github.com/python/cpython/commit/9f94e52e8d38092520a3bfb1bf1ef9cbb0836584


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38730>
_______________________________________

From report at bugs.python.org  Thu Nov  7 10:37:20 2019
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 07 Nov 2019 15:37:20 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573141040.14.0.737396279381.issue36906@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Excuse me for the spam, but against make it the default behavior I have a simple consideration: what will expect a person that reads the code, that doesn't know Python?

IMHO it expects that the string is *exactly* like it's written. The fact that it will be de-dented it's a bit surprising.

For readability and for not breaking old code, I continue to be in favor of a letter before the multi-string. Maybe `d`, for de-dent, it's more appropriate than `t`, since it does not only trim the string.

But probably there's a better solution than the letter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Thu Nov  7 10:40:47 2019
From: report at bugs.python.org (=?utf-8?q?Erik_Ahl=C3=A9n?=)
Date: Thu, 07 Nov 2019 15:40:47 +0000
Subject: [issue38736] argparse: wrong type from get_default when type is set
Message-ID: <1573141247.89.0.957889061173.issue38736@roundup.psfhosted.org>


New submission from Erik Ahl?n <erik.ahlen at gmail.com>:

The type of the object returned by get_default isn't converted to the specified type supplied to add_argument. I would expect the type to be the same.

----------
components: Library (Lib)
files: test.py
messages: 356194
nosy: Erik Ahl?n
priority: normal
severity: normal
status: open
title: argparse: wrong type from get_default when type is set
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file48700/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38736>
_______________________________________

From report at bugs.python.org  Thu Nov  7 10:59:10 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 07 Nov 2019 15:59:10 +0000
Subject: [issue38613] Optimize some set operations in dictkeys object
In-Reply-To: <1572263745.15.0.0692968844895.issue38613@roundup.psfhosted.org>
Message-ID: <1573142350.14.0.7174477709.issue38613@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 6cbc84fb99acb33dd659d7adb29a20adbe62b74a by Inada Naoki in branch 'master':
bpo-38613: Optimize set operations of dict keys. (GH-16961)
https://github.com/python/cpython/commit/6cbc84fb99acb33dd659d7adb29a20adbe62b74a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38613>
_______________________________________

From report at bugs.python.org  Thu Nov  7 10:59:26 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 07 Nov 2019 15:59:26 +0000
Subject: [issue38613] Optimize some set operations in dictkeys object
In-Reply-To: <1572263745.15.0.0692968844895.issue38613@roundup.psfhosted.org>
Message-ID: <1573142366.68.0.870378057214.issue38613@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38613>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:01:05 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Thu, 07 Nov 2019 16:01:05 +0000
Subject: [issue36876] Global C variables are a problem.
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1573142465.27.0.042889041795.issue36876@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy:  -yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:02:10 2019
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 07 Nov 2019 16:02:10 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573142530.6.0.987532476638.issue38500@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Victor,
I don't think this is a regression.
`PyThreadState` is an internal opaque data structure, which means we are free to change it.
That the `eval_frame` is hard to access is a feature not a bug, as it discourages misuse and enables us to remove it easily, when a better approach becomes available.

PEP 523 is quite vague, but the rationale indicates that exposing `eval_frame` is for "a method-level JIT". PEP 523 did not suggest adding an API. If it had (and I had had the time) I would have opposed it more vigorously.

IMO, the correct way to change the code object is to set `function.__code__` which can be done easily from either Python or C code.

@Fabioz, is there anything preventing you from doing that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:14:46 2019
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 07 Nov 2019 16:14:46 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573143286.84.0.992475669212.issue38500@roundup.psfhosted.org>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

@Mark I don't want to change the original function code, I just want to change the code to be executed in the frame (i.e.: as breakpoints change things may be different).

Changing the actual function code is a no-go since changing the real function code can break valid user code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:19:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Nov 2019 16:19:28 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573143568.43.0.250935909342.issue36906@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The user expects what they read in the documentation of what they learn in other programming languages. If we update the documentation their expectation will change.

As for other programming languages, Bash has an option for stripping all leading tab characters from a here document, and in Julia triple-quoted strings are dedented (https://docs.julialang.org/en/v1/manual/strings/#Triple-Quoted-String-Literals-1). Since Julia is a competitor of Python in science applications, I think that significant fraction of Python users expected Python triple-quoted strings be dedented too, especially if they are dedented by help() and other tools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:24:52 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Nov 2019 16:24:52 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1573143892.39.0.633826001487.issue2986@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +16592
pull_request: https://github.com/python/cpython/pull/17082

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:30:51 2019
From: report at bugs.python.org (maciozo)
Date: Thu, 07 Nov 2019 16:30:51 +0000
Subject: [issue31842] pathlib: "Incorrect function" during resolve()
In-Reply-To: <1508707873.05.0.213398074469.issue31842@psf.upfronthosting.co.za>
Message-ID: <1573144251.0.0.607582333111.issue31842@roundup.psfhosted.org>


maciozo <maciozo at maciozo.com> added the comment:

Same error occurs when attempting to resolve a path on an ImDisk RAM disk:

>>> pathlib.Path("T:\\").resolve()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Users\maciozo\AppData\Local\Continuum\miniconda3\envs\brainboxes\lib\pathlib.py", line 1151, in resolve
    s = self._flavour.resolve(self, strict=strict)
  File "C:\Users\maciozo\AppData\Local\Continuum\miniconda3\envs\brainboxes\lib\pathlib.py", line 202, in resolve
    s = self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 1] Incorrect function: 'T:\\'

----------
nosy: +maciozo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31842>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:37:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 16:37:22 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573144642.64.0.583158745228.issue38500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

By the way, it's still possible to access directly ts->interp if you include "pycore_pystate.h" header, which requires to define Py_BUILD_CORE_MODULE. This header is an internal header.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:38:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 16:38:36 +0000
Subject: [issue36084] Threading: add builtin TID attribute to Thread objects
In-Reply-To: <1550875571.41.0.297490361597.issue36084@roundup.psfhosted.org>
Message-ID: <1573144716.63.0.136001558793.issue36084@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Jake created bpo-38707.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36084>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:46:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 16:46:51 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1573145211.24.0.873564266803.issue38707@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> See the branch here: https://github.com/jaketesler/cpython/tree/fix-mp-native-id

Can you please create a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:48:26 2019
From: report at bugs.python.org (Ben Reilly)
Date: Thu, 07 Nov 2019 16:48:26 +0000
Subject: [issue30587] Mock with spec object does not ensure method call
 signatures
In-Reply-To: <1496837046.98.0.920527641247.issue30587@psf.upfronthosting.co.za>
Message-ID: <1573145306.24.0.985677192597.issue30587@roundup.psfhosted.org>


Change by Ben Reilly <breilly at box.com>:


----------
nosy: +breilly_box

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30587>
_______________________________________

From report at bugs.python.org  Thu Nov  7 11:51:55 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Nov 2019 16:51:55 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573145515.72.0.478704361755.issue36906@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Julia syntax looks well thought out, so I suggest to borrow it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Thu Nov  7 12:48:33 2019
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 07 Nov 2019 17:48:33 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1573148913.53.0.872702592291.issue36906@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

When Python started to emulate the other languages?

Who cares about what other languages do? Python uses `raise` instead of `throw`, even if `throw` is much more popular in the most used languages, only because `raise` in English has more sense. 

And IMHO a newbie that see a multi-string in the code does not read the documentation. It's evident that is a multi-string. And it expects that it acts as in English or any other written language, that is the text is *that* one that (s)he read.

On the contrary, if (s)he reads 

d"""
   Marco
   Sulla
"""

maybe (s)he thinks "this must be something different", and read the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________

From report at bugs.python.org  Thu Nov  7 12:52:55 2019
From: report at bugs.python.org (Anders Lorentsen)
Date: Thu, 07 Nov 2019 17:52:55 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1573149175.76.0.612801222166.issue38673@roundup.psfhosted.org>


Anders Lorentsen <phaqui at gmail.com> added the comment:

As a person without much experience, it sounded like a simple enough task, but having dug a bit, I found it quite complicated. It seems to me that the interpreter loop (in the standard REPL, that you get when you start ./python, blocks for input somewhere inside a massive function called 'parsetok' (in Parser/parsetok.c). Now, I could maybe investigate further, to have it return to the interpreter loop if it reads a comment (or empty line), but I'm afraid to mess up something.

>From my understanding, there aren't that many other choices, because parsetok() doesn't return before you finish the statement (in other words, it does not return if you type a comment line or a blank line - it instead waits for more input, as indicated by the '... ').

Am I way off in concluding that this would be a change to the parser?

----------
nosy: +Phaqui

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Thu Nov  7 13:13:43 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Nov 2019 18:13:43 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573150423.54.0.986449454964.issue38706@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Terry]

> A correct failure message, correct both as English and Python, should be something like 'bool(x) is not True'.  I see 'x is not true' as an informal English equivalent of the full claim.

I'm not clear whether you're suggesting having something like "bool(x) is not True" be the actual failure message, but if you are, that makes a lot of sense to me. (My current advice to coworkers is always to include the "msg" attribute when using assertTrue and assertFalse, because the default message tends to be spectacularly unhelpful.)

-1 on introducing the terms "truthy" and "falsy" (or "falsey"?) into this one corner of Python. Given that those terms don't seem to be used elsewhere in the codebase, I'd expect introducing them here to cause more confusion, rather than less.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Thu Nov  7 13:31:50 2019
From: report at bugs.python.org (Anthony Baire)
Date: Thu, 07 Nov 2019 18:31:50 +0000
Subject: [issue38737] StreamReaderProtocol.eof_received() should return True
 only for _SSLProtocolTransport
Message-ID: <1573151510.94.0.566528932469.issue38737@roundup.psfhosted.org>


New submission from Anthony Baire <ayba at free.fr>:

We developed an alternate asyncio TLS transport based on GnuTLS (https://pypi.org/project/aio-gnutls-transport/). In this project we want to support half-closed TLS connections (WriteTransport.write_eof()).


Unfortunately StreamReaderProtocol won't interoperate properly without a monkey patch because its eof_received() method returns True for any ssl transport (this is to avoid a warning in the _SSLProtocolTransport):

    def eof_received(self):
        self._stream_reader.feed_eof()
        if self._over_ssl:
            # Prevent a warning in SSLProtocol.eof_received:
            # "returning true from eof_received()
            # has no effect when using ssl"
            return False
        return True

As this is an unspecified internal feature, very specific to the _SSLProtocolTransport class (which issues the warning), we think the test should be made explicitly against this class (see the attached patch).

----------
components: asyncio
files: eof-received-over-ssl.diff
keywords: patch
messages: 356207
nosy: aba, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: StreamReaderProtocol.eof_received() should return True only for _SSLProtocolTransport
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48701/eof-received-over-ssl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38737>
_______________________________________

From report at bugs.python.org  Thu Nov  7 13:48:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Nov 2019 18:48:13 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573152493.26.0.00623845656012.issue38706@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In some cases "a true value" and "a false value" are used in the documentation. But in most cases it is just "true" and "false".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Thu Nov  7 14:16:13 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 07 Nov 2019 19:16:13 +0000
Subject: [issue38737] StreamReaderProtocol.eof_received() should return True
 only for _SSLProtocolTransport
In-Reply-To: <1573151510.94.0.566528932469.issue38737@roundup.psfhosted.org>
Message-ID: <1573154173.96.0.780057795959.issue38737@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

StreamReaderProtocol is tightly coupled with builtin asyncio transports.
Even worse, it is an internal class actually.
If you want a code to operate with custom transports -- perhaps you need to reimplement streams for them as well.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38737>
_______________________________________

From report at bugs.python.org  Thu Nov  7 14:42:20 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Nov 2019 19:42:20 +0000
Subject: [issue38738] Fix formatting of True and False
Message-ID: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR fixes some issues with True and False in the documentation:

* "Return true/false" is replaced with "Return ``True``/``False``" if the function actually returns a bool.

* Fixed formatting of some True and False literals (now in monospace).

* Replaced "True/False" with "true/false" if it can be not only bool.

* Replaced some 1/0 with True/False if it corresponds the code.

----------
assignee: docs at python
components: Documentation
messages: 356210
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix formatting of True and False
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Thu Nov  7 14:43:03 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Nov 2019 19:43:03 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573155783.21.0.8768751101.issue38738@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Thu Nov  7 14:45:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Nov 2019 19:45:19 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>
Message-ID: <1573155919.7.0.967810732274.issue38706@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue38738.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38706>
_______________________________________

From report at bugs.python.org  Thu Nov  7 15:31:45 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Nov 2019 20:31:45 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573158705.93.0.910767532533.issue22367@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset befa032d8869e0fab4732d910f3887642879d644 by Serhiy Storchaka (Dong-hee Na) in branch 'master':
bpo-22367: Add tests for fcntl.lockf(). (GH-17010)
https://github.com/python/cpython/commit/befa032d8869e0fab4732d910f3887642879d644


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Thu Nov  7 15:32:27 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Nov 2019 20:32:27 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573158747.64.0.482469551042.issue22367@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16594
pull_request: https://github.com/python/cpython/pull/17084

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Thu Nov  7 15:32:35 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Nov 2019 20:32:35 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573158755.76.0.732224961269.issue22367@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16595
pull_request: https://github.com/python/cpython/pull/17085

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Thu Nov  7 16:11:15 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Nov 2019 21:11:15 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1573161075.81.0.106232621478.issue16576@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Thu Nov  7 17:11:39 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 07 Nov 2019 22:11:39 +0000
Subject: [issue38608] Undocumented behavior that IsolatedAsyncioTestCase would
 enable event loop debug mode
In-Reply-To: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>
Message-ID: <1573164699.6.0.163472918932.issue38608@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Slower by percents, not in the factor of times.

I guess for tests it is satisfactory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38608>
_______________________________________

From report at bugs.python.org  Thu Nov  7 17:46:49 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Nov 2019 22:46:49 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1573166809.58.0.0821095977085.issue38673@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Yes, that's likely where the change should be made.

I think if the *first* token encountered is either NL or COMMENT the parse should be abandoned by the tokenizer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Thu Nov  7 18:13:29 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 Nov 2019 23:13:29 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573168409.27.0.269288464161.issue38500@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

PEP 523 was to give user code the ability to change the eval function. While the work was motivated by our JIT work, supporting debugging was another motivating factor: https://www.python.org/dev/peps/pep-0523/#debugging. There's no C API because at the time there was no need as PyInterpreterState was publicly exposed.

I don't think anyone is suggesting to add something to the stable ABI, so this comes down to whether this should be exposed as part of the CPython API or the publicly accessible internal API. Since there is no distinction of "you probably don't want to use this but we won't yank it out from underneath" you I think this belongs in the CPython API somehow. Otherwise someone should propose withdrawing PEP 523 as I think that shifts what the PEP was aiming for. You can also ask on python-dev or the steering council (which I will abstain myself from due to being a co-author of PEP 523).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov  7 18:44:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 23:44:26 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573170266.81.0.117904896162.issue38500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I heard that for debuggers, the PEP 523 is really useful. I recall a huge speedup thanks to this PEP in Jetbrain:
https://blog.jetbrains.com/pycharm/2017/03/inside-the-debugger-interview-with-elizaveta-shashkova/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov  7 19:24:04 2019
From: report at bugs.python.org (Jake Tesler)
Date: Fri, 08 Nov 2019 00:24:04 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1573172644.73.0.157947972964.issue38707@roundup.psfhosted.org>


Change by Jake Tesler <jake.tesler at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Thu Nov  7 19:33:45 2019
From: report at bugs.python.org (Jake Tesler)
Date: Fri, 08 Nov 2019 00:33:45 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1573173225.04.0.587388355871.issue38707@roundup.psfhosted.org>


Jake Tesler <jake.tesler at gmail.com> added the comment:

@vstinner PR created :)
https://github.com/python/cpython/pull/17088

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Thu Nov  7 20:30:55 2019
From: report at bugs.python.org (Travis Lazar)
Date: Fri, 08 Nov 2019 01:30:55 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
Message-ID: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>


New submission from Travis Lazar <travis.lazar at gmail.com>:

When running pyperformance html5lib test, the application crashes with "ImportError: cannot import name 'Mapping' from 'collections' (/py3buildpath/lib/python3.9/collections/__init__.py)"

To reproduce:

1 - Build Python from source. I produced with git commit befa032d8869e0fab4732d910f3887642879d644 from cpython GitHub.

2 - Run pyperformance with: /py3buildpath/bin/pyperformance run --python=/py3buildpath/bin/python3 --venv venvpath -b html5lib -o output.json

3 - Immediate crash is seen with message:

#!/bin/sh
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/html5lib/_tokenizer.py", line 16, in <module>
    from ._trie import Trie
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/html5lib/_trie/__init__.py", line 3, in <module>
    from .py import Trie as PyTrie
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/html5lib/_trie/py.py", line 6, in <module>
    from ._base import Trie as ABCTrie
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/html5lib/_trie/_base.py", line 3, in <module>
    from collections import Mapping
ImportError: cannot import name 'Mapping' from 'collections' (/root/py3-tot-no/lib/python3.9/collections/__init__.py)
ERROR: Benchmark html5lib failed: Benchmark died
Traceback (most recent call last):
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/pyperformance/run.py", line 132, in run_benchmarks
    bench = func(cmd_prefix, options)
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/pyperformance/benchmarks/__init__.py", line 244, in BM_html5lib
    return run_perf_script(python, options, "html5lib")
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/pyperformance/run.py", line 98, in run_perf_script
    run_command(cmd, hide_stderr=not options.verbose)
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/pyperformance/run.py", line 66, in run_command
    raise RuntimeError("Benchmark died")
RuntimeError: Benchmark died

----------
components: Tests
messages: 356219
nosy: Travis Lazar
priority: normal
severity: normal
status: open
title: pyperformance html5lib cannot import Mapping (and fails)
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Thu Nov  7 20:31:41 2019
From: report at bugs.python.org (Travis Lazar)
Date: Fri, 08 Nov 2019 01:31:41 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
In-Reply-To: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>
Message-ID: <1573176701.31.0.270641931159.issue38739@roundup.psfhosted.org>


Travis Lazar <travis.lazar at gmail.com> added the comment:

Forgot to include that this was built on an aarch64 (Ampere eMAG) system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Thu Nov  7 21:18:28 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 08 Nov 2019 02:18:28 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
In-Reply-To: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>
Message-ID: <1573179508.92.0.309756792737.issue38739@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

collections removed ABC access in 3.9. It seems you are using an older version of pip. Please update to the latest version which has the vendored html5lib package fixed.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Thu Nov  7 22:31:29 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Nov 2019 03:31:29 +0000
Subject: [issue38730] 2.7 modern compiler warnings
In-Reply-To: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>
Message-ID: <1573183889.56.0.753923198949.issue38730@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38730>
_______________________________________

From report at bugs.python.org  Thu Nov  7 22:42:12 2019
From: report at bugs.python.org (paul j3)
Date: Fri, 08 Nov 2019 03:42:12 +0000
Subject: [issue38736] argparse: wrong type from get_default when type is set
In-Reply-To: <1573141247.89.0.957889061173.issue38736@roundup.psfhosted.org>
Message-ID: <1573184532.51.0.411266941541.issue38736@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

get_default just returns the default attribute as it is stored in the Action.   Defaults are stored as given. 

During parsing the Action's default is placed in the args namespace at the start.  At the end, it checks if the value in the namespace is a string that matches the default (i.e. has been over written by user input).  Only then is it passed through the type function.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38736>
_______________________________________

From report at bugs.python.org  Thu Nov  7 23:23:02 2019
From: report at bugs.python.org (Gustavo)
Date: Fri, 08 Nov 2019 04:23:02 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1573186982.27.0.678016924973.issue32545@roundup.psfhosted.org>


Gustavo <augussee at yahoo.com> added the comment:

I was able to fix this problem quickly following these easy guide:

First, you need to press the keys Win + R to open the Run dialog, there type the command msiexec /unreg and hit Enter
Now, open the Run dialog again and this time, type the command msiexec /regserver, then hit Enter
Finally, try to install python again.

I found this guide on https://windowshelper.co

----------
nosy: +gustavoxo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Fri Nov  8 01:01:02 2019
From: report at bugs.python.org (Thamme Gowda)
Date: Fri, 08 Nov 2019 06:01:02 +0000
Subject: [issue38740] Line count mis match between open() vs sys.stdin api
 calls
Message-ID: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>


New submission from Thamme Gowda <tgowdan at gmail.com>:

I ran into a line count mismatch bug and I narrowed it down to 9 lines where the line break handling is causing an issue. Please find the attachment named line_break_err.txt to reproduce the below. 


$ md5sum line_break_err.txt
5dea501b8e299a0ece94d85977728545  line_break_err.txt

# wc says there are 9 lines
$ wc -l line_break_err.txt
9 line_break_err.txt

# if I read from sys.stdin, I get 9 lines
$ python -c 'import sys; print(sum(1 for x in sys.stdin))' < line_break_err.txt

# but... if I use a open() call, i get 18 
$ python -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1])))' line_break_err.txt
Linecount= 18

# changing encoding or error handling has no effect
$ python -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1], "r", encoding="utf-8", errors="replace")))' line_break_err.txt
Linecount= 18

$ python -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1], "r", encoding="utf-8", errors="ignore")))' line_break_err.txt
Linecount= 18
# but, not just wc, even awk says there are only 9 lines
$ awk 'END {print "Linecount=", NR}' line_break_err.txt
Linecount= 9

# let's see python 2 using io
# python2 -c 'import sys,io; print("Linecount=", sum(1 for x in io.open(sys.argv[1],  encoding="ascii", errors="ignore")))' line_break_err.txt
('Linecount=', 18)

# But this one which we no longer use somehow gets it right
$ python2 -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1])))' line_break_err.txt
('Linecount=', 9)


Tested it on 
1. Linux 
Python 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 21:52:21)
[GCC 7.3.0] :: Anaconda, Inc. on linux


2. OSX
Python 3.7.3 (default, Mar 27 2019, 16:54:48)
[Clang 4.0.1 (tags/RELEASE_401/final)] :: Anaconda, Inc. on darwin

3. python 2 on OSX
Python 2.7.16 (default, Jun 19 2019, 07:40:37)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)] on darwin

---- 

P.S. 
this is my first issue created. If this issue is a duplicate, I am happy to close it.

----------
components: IO, Library (Lib), Unicode
messages: 356224
nosy: Thamme Gowda, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Line count mis match between open() vs sys.stdin api calls
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38740>
_______________________________________

From report at bugs.python.org  Fri Nov  8 01:01:54 2019
From: report at bugs.python.org (Thamme Gowda)
Date: Fri, 08 Nov 2019 06:01:54 +0000
Subject: [issue38740] Line count mis match between open() vs sys.stdin api
 calls
In-Reply-To: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>
Message-ID: <1573192914.94.0.766505555576.issue38740@roundup.psfhosted.org>


Change by Thamme Gowda <tgowdan at gmail.com>:


Added file: https://bugs.python.org/file48702/line_break_err.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38740>
_______________________________________

From report at bugs.python.org  Fri Nov  8 01:07:52 2019
From: report at bugs.python.org (Mark)
Date: Fri, 08 Nov 2019 06:07:52 +0000
Subject: [issue38741] Definition of multiple ']' in header configparser
Message-ID: <1573193272.74.0.118296138456.issue38741@roundup.psfhosted.org>


New submission from Mark <mark-smirnow at ya.ru>:

in example header is "[i love [python] lang]"
parse as "i love [python", only up to the first character ']'.

now saving works correctly, but reading does not

----------
messages: 356225
nosy: @mark99i
priority: normal
severity: normal
status: open
title: Definition of multiple ']' in header configparser
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38741>
_______________________________________

From report at bugs.python.org  Fri Nov  8 01:30:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 08 Nov 2019 06:30:47 +0000
Subject: [issue38729] mock.create_autospec generates incorrect signature for
 some decorated methods
In-Reply-To: <1573081188.35.0.210639381989.issue38729@roundup.psfhosted.org>
Message-ID: <1573194647.6.0.197747408334.issue38729@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

If I understand this correctly, when an autospec of a class is created the attributes themselves of the given class are autospecced. During autospec of attributes it's modelled upon __call__'s signature for the given attributes [0]. Here you are wrapping the method's inside a class with Wrapper with a custom __call__ implementation. During actual calls the chain goes through __call__ and executes __get__ where bound method is called. But in mock I am not sure of a way where it can figure out __call__ and then look more into the body to see if there are actual calls being made to be mocked with current implementation just going through signature of __call__.

[0] https://github.com/python/cpython/blob/befa032d8869e0fab4732d910f3887642879d644/Lib/unittest/mock.py#L94

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38729>
_______________________________________

From report at bugs.python.org  Fri Nov  8 01:34:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 08 Nov 2019 06:34:55 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
In-Reply-To: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>
Message-ID: <1573194895.36.0.772564532398.issue38739@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sorry, I misread the traceback itself as if it's from pip. It's from html5lib being incompatible with 3.9 as per the latest release on 1.0.1 (Dec 7, 2017) . There is an issue to request new release with the fix at https://github.com/html5lib/html5lib-python/issues/419 . Maybe you can try building html5lib from their master branch to be used in pyperformance. I would propose closing it as third party.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Fri Nov  8 03:05:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Nov 2019 08:05:07 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
In-Reply-To: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>
Message-ID: <1573200307.2.0.0525360134692.issue38739@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I fixed the issue by disabling temporarily the benchmark, until html5lib is fixed:
https://github.com/python/pyperformance/commit/8043c159215836fa733ee0815feecdd359e8852a

--

That's Python bug tracker. The pyperformance bug tracker is at:
https://github.com/python/pyperformance/issues

Your issue is that "import html5lib" fails on Python 3.9 because there is no html5lib release including the fix:
https://github.com/html5lib/html5lib-python/issues/419

The bug has already been fixed in html5lib.

One workaround would be to disable htmllib benchmark on Python 3.9 until https://github.com/html5lib/html5lib-python/issues/419 is fixed.

--

> collections removed ABC access in 3.9.

That's bpo-25988 with commit ef092fe9905f61ca27889092ca1248a11aa74498.

--

pip backported the html5lib patch:
https://github.com/pypa/pip/commit/ef7ca1472c1fdd085cffb8183b7ce8abbe9e2800#diff-2496ad1eedee846e323ed2916d6c2d24

The fix is included in pip since pip 19.3.1.

Note: The ensurepip module of the master branch of Python uses a bundled copy of pip 19.2.3.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Fri Nov  8 03:05:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Nov 2019 08:05:19 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
In-Reply-To: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>
Message-ID: <1573200319.04.0.563700713107.issue38739@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Fri Nov  8 03:10:53 2019
From: report at bugs.python.org (yucheng chen)
Date: Fri, 08 Nov 2019 08:10:53 +0000
Subject: [issue38742] ElementTree won't parse comments before root element
Message-ID: <1573200653.57.0.472898795822.issue38742@roundup.psfhosted.org>


New submission from yucheng chen <celinecyc1996 at gmail.com>:

issue8277
It couldn't work for those comments before the root element. 
It will raise an error that "xml.etree.ElementTree.ParseError: multiple elements on top level". 

Example:

test.xml
--------
<?xml version="1.0" encoding="utf-8"?>
<!-- comments here doesn't work -->
<root node>
  <nodeA />
  <!-- comments here is ok -->
  <nodeB />
</root node>

test.py
-------
from xml.etree import ElementTree
class MyTreeBuilder(ElementTree.TreeBuilder):
   def comment(self, data):
       self.start(ElementTree.Comment, {})
       self.data(data)
       self.end(ElementTree.Comment)
with open('c:/temp/t.xml', 'r') as f:
   xml = ElementTree.parse(
       f, parser=ElementTree.XMLParser(target=MyTreeBuilder()))
ElementTree.dump(xml)

----------
components: XML
messages: 356229
nosy: amaury.forgeotdarc, effbot, flox, poke, scoder, yucheng chen
priority: normal
severity: normal
status: open
title: ElementTree won't parse comments before root element
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38742>
_______________________________________

From report at bugs.python.org  Fri Nov  8 03:14:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Nov 2019 08:14:56 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1573200896.35.0.968228995132.issue16575@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

3.7 refleaks buildbots pass again (ignoring a few warnings).

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Fri Nov  8 03:30:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Nov 2019 08:30:43 +0000
Subject: [issue38740] Line count mis match between open() vs sys.stdin api
 calls
In-Reply-To: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>
Message-ID: <1573201843.8.0.449674457943.issue38740@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Try to add newline="\n" in open().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38740>
_______________________________________

From report at bugs.python.org  Fri Nov  8 04:04:49 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 08 Nov 2019 09:04:49 +0000
Subject: [issue38740] Line count mis match between open() vs sys.stdin api
 calls
In-Reply-To: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>
Message-ID: <1573203889.87.0.675640434983.issue38740@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This seems to be the difference between Universal Newlines or not. In Python 2, you have to set it explicitly with a U in the open mode:

    $ python2.7 -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1], "Ur")))' line_break_err.txt
    ('Linecount=', 18)

In Python 3, Universal Newlines is the default for text files, but you can control it with the ``newline`` parameter:

    $ python3.5 -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1], newline="\n")))' line_break_err.txt
    Linecount= 9


    $ python3.5 -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1], newline="\r")))' line_break_err.txt
    Linecount= 15


I think this explains the difference you are seeing. Do you agree?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38740>
_______________________________________

From report at bugs.python.org  Fri Nov  8 04:04:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Nov 2019 09:04:57 +0000
Subject: [issue38276] test_asyncio:
 test_cancel_make_subprocess_transport_exec() failed on RHEL7 LTO + PGO 3.x
In-Reply-To: <1569416953.01.0.173802643321.issue38276@roundup.psfhosted.org>
Message-ID: <1573203897.04.0.724173047144.issue38276@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Timeout on the Ubuntu job of Azure Pipelines:

https://dev.azure.com/Python/cpython/_build/results?buildId=53629&view=logs&j=256d7e09-002a-52d7-8661-29ee3960640e

0:27:55 load avg: 0.11 [419/419/2] test_asyncio crashed (Exit code 1)
Timeout (0:20:00)!
Thread 0x00007fe2c4fdf700 (most recent call first):
  File "/home/vsts/work/1/s/Lib/selectors.py", line 468 in select
  File "/home/vsts/work/1/s/Lib/asyncio/base_events.py", line 1837 in _run_once
  File "/home/vsts/work/1/s/Lib/asyncio/base_events.py", line 589 in run_forever
  File "/home/vsts/work/1/s/Lib/asyncio/base_events.py", line 621 in run_until_complete
  File "/home/vsts/work/1/s/Lib/test/test_asyncio/test_subprocess.py", line 440 in test_cancel_make_subprocess_transport_exec
  File "/home/vsts/work/1/s/Lib/unittest/case.py", line 616 in _callTestMethod

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38276>
_______________________________________

From report at bugs.python.org  Fri Nov  8 04:05:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Nov 2019 09:05:25 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573203925.38.0.671877561775.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7e433733175e76627d46ed9bdab543860cd1452d by Victor Stinner in branch 'master':
bpo-38644: Add _PyObject_VectorcallTstate() (GH-17052)
https://github.com/python/cpython/commit/7e433733175e76627d46ed9bdab543860cd1452d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Nov  8 04:48:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Nov 2019 09:48:10 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573206490.69.0.122971976438.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16598
pull_request: https://github.com/python/cpython/pull/17089

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Nov  8 05:12:36 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 08 Nov 2019 10:12:36 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573207956.08.0.747650911304.issue38692@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

I got a failure in newly added test_pidfd_open:

======================================================================
FAIL: test_pidfd_open (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python-git/src/cpython/Lib/test/test_posix.py", line 1479, in test_pidfd_open
    self.assertEqual(cm.exception.errno, errno.EINVAL)
AssertionError: 1 != 22

----------------------------------------------------------------------

I'm running kernel 5.3.7-x86_64-linode130 with Arch Linux. At first I suspect that it's related to system call filters from systemd as tests are run in a systemd-nspawn container. However, there are still failures after patching systemd with https://github.com/systemd/systemd/commit/9e486265716963439fb0fd7f2a97abf109f24f75.

How about also skipping the test if pidfd_open returns EPERM?

----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Fri Nov  8 05:20:59 2019
From: report at bugs.python.org (=?utf-8?q?Erik_Ahl=C3=A9n?=)
Date: Fri, 08 Nov 2019 10:20:59 +0000
Subject: [issue38736] argparse: wrong type from get_default when type is set
In-Reply-To: <1573141247.89.0.957889061173.issue38736@roundup.psfhosted.org>
Message-ID: <1573208459.26.0.274841769032.issue38736@roundup.psfhosted.org>


Erik Ahl?n <erik.ahlen at gmail.com> added the comment:

So, not a bug since you can just do `default = Path('file.txt')`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38736>
_______________________________________

From report at bugs.python.org  Fri Nov  8 06:34:01 2019
From: report at bugs.python.org (=?utf-8?q?Jakub_Piotr_C=C5=82apa?=)
Date: Fri, 08 Nov 2019 11:34:01 +0000
Subject: [issue38743] configure: on macOS (darwin) add CoreFoundation to flags
 before checking for gettext
Message-ID: <1573212841.11.0.0393862101681.issue38743@roundup.psfhosted.org>


New submission from Jakub Piotr C?apa <jpc at loee.pl>:

macOS needs to link to CoreFoundation for gettext to work. We reorder the autoconf tests so CoreFoundation is added to LIBS earlier and the -lintl test does not fail (which would exclude it from the final set of flags).

Btw. the whole test seems fishy: if compilation fails it does not mean -lintl is not needed, for this we would need to test a gettext function without -lintl. Basically two tests (with and without -lintl) are needed to properly diagnose the situation. The test in question had been written in 2009 as a fix for the https://bugs.python.org/issue6154 bug report.

This may be an issue only with non-Framework builds (since Homebrew manages to build a framework-based Python on macOS without any special shenigans) but I had not tested it.

----------
components: Build
messages: 356237
nosy: Jakub Piotr C?apa
priority: normal
severity: normal
status: open
title: configure: on macOS (darwin) add CoreFoundation to flags before checking for gettext
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38743>
_______________________________________

From report at bugs.python.org  Fri Nov  8 06:36:53 2019
From: report at bugs.python.org (=?utf-8?q?Jakub_Piotr_C=C5=82apa?=)
Date: Fri, 08 Nov 2019 11:36:53 +0000
Subject: [issue38743] configure: on macOS (darwin) add CoreFoundation to flags
 before checking for gettext
In-Reply-To: <1573212841.11.0.0393862101681.issue38743@roundup.psfhosted.org>
Message-ID: <1573213013.76.0.61558351737.issue38743@roundup.psfhosted.org>


Change by Jakub Piotr C?apa <jpc at loee.pl>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38743>
_______________________________________

From report at bugs.python.org  Fri Nov  8 06:53:22 2019
From: report at bugs.python.org (Matthias Schoepfer)
Date: Fri, 08 Nov 2019 11:53:22 +0000
Subject: [issue36852] Python3.7.2 fails to cross-compile (yocto /
 openembedded) when target is mips softfloat
In-Reply-To: <1557331268.61.0.662119534756.issue36852@roundup.psfhosted.org>
Message-ID: <1573214002.88.0.228151693743.issue36852@roundup.psfhosted.org>


Matthias Schoepfer <matthias.schoepfer at googlemail.com> added the comment:

Hi!

I submitted this patch, it even is now on yocto zeus. Any progress, will someone review it?! 

Thanks and Regards,

Matthias

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36852>
_______________________________________

From report at bugs.python.org  Fri Nov  8 06:55:53 2019
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 08 Nov 2019 11:55:53 +0000
Subject: [issue36852] Python3.7.2 fails to cross-compile (yocto /
 openembedded) when target is mips softfloat
In-Reply-To: <1557331268.61.0.662119534756.issue36852@roundup.psfhosted.org>
Message-ID: <1573214153.42.0.169438558375.issue36852@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

I'll get back on this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36852>
_______________________________________

From report at bugs.python.org  Fri Nov  8 09:20:48 2019
From: report at bugs.python.org (Emmanuel C)
Date: Fri, 08 Nov 2019 14:20:48 +0000
Subject: [issue37784] Compiling Python 3 with sqlite impossible when sqlite
 installation is in a non standard directory
In-Reply-To: <1565174815.9.0.140806109793.issue37784@roundup.psfhosted.org>
Message-ID: <1573222848.48.0.205989201498.issue37784@roundup.psfhosted.org>


Emmanuel C <emmanuel.coirier at caissedesdepots.fr> added the comment:

Sorry guy,

I've found my error : I have to use the CPPFLAGS instead of the CFLAGS in order to include sqlite3 into my own Python compiled installation.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37784>
_______________________________________

From report at bugs.python.org  Fri Nov  8 09:29:54 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 08 Nov 2019 14:29:54 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1573223394.33.0.687946947108.issue32309@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I think that I'm still not understanding something important though. Even if we initialize our ThreadPoolExecutor outside of __init__ (in a start() coroutine method, as your proposing), it seems like the threads will be spawned throughout the lifespan of the threadpool, rather than upon startup since the new threads are spawned in ThreadPoolExecutor *after* executor.submit() is called (up to max_workers) rather than upon initialization.

Correct.

> So even if an instance of ThreadPoolExecututor is initialized asynchronously within a start() coroutine method, the individual threads within it won't be spawned at the same time.

Correct.  There are a few points of this approach:

(a) design the API correctly; 
(b) ship something that definitely works with a proven ThreadPoolExecutor; 
(c) write lots of tests;
(d) write docs;
(e) if (a-d) are OK, refine the implementation later by replacing ThreadPoolExecutor with a proper (eager threads creation) implementation.

> That's why I wrote an explicit way of spawning threads in the above example, based on the way that ThreadPoolExecutor spawns threads in _adjust_thread_count(), which is called at the end of submit().

Yeah. In your current approach you're using ThreadPoolExecutor private API, which makes the code a bit fragile.  There are two alternatives:

1. Extent ThreadPoolExecutor API to add an option of eager threads spawn.

2. Not using ThreadPoolExecutor at all. We can write our own threads orchestration code, it's not that complicated. If we do that, our implementation will become quite faster than the current run_in_executor.  We can use curio as inspiration.  Last time I profiled asyncio I saw that the code binding concurrent.Future to asyncio.Future is quite complex, brittle, and slow.

I'm in favor of (2), but let's go through (a-d) steps to get there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Nov  8 10:00:45 2019
From: report at bugs.python.org (Dmitry Marakasov)
Date: Fri, 08 Nov 2019 15:00:45 +0000
Subject: [issue38744] python 3.8 hang in multiprocessing.Pool() locking on
 FreeBSD
Message-ID: <1573225244.96.0.151354887911.issue38744@roundup.psfhosted.org>


New submission from Dmitry Marakasov <amdmi3 at amdmi3.ru>:

System: FreeBSD 12.0-RELEASE, amd64.

This simple program

    from multiprocessing import Pool
    from time import sleep

    Pool().map(sleep, [0.01] * 10)

works fine with python 3.7, but is likely (about 20-50% probability on my 4 core box) to hang with python 3.8. Example backtraces after interruption:

% python3.8 1.py
^CException ignored in: <Finalize object, dead>
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/util.py", line 201, in __call__
Process ForkPoolWorker-2:
Process ForkPoolWorker-4:
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 689, in _terminate_pool
    cls._help_stuff_finish(inqueue, task_handler, len(pool))
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 674, in _help_stuff_finish
    inqueue._rlock.acquire()
KeyboardInterrupt: 
Process ForkPoolWorker-3:
Process ForkPoolWorker-1:

% python3.8 1.py
^CException ignored in: <Finalize object, dead>
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/util.py", line 201, in __call__
Process ForkPoolWorker-3:
Process ForkPoolWorker-4:
Process ForkPoolWorker-1:
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 689, in _terminate_pool
    cls._help_stuff_finish(inqueue, task_handler, len(pool))
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 674, in _help_stuff_finish
    inqueue._rlock.acquire()
KeyboardInterrupt: 
Process ForkPoolWorker-2:

% python3.8 1.py
^CException ignored in: <Finalize object, dead>
Process ForkPoolWorker-2:
Process ForkPoolWorker-3:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/util.py", line 201, in __call__
Process ForkPoolWorker-1:
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 689, in _terminate_pool
    cls._help_stuff_finish(inqueue, task_handler, len(pool))
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 674, in _help_stuff_finish
Traceback (most recent call last):
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/usr/local/lib/python3.8/multiprocessing/queues.py", line 355, in get
    with self._rlock:
  File "/usr/local/lib/python3.8/multiprocessing/queues.py", line 355, in get
    with self._rlock:
  File "/usr/local/lib/python3.8/multiprocessing/synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
  File "/usr/local/lib/python3.8/multiprocessing/synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
KeyboardInterrupt
KeyboardInterrupt
    inqueue._rlock.acquire()
KeyboardInterrupt: 
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/usr/local/lib/python3.8/multiprocessing/queues.py", line 356, in get
    res = self._reader.recv_bytes()
  File "/usr/local/lib/python3.8/multiprocessing/connection.py", line 216, in recv_bytes
    buf = self._recv_bytes(maxlength)
  File "/usr/local/lib/python3.8/multiprocessing/connection.py", line 414, in _recv_bytes
    buf = self._recv(4)
  File "/usr/local/lib/python3.8/multiprocessing/connection.py", line 379, in _recv
    chunk = read(handle, remaining)
KeyboardInterrupt
Process ForkPoolWorker-4:

Related issue in FreeBSD bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241801

----------
components: Library (Lib)
messages: 356243
nosy: AMDmi3
priority: normal
severity: normal
status: open
title: python 3.8 hang in multiprocessing.Pool() locking on FreeBSD
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38744>
_______________________________________

From report at bugs.python.org  Fri Nov  8 10:12:57 2019
From: report at bugs.python.org (Suresh Murugesan)
Date: Fri, 08 Nov 2019 15:12:57 +0000
Subject: [issue38745] pygame install error using python 3.8.0
Message-ID: <1573225977.18.0.894104496168.issue38745@roundup.psfhosted.org>


New submission from Suresh Murugesan <sayhelloby6am at gmail.com>:

I tried to install pygame, using pip install pygame, on my windows 10 running python 3.8.0. But it fails with the following error messages

Can you please help. I read on the internet that 3.8 is not stable yet for pygame. Is it true?

   ERROR: Command errored out with exit status 1:
     command: 'c:\users\smuru02\appdata\local\programs\python\python38-32\python.exe' -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\smuru02\\AppData\\Local\\Temp\\pip-install-0yqtpy1n\\pygame\\setup.py'"'"'; __file__='"'"'C:\\Users\\smuru02\\AppData\\Local\\Temp\\pip-install-0yqtpy1n\\pygame\\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base 'C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\pip-egg-info'
         cwd: C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\
    Complete output (17 lines):


    WARNING, No "Setup" File Exists, Running "buildconfig/config.py"
    Using WINDOWS configuration...


    Download prebuilts to "prebuilt_downloads" and copy to "./prebuilt-x86"? [Y/n]Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\setup.py", line 194, in <module>
        buildconfig.config.main(AUTO_CONFIG)
      File "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\config.py", line 210, in main
        deps = CFG.main(**kwds)
      File "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\config_win.py", line 576, in main
        and download_win_prebuilt.ask(**download_kwargs):
      File "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\download_win_prebuilt.py", line 302, in ask
        reply = raw_input(
    EOFError: EOF when reading a line
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

----------
components: Windows
messages: 356244
nosy: paul.moore, pysuresh, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pygame install error using python 3.8.0
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38745>
_______________________________________

From report at bugs.python.org  Fri Nov  8 10:29:48 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Nov 2019 15:29:48 +0000
Subject: [issue38745] pygame install error using python 3.8.0
In-Reply-To: <1573225977.18.0.894104496168.issue38745@roundup.psfhosted.org>
Message-ID: <1573226988.81.0.660087551802.issue38745@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

pygame is a third-party component and not developed by the Python core team. This bug tracker is only for issues with Python itself. Please report the problem with pygame.

----------
nosy: +christian.heimes
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38745>
_______________________________________

From report at bugs.python.org  Fri Nov  8 11:09:16 2019
From: report at bugs.python.org (Mike Raider)
Date: Fri, 08 Nov 2019 16:09:16 +0000
Subject: [issue38746] HTML5 named character references not consistent
Message-ID: <1573229356.22.0.226241995298.issue38746@roundup.psfhosted.org>


New submission from Mike Raider <miker2001 at yahoo.com>:

In the file 
cpython/blob/master/Lib/html/entities.py

the HTML5 named character references (line 264) do not look consistent.

Some references have a semicolon at the end, some not, and some have both variants.

Is there a reason for this?

----------
components: Library (Lib)
messages: 356246
nosy: mikeraider
priority: normal
severity: normal
status: open
title: HTML5 named character references not consistent

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38746>
_______________________________________

From report at bugs.python.org  Fri Nov  8 11:28:54 2019
From: report at bugs.python.org (paul j3)
Date: Fri, 08 Nov 2019 16:28:54 +0000
Subject: [issue38736] argparse: wrong type from get_default when type is set
In-Reply-To: <1573141247.89.0.957889061173.issue38736@roundup.psfhosted.org>
Message-ID: <1573230534.2.0.229843583354.issue38736@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

Yes you can set the default to be any object, such as an evaluated string.  If it isn't a string it won't be passed through 'type'.

The purpose of the delayed evaluation that I described is to avoid unnecessary evaluations.  The worse case would be a write filetype.  You don't want to create (or over write) a default file if it never gets used.

(I intend to close this issue).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38736>
_______________________________________

From report at bugs.python.org  Fri Nov  8 11:35:50 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Nov 2019 16:35:50 +0000
Subject: [issue38743] configure: on macOS (darwin) add CoreFoundation to flags
 before checking for gettext
In-Reply-To: <1573212841.11.0.0393862101681.issue38743@roundup.psfhosted.org>
Message-ID: <1573230950.53.0.157501917447.issue38743@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38743>
_______________________________________

From report at bugs.python.org  Fri Nov  8 11:38:28 2019
From: report at bugs.python.org (Marco Sulla)
Date: Fri, 08 Nov 2019 16:38:28 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
Message-ID: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

Sometimes I?m lazy and I would test code copy - pasted from internet or from other sources directly in the interpreter, in interactive mode. But if the code contains completely blank lines, the copy - paste fails. For example:

def f():
    print("Marco")

    print("Sulla")

does not work, but

def f():
    print("Marco")
    
    print("Sulla")

yes. Notice that in a script the first code block is perfectly valid and works.

This does not happen with Jupiter console, aka IPython. Jupiter implements bracketed paste mode, so it distinguish between normal input and pasted input.

Jupyter offers also:
- autoindent
- save code blocks in one history entry: this way, if you write a function, for example, and you press the up key, the whole function will be loaded, and not its last line.
- auto-reloading of modules. It should be disabled by default and enabled by a flag, and could auto-reload a module if its code changes.
- save code to console. All the code written in the current interactive session could be saved to the clipboard. It could be triggered by F12.
- history: it could be a new built-in function. if called without parameters, it could show the history, with lines numbered. If called with a number, it will paste the corresponding history line to the console
- pretty printing and source inspection. IMHO pprint.pprint() and inspect.getsource() are so useful in interactive mode that could be added to builtins.
- syntax coloring. It should be disabled by default, and could be enabled by a flag or a config.
- bracket matching. See above.

I think that implementing all of this in CPython is really hard. I suppose that maybe many things are not possible for compatibility between platforms, or can't be available everywhere, like syntax coloring.

----------
components: Demos and Tools
messages: 356248
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Fri Nov  8 11:57:34 2019
From: report at bugs.python.org (David Heffernan)
Date: Fri, 08 Nov 2019 16:57:34 +0000
Subject: [issue38748] 32 bit ctypes stdcall callback fails to restore stack
 pointer
Message-ID: <1573232254.38.0.286098798289.issue38748@roundup.psfhosted.org>


New submission from David Heffernan <david.heff at gmail.com>:

Starting with Python 3.8 certain ctypes callbacks fail to restore the stack pointer.

In the repo below, when the DLL is compiled with MSVC under default debug settings, running the Python script leads to a debug error dialog which says:


Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call.  This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.


It appears that when the C code calls the callback function, the value of ESP is 4 greater than it should be.

This problem does not occur with older versions of Python.


**DLL code**

#include <Windows.h>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

typedef void (__stdcall *MYCALLBACK)(int, double);

extern "C"
{
    __declspec(dllexport) void __stdcall foo(MYCALLBACK callback)
    {
        callback(1, 11);
        callback(2, 21);
        callback(3, 31);
    }
}

**Python code**

import ctypes
import ctypes.wintypes

def CallbackType(restype, *argtypes):

    def from_param(cls, obj):
        if obj is None:
            return obj
        return ctypes._CFuncPtr.from_param(obj)

    result = ctypes.WINFUNCTYPE(restype, *argtypes)
    result.from_param = classmethod(from_param)
    return result

MYCALLBACK = CallbackType(
    None,
    ctypes.c_int,
    ctypes.c_double
)

def callback(handle, time):
    print(handle, time)
mycallback = MYCALLBACK(callback)

lib = ctypes.WinDLL(r'path\to\dll\foo.dll')
func = getattr(lib, '_foo at 4')
func.restype = None
func.argtypes = MYCALLBACK,
func(mycallback)

----------
components: ctypes
messages: 356249
nosy: David Heffernan
priority: normal
severity: normal
status: open
title: 32 bit ctypes stdcall callback fails to restore stack pointer
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38748>
_______________________________________

From report at bugs.python.org  Fri Nov  8 12:01:41 2019
From: report at bugs.python.org (Thamme Gowda)
Date: Fri, 08 Nov 2019 17:01:41 +0000
Subject: [issue38740] Line count mis match between open() vs sys.stdin api
 calls
In-Reply-To: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>
Message-ID: <1573232501.2.0.167432276425.issue38740@roundup.psfhosted.org>


Thamme Gowda <tgowdan at gmail.com> added the comment:

Thanks for the quick response. 
Yes ``newline="\n"`` fixed it. 
So it as a known behavior. (I was tempted to consider it as a bug since the behavior differed from sys.stdin)

Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38740>
_______________________________________

From report at bugs.python.org  Fri Nov  8 12:03:52 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Nov 2019 17:03:52 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573232632.11.0.147336944162.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

I think you must still be experiencing some sort of sandboxing. I don't know how else you would get an EPERM out of pidfd_open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Fri Nov  8 12:13:39 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 08 Nov 2019 17:13:39 +0000
Subject: [issue38743] configure: on macOS (darwin) add CoreFoundation to flags
 before checking for gettext
In-Reply-To: <1573212841.11.0.0393862101681.issue38743@roundup.psfhosted.org>
Message-ID: <1573233219.97.0.363249670515.issue38743@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38743>
_______________________________________

From report at bugs.python.org  Fri Nov  8 12:54:30 2019
From: report at bugs.python.org (Travis Lazar)
Date: Fri, 08 Nov 2019 17:54:30 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
In-Reply-To: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>
Message-ID: <1573235670.17.0.626618271182.issue38739@roundup.psfhosted.org>


Travis Lazar <travis.lazar at gmail.com> added the comment:

Really appreciate all the commentary and references here. Thanks for that.

The resolution of disabling html5lib in pyperformance is good. I'll assume no html5lib benchmarking in pyperformance (master) until a version of html5lib is released compatible with 3.9.

Thanks again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Fri Nov  8 12:57:09 2019
From: report at bugs.python.org (Ben Reilly)
Date: Fri, 08 Nov 2019 17:57:09 +0000
Subject: [issue38729] mock.create_autospec generates incorrect signature for
 some decorated methods
In-Reply-To: <1573081188.35.0.210639381989.issue38729@roundup.psfhosted.org>
Message-ID: <1573235829.51.0.495027364083.issue38729@roundup.psfhosted.org>


Ben Reilly <breilly at box.com> added the comment:

Yes, your description sounds right, and I had zero-ed in on the same park of the mock code when I was doing my investigation.

I know that this is a peculiar situation, but one thing to note is that `inspect.signature` gets the signature right on these wrapped methods. You can see this if you were to add in an appropriate spot the following code to the script:

====
from inspect import signature

print(signature(a.with_arg))  # prints `(x)`
print(signature(a.no_arg))    # prints `()`
====

Is there a reason why mock calculates the signature on its own rather than relying on `inspect`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38729>
_______________________________________

From report at bugs.python.org  Fri Nov  8 13:23:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Nov 2019 18:23:06 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573237386.18.0.967761307887.issue38747@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Interpreter Core -Demos and Tools
priority: normal -> low
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Fri Nov  8 13:55:19 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 08 Nov 2019 18:55:19 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573239319.6.0.627429813173.issue38738@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Very nice. I aplaud your return to the original Python terminology, of true and false as adjectives, and True and False as names for specific objects. Perlisms such as `truthy` or `that evaluates as True` simply make my head spin.

I wrote one comment, regarding the case where you have the default value mentioned. Otherwise, I think it is a very nice change.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Fri Nov  8 14:10:01 2019
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 08 Nov 2019 19:10:01 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573240201.07.0.186636537113.issue38500@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

It sounds to me like `PyInterpreterState.eval_frame` is being used to lazily modify the bytecode to support breakpoints.

I can see no reason why changing the bytecode can't be done via `function.__code__`.
Suppose the code-object with the breakpoint add is `bcode`, then to turn on the breakpoint:
original_code = f.__code__
f.__code__ = bcode

and to turn it off
f.__code__ = original_code


The JVM supports bytecode instrumentation (via class loaders). It works well, as it provides a clear way for third party tools to modify the behaviour of a particular piece of code without violating any of the invariants of the interpreter. 
We don't really advertise setting `function.__code__` as a way to add low-impact breakpoints or profiling, but it is there.

If this use case is important, and it sounds like it is, then a better option would be to offer library support for adding and removing breakpoints/instrumentation.
This would have the advantage of being composable in a way that changing `PyInterpreterState.eval_frame` is not; in other words, it would be possible for one tool to add profiling and another to add breakpoints and have both work correctly.

I can write up a PEP if necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov  8 14:25:53 2019
From: report at bugs.python.org (Fabio Zadrozny)
Date: Fri, 08 Nov 2019 19:25:53 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573241153.91.0.583537169802.issue38500@roundup.psfhosted.org>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

@Mark

I can think of many use-cases which may break if the function code is changed (users can change the code in real-use cases and when they do that they'd loose debugging).

So, as long as the function code is part of the public API of Python, the debugger can't really change it for breakpoints (which is a bit different from the frame code, which the user can't really swap and it's not so common to change).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov  8 14:30:25 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Nov 2019 19:30:25 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1573241425.05.0.738451972174.issue38707@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Fri Nov  8 14:42:25 2019
From: report at bugs.python.org (mike bayer)
Date: Fri, 08 Nov 2019 19:42:25 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
Message-ID: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

When using unicode characters inside of JSON strings, values retrieved via the JSON_EXTRACT SQLite function fail to be decoded by the sqlite3 driver if they include four-byte unicode characters.

Version information for my build, which is Fedora 30:

Python 3.7.4 (default, Jul  9 2019, 16:32:37) 
[GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.version
'2.6.0'
>>> sqlite3.sqlite_version
'3.26.0'


Demo as follows:

import json
import sqlite3

# two unicode strings, the second one has four byte character in it
good_data = "r?ve ill?"
bad_data = "r?ve? ill?"

# create simple json structures
good_data_json = json.dumps({"foo": good_data})
bad_data_json = json.dumps({"foo": bad_data})

# all strings are valid utf-8
# data round trips correctly through json
assert json.loads(good_data_json.encode("utf-8").decode("utf-8")) == {
    "foo": good_data
}
assert json.loads(bad_data_json.encode("utf-8").decode("utf-8")) == {
    "foo": bad_data
}


conn = sqlite3.connect(":memory:")
cursor = conn.cursor()

cursor.execute("CREATE TABLE some_data (id INT, data JSON)")
cursor.executemany(
    "INSERT INTO some_data(id, data) VALUES(?, ?)",
    [(1, good_data_json), (2, bad_data_json)],
)

# we can retrieve the JSON objects as a whole from the DB, no issue
cursor.execute("SELECT some_data.data FROM some_data ORDER BY id")
assert cursor.fetchall() == [(good_data_json, ), (bad_data_json, )]

# when we use JSON_EXTRACT, then full utf-8 support is lost

# extract good value from JSON object
cursor.execute("""
    SELECT JSON_EXTRACT(some_data.data, '$."foo"')
    FROM some_data WHERE id=1
""")
assert cursor.fetchone()[0] == good_data

# extract bad value from JSON object; utf-8 failure
# sqlite3.OperationalError: Could not decode to UTF-8 column
# 'JSON_EXTRACT(some_data.data, '$."foo"')' with text 'r??ve?????? ill??'
cursor.execute("""
    SELECT JSON_EXTRACT(some_data.data, '$."foo"')
    FROM some_data WHERE id=2
""")
assert cursor.fetchone()[0] == bad_data


output:


Traceback (most recent call last):
  File "test4.py", line 50, in <module>
    """)
sqlite3.OperationalError: Could not decode to UTF-8 column 'JSON_EXTRACT(some_data.data, '$."foo"')' with text 'r??ve?????? ill??'


surprising to say the least as the SQLite driver has always been completely solid with all unicode, but there you go.

----------
components: Library (Lib)
messages: 356257
nosy: zzzeek
priority: normal
severity: normal
status: open
title: sqlite3 driver fails on four byte unicode strings coming from JSON_EXTRACT
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov  8 14:42:59 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Nov 2019 19:42:59 +0000
Subject: [issue38744] python 3.8 hang in multiprocessing.Pool() locking on
 FreeBSD
In-Reply-To: <1573225244.96.0.151354887911.issue38744@roundup.psfhosted.org>
Message-ID: <1573242179.27.0.720942739628.issue38744@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38744>
_______________________________________

From report at bugs.python.org  Fri Nov  8 14:57:53 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 19:57:53 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1573243073.24.0.339025224529.issue38669@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This enhancement request (no backports) is about the unittest.mock patch.object.
https://docs.python.org/3/library/unittest.mock.html#unittest.mock.patch.object

----------
nosy: +terry.reedy
type:  -> enhancement
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38669>
_______________________________________

From report at bugs.python.org  Fri Nov  8 15:23:01 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Nov 2019 20:23:01 +0000
Subject: [issue32417] fromutc does not respect datetime subclasses
In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za>
Message-ID: <1573244581.7.0.618621426458.issue32417@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This issue broke a date subclass in the calendra project (https://github.com/jaraco/calendra/issues/11). I acknowledge this change was a known breakage, but I mention it here and link the downstream issue for your information.

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32417>
_______________________________________

From report at bugs.python.org  Fri Nov  8 15:43:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 20:43:32 +0000
Subject: [issue38672] mimetypes.init() fails if no access to one of known files
In-Reply-To: <1572784402.07.0.839086408394.issue38672@roundup.psfhosted.org>
Message-ID: <1573245812.35.0.334993335666.issue38672@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

An exception report is a failure to finish but not a crash as meant here.

The current code requires all known files and any file explicitly passes to be readable.  The proposed simple change would make it OK if none of them are.  But is this really OK?

Is it really OK if known files are not readable?  Should they not be readable by all?

Removing the isfile call would allow directories to be passed through to db.readfp.  This might not be a good idea.  We would definitely have to think about what errors might be raised on different systems.

I think the try-except should be in init rather than db.read.  The latter can be called directly and I think a user explicitly passing an filename should be notified.  This comment actually also applies to files passed to init.

[Sidenote: the doc says that MimeTypes "provides an interface similar to the one of the mimetypes module."  The mimetypes.db used by mimetypes functions *is* a MimeTypes instance and the user can call db methods anything after init().]

Overall, I am not convinced that the current behavior is a bug, in which case this is an 'enhancement' request that changes the current API.  I am not at all a mimetypes expert, so I nosied a couple of email people who have worked on the module and should know more.

----------
nosy: +maxking, r.david.murray, terry.reedy
title: Crash on mimetypes.init() if there is no access to one of knownfiles -> mimetypes.init() fails if no access to one of known files

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38672>
_______________________________________

From report at bugs.python.org  Fri Nov  8 15:56:56 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Nov 2019 20:56:56 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
In-Reply-To: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>
Message-ID: <1573246616.92.0.165065685605.issue38749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

sqlite> select JSON_EXTRACT('["t\u00e8\u015b\ud835\udd99"]', '$[0]');
t????????

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov  8 15:57:33 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Nov 2019 20:57:33 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
In-Reply-To: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>
Message-ID: <1573246653.69.0.371261664679.issue38749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seems this is a bug in JSON_EXTRACT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov  8 16:02:40 2019
From: report at bugs.python.org (Jason Killen)
Date: Fri, 08 Nov 2019 21:02:40 +0000
Subject: [issue38723] Pdb._runscript should use io.open_code() instead of
 open()
In-Reply-To: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>
Message-ID: <1573246960.39.0.913802002151.issue38723@roundup.psfhosted.org>


Jason Killen <jsnklln at gmail.com> added the comment:

I flipped through PEP 578 (Runtime Audit Hooks) and this seems like the type of situation that PEP 578 was trying to handle.  I've got a change that seems to be working and can provide a PR or whatever once I remember/read up on doing that.  (I'm a very seldom contributor and am more than happy to defer to those that know more than me.)

----------
nosy: +Jason.Killen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38723>
_______________________________________

From report at bugs.python.org  Fri Nov  8 16:06:11 2019
From: report at bugs.python.org (Pete Wicken)
Date: Fri, 08 Nov 2019 21:06:11 +0000
Subject: [issue38750] Solve IPv4 categorisation issues with the ipaddress
 module
Message-ID: <1573247171.82.0.693534364371.issue38750@roundup.psfhosted.org>


New submission from Pete Wicken <petewicken at gmail.com>:

As alluded to in issue bpo-38655, the behaviour for getting categorising IPv4 networks is inconsistent with the IANA guideline, which the docs say it follows.

I'm proposing we either change the documentation so that it describes the behaviour that should actually be expected, or we rewrite some parts of the ipaddress module so that they follow the guidelines.

For the latter, my thoughts would be to actually implement the check table on the IANA page (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml).

i.e for a given address, you can ask of it "is_forwardable", "is_globally_reachable", etc.

----------
messages: 356265
nosy: Wicken
priority: normal
severity: normal
status: open
title: Solve IPv4 categorisation issues with the ipaddress module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38750>
_______________________________________

From report at bugs.python.org  Fri Nov  8 16:06:31 2019
From: report at bugs.python.org (Pete Wicken)
Date: Fri, 08 Nov 2019 21:06:31 +0000
Subject: [issue38750] Solve IPv4 categorisation issues with the ipaddress
 module
In-Reply-To: <1573247171.82.0.693534364371.issue38750@roundup.psfhosted.org>
Message-ID: <1573247191.68.0.791451140444.issue38750@roundup.psfhosted.org>


Change by Pete Wicken <petewicken at gmail.com>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38750>
_______________________________________

From report at bugs.python.org  Fri Nov  8 16:34:28 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 08 Nov 2019 21:34:28 +0000
Subject: [issue27465] IDLE:Make help source menu entries unique and sorted.
In-Reply-To: <1467943126.13.0.718896019337.issue27465@psf.upfronthosting.co.za>
Message-ID: <1573248868.96.0.867348921698.issue27465@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +16601
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/17093

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27465>
_______________________________________

From report at bugs.python.org  Fri Nov  8 16:36:52 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Nov 2019 21:36:52 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
In-Reply-To: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>
Message-ID: <1573249012.64.0.492163298058.issue38749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have reported a bug to SQLite. Will see an answer.

It could be possible to implement a workaround in Python if this behavior will not be fixed.

----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov  8 16:55:44 2019
From: report at bugs.python.org (Pete Wicken)
Date: Fri, 08 Nov 2019 21:55:44 +0000
Subject: [issue38750] Solve IPv4 categorisation issues with the ipaddress
 module
In-Reply-To: <1573247171.82.0.693534364371.issue38750@roundup.psfhosted.org>
Message-ID: <1573250144.04.0.930862444517.issue38750@roundup.psfhosted.org>


Pete Wicken <petewicken at gmail.com> added the comment:

In addition to my previous comment, I think a more generic "is_special" could cover everything in the IANA special purpose address table for ease of checking anything that isn't publicly available IP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38750>
_______________________________________

From report at bugs.python.org  Fri Nov  8 17:17:36 2019
From: report at bugs.python.org (mike bayer)
Date: Fri, 08 Nov 2019 22:17:36 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
In-Reply-To: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>
Message-ID: <1573251456.79.0.0231479721959.issue38749@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

Hi where did you report it?    I don't see it on the mailing list or in their fossil tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov  8 17:22:24 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Nov 2019 22:22:24 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
In-Reply-To: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>
Message-ID: <1573251744.4.0.769721472389.issue38749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It awaits moderator approval.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov  8 17:50:54 2019
From: report at bugs.python.org (mike bayer)
Date: Fri, 08 Nov 2019 22:50:54 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
In-Reply-To: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>
Message-ID: <1573253454.21.0.611263202081.issue38749@roundup.psfhosted.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

silly me thinking python devs had better access to SQLite devs :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov  8 17:55:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 22:55:09 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1573253709.81.0.326562808163.issue38673@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Entering 'pass' or a completely blank line results in a new primary prompt, at least on Windows. The Windows REPL otherwise prints ... even for effectively blank lines.  IDLE usually prints a new prompt for effectively blank lines.

>>> 
>>> #a
>>> # a
>>>  #a
>>>

I agree that these look better.  This behavior comes from code.InteractiveInterpreter and ultimately codeop.

def _maybe_compile(compiler, source, filename, symbol):
    # Check for source consisting of only blank lines and comments
    for line in source.split("\n"):
        line = line.strip()
        if line and line[0] != '#':
            break               # Leave it alone
    else:
        if symbol != "eval":
            source = "pass"     # Replace it with a 'pass' statement

As noted above, 'pass\n' is treated the same as '\n'

The first line above originally had a space, but IDLE appears to strip trailing whitespace also, even outside of comments.  (For an ending '\ ', this prevents SyntaxError, but maybe this is a bad lesson for beginners.)  However, I did find a case with an unnecessary continuation line.

>>>  # a
 
>>> 

This puzzles me, as it should be treated exactly the same as without the space after '#'.  ast.dump(ast.parse(' # a\n', '', 'single')) gives the same result, 'Module(body=[], type_ignores=[])', as without.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Fri Nov  8 17:57:50 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 22:57:50 +0000
Subject: [issue38675] Improve scope example in Tutorial, chapter 9
In-Reply-To: <1572813161.36.0.350406058195.issue38675@roundup.psfhosted.org>
Message-ID: <1573253870.73.0.901832331978.issue38675@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Sug. for the scope example in TPT Chapter 9 -> Improve scope example in Tutorial, chapter 9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38675>
_______________________________________

From report at bugs.python.org  Fri Nov  8 17:58:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 22:58:43 +0000
Subject: [issue38675] Improve scope example in Tutorial, chapter 9
In-Reply-To: <1572813161.36.0.350406058195.issue38675@roundup.psfhosted.org>
Message-ID: <1573253923.02.0.926461365195.issue38675@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To me, this is a plausible addition

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38675>
_______________________________________

From report at bugs.python.org  Fri Nov  8 17:59:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 22:59:54 +0000
Subject: [issue38679] Scipy and Scikit learn library installation issues
In-Reply-To: <1572830390.76.0.194683013325.issue38679@roundup.psfhosted.org>
Message-ID: <1573253994.73.0.136402122548.issue38679@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38679>
_______________________________________

From report at bugs.python.org  Fri Nov  8 18:29:23 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 23:29:23 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1573255763.43.0.479045477329.issue38678@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Crash means 'python stopped erroneously without a traceback'. 

Same exception in 3.8 and 3.9.  Argparse uses None for a count of 0.  I consider this a bug.  If not changed, it should be documented.  As argparse is, the example needs to recode None to 0.  (Or, it could add '-v' to sys.argv.)  With proper line wrapping, the result could be

import argparse
from getpass import getuser
parser = argparse.ArgumentParser(description='An argparse example.')
parser.add_argument('name', nargs='?', default=getuser(),  # wrap
                    help='The name of someone to greet.')
parser.add_argument('--verbose', '-v', action='count')
args = parser.parse_args()  # new
args.verbose = 0 if args.verbose is None else args.verbose
greeting = (["Hi", "Hello", "Greetings! its very nice to meet you"] #wrap
            [args.verbose % 3])
print(f'{greeting}, {args.name}')

----------
nosy: +terry.reedy
stage:  -> needs patch
title: TypeError raised trying to run TPT 10.3 Example 2 in Python 3.4.3 -> TypeError for Tutorial 10.3 Example 2
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Fri Nov  8 18:31:00 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 23:31:00 +0000
Subject: [issue38681] 2to3 Conversion Result using BlankLine() can be
 Syntactically Incorrect
In-Reply-To: <1572851567.83.0.781319798867.issue38681@roundup.psfhosted.org>
Message-ID: <1573255860.24.0.944331869965.issue38681@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38681>
_______________________________________

From report at bugs.python.org  Fri Nov  8 18:33:11 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Nov 2019 23:33:11 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1573255991.62.0.411148456779.issue38688@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +3.8regression
stage:  -> needs patch
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Fri Nov  8 18:55:40 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 08 Nov 2019 23:55:40 +0000
Subject: [issue27465] IDLE:Make help source menu entries unique and sorted.
In-Reply-To: <1467943126.13.0.718896019337.issue27465@psf.upfronthosting.co.za>
Message-ID: <1573257340.99.0.437222440226.issue27465@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created a pull request for this issue.  Please consider taking a look.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27465>
_______________________________________

From report at bugs.python.org  Fri Nov  8 19:00:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Nov 2019 00:00:47 +0000
Subject: [issue38734] Python 3.7 and 3.8 in Windows Store do not start under
 git bash
In-Reply-To: <1573122494.13.0.703066612304.issue38734@roundup.psfhosted.org>
Message-ID: <1573257647.62.0.859145631745.issue38734@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

['crash' means something like Windows 'your program has quit running' box.]

Do other Windows Store 'apps' run from bash? (Or from Command Prompt or Power Shell?)

For an immediate solution, install Python normally, as a command-line program, with the python.org Windows installer.

Terry at Tejarex MINGW64 ~
$ python
Python 3.7.5 (tags/v3.7.5:5c02a39a0b, Oct 15 2019, 00:11:34) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

Terry at Tejarex MINGW64 ~
$ py
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

Terry at Tejarex MINGW64 ~
$ py -m idlelib
[IDLE 3.8 shell runs]

You should then be able to run 'py -x.y pip install ...' to install to python x.y.

Steve, can and will you make store python runnable under bash or should this be closed?

----------
nosy: +terry.reedy
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38734>
_______________________________________

From report at bugs.python.org  Fri Nov  8 19:22:59 2019
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Sat, 09 Nov 2019 00:22:59 +0000
Subject: [issue38751] Document maximum JSON depth or remove it.
Message-ID: <1573258979.82.0.0958429006244.issue38751@roundup.psfhosted.org>


New submission from ????? ?????????? <boris.verk at gmail.com>:

import json

foo = {}

for i in range(1000):
    json.dumps(foo)
    print(i)
    foo = {'bar': foo}


Will error at 994. At a minimum this magic number should be documented, but it would be better if the json library could handle arbitrarily nested JSON or have a configurable limit.

https://github.com/lovasoa/bad_json_parsers

----------
components: Library (Lib)
messages: 356276
nosy: boris
priority: normal
severity: normal
status: open
title: Document maximum JSON depth or remove it.
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38751>
_______________________________________

From report at bugs.python.org  Fri Nov  8 20:07:28 2019
From: report at bugs.python.org (Sebastian Bevc)
Date: Sat, 09 Nov 2019 01:07:28 +0000
Subject: [issue38752] __init__ taking out of context variables
Message-ID: <1573261648.24.0.116935582519.issue38752@roundup.psfhosted.org>


New submission from Sebastian Bevc <sebastian.bevc at gmail.com>:

Hello,

This is my first bug report. While doing some homework i came to realize that the __init__ of a class was taking out of context variables.

class Foo(object):
  def __init__(self, attr1):
    self.out_of_context = out_of_context


# Raises NameError as it is expected
foo = Foo('some attr')

# 'bar' is bounded to 'out_of_context' although it was initialized
# with value 'some value'
out_of_context = 'bar'
foo = Foo('some value')
print(foo.out_of_context')  # prints 'bar'

----------
components: asyncio
messages: 356277
nosy: asvetlov, sebasbeco, yselivanov
priority: normal
severity: normal
status: open
title: __init__ taking out of context variables
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38752>
_______________________________________

From report at bugs.python.org  Fri Nov  8 20:11:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Nov 2019 01:11:30 +0000
Subject: [issue38740] Line count mismatch between open() vs sys.stdin api calls
In-Reply-To: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>
Message-ID: <1573261890.33.0.769973190167.issue38740@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Should this be closed as 'not a bug'?

----------
nosy: +terry.reedy
title: Line count mis match between open() vs sys.stdin api calls -> Line count mismatch between open() vs sys.stdin api calls

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38740>
_______________________________________

From report at bugs.python.org  Fri Nov  8 20:13:20 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Nov 2019 01:13:20 +0000
Subject: [issue38746] HTML5 named character references not consistent
In-Reply-To: <1573229356.22.0.226241995298.issue38746@roundup.psfhosted.org>
Message-ID: <1573262000.96.0.35397675026.issue38746@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38746>
_______________________________________

From report at bugs.python.org  Fri Nov  8 20:20:20 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 09 Nov 2019 01:20:20 +0000
Subject: [issue38752] __init__ taking out of context variables
In-Reply-To: <1573261648.24.0.116935582519.issue38752@roundup.psfhosted.org>
Message-ID: <1573262420.17.0.165798847397.issue38752@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This isn't a bug, it's how the language works. You're not forced to use the parameters to a function (in this case __init__), and you can reference any variable, including a global.

----------
components:  -asyncio
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38752>
_______________________________________

From report at bugs.python.org  Fri Nov  8 20:24:51 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 09 Nov 2019 01:24:51 +0000
Subject: [issue38752] __init__ taking out of context variables
In-Reply-To: <1573261648.24.0.116935582519.issue38752@roundup.psfhosted.org>
Message-ID: <1573262691.74.0.534448574502.issue38752@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Also: you're statement that bar was initialized to "some value" isn't true: you didn't use attr1 in your __init__ method, so "some value" was never used.

If you're confused, I suggest you ask on the python-list or tutor mailing lists. More info here: https://mail.python.org/mailman/listinfo

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38752>
_______________________________________

From report at bugs.python.org  Fri Nov  8 21:00:34 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Nov 2019 02:00:34 +0000
Subject: [issue16245] Update html.entities.html5 dictionary and
 parseentities.py
In-Reply-To: <1350380511.49.0.860998010837.issue16245@psf.upfronthosting.co.za>
Message-ID: <1573264834.41.0.347021453359.issue16245@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

According to git blame, the html5 dict in https://github.com/python/cpython/blob/master/Lib/html/entities.py has changed in 7 years.  On the other hand, the standard on which it is based, https://html.spec.whatwg.org/multipage/named-characters.html, was last revised yesterday, and I presume several other times since.  On the third hand, I just ran the update script and there was no change to entities.py, so maybe is has been run with every release.

Should a comment be added to the file listing the unicode source and the update script?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16245>
_______________________________________

From report at bugs.python.org  Fri Nov  8 21:07:40 2019
From: report at bugs.python.org (Thamme Gowda)
Date: Sat, 09 Nov 2019 02:07:40 +0000
Subject: [issue38740] Line count mismatch between open() vs sys.stdin api calls
In-Reply-To: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>
Message-ID: <1573265259.99.0.804489832549.issue38740@roundup.psfhosted.org>


Change by Thamme Gowda <tgowdan at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38740>
_______________________________________

From report at bugs.python.org  Fri Nov  8 21:17:40 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Nov 2019 02:17:40 +0000
Subject: [issue38746] HTML5 named character references not consistent
In-Reply-To: <1573229356.22.0.226241995298.issue38746@roundup.psfhosted.org>
Message-ID: <1573265860.29.0.249435089664.issue38746@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Questions should usually be asked on python-list or elsewhere.

To answer, html5 was created from
https://html.spec.whatwg.org/multipage/named-characters.html
with these issues and patches.
#11113 dc44f55cc9dc1d016799362c344958baab328ff4
       518dbfd7b5a4614b095befc62d1abf1588c7c14a
#16245 e6e96eea5157650be77306b15b28bc815e14c2f3

The peculiarities in the dict keys reflect peculiarities in the standard. For instance, msg163706 of #11113 says "the standard allows some charref to end without a ';', but not all of them."

I am leaving this open to add a link to the source file both in entities.py and the doc.  It shows examples of the entities.  A new one for me is smashp; 	U+02A33 	?.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, terry.reedy
resolution:  -> not a bug
stage:  -> needs patch
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38746>
_______________________________________

From report at bugs.python.org  Fri Nov  8 21:41:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Nov 2019 02:41:44 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573267304.87.0.726518457461.issue38747@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In interactive mode, python.exe interacts with a console/(dumb terminal) through the std streams using \n as a special character  It gets input from stdin, send output to stdout or errors to stderr.  The terminal, not python, handles line editing and history retrieval.  Once a statement is entered and executed, python has no memory of it.

On Linux, one can use readline and ncurses modules for somewhat enhances interaction.

IPython is GUI-based.  Python already come with a GUI-based IDE, IDLE, which has many of the features you list - autoindent, statement history, save, line numbers in the editor, syntax coloring, and some source inspection.  Code with blank lines within statement can be pasted into an editor window and run either with or without clearing the shell workspace.

There are other alternatives with similar features, but this is not the place to discuss them.  The point is that there is no need to completely rewrite current text-based interactive mode.

----------
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Sat Nov  9 00:00:20 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 09 Nov 2019 05:00:20 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573275620.46.0.0772681159051.issue38747@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Terry, I think you were extremely over-eager, almost aggressively so, to close this feature request, especially since your reasons given are rather bogus: IPython isn't based on a GUI, it works in a text mode console too, including on Windows.

https://ipython.readthedocs.io/en/stable/overview.html

You say "there is no need to completely rewrite current text-based interactive mode". You are probably right: there probably is *no need* to completely rewrite the current implementation to add at least some, if not all, of the requested features.

For example, I would be shocked if it wasn't absolutely trivial for the current implementation to add auto-indenting following a colon. That feature alone would be a win for usability.

Given that Brett already said that the main obstacle to this feature request was lack of somebody interested and able to do the work (as opposed to a policy that we want the default REPL to be weak and unfriendly), I think you were premature in closing this so quickly. It's not like it has been languishing for years.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Sat Nov  9 00:11:14 2019
From: report at bugs.python.org (wim glenn)
Date: Sat, 09 Nov 2019 05:11:14 +0000
Subject: [issue31542] pth files in site-packages of venvs are executed twice
In-Reply-To: <1505986898.8.0.276227616013.issue31542@psf.upfronthosting.co.za>
Message-ID: <1573276274.64.0.190310589776.issue31542@roundup.psfhosted.org>


Change by wim glenn <wim.glenn at gmail.com>:


----------
nosy: +wim.glenn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31542>
_______________________________________

From report at bugs.python.org  Sat Nov  9 00:11:44 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 09 Nov 2019 05:11:44 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573276304.92.0.906235635866.issue38747@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Marco: there's no need for these to be "slowly" introduced. If the features are worth having in the default REPL, they're worth having as soon as possible, without us artificially slowing the process down. It will be hard enough to get somebody willing and able to do the work without telling them to dribble the features out slowly as well. Trust me on this, the hard part of Python development is getting feature requests implemented *at all*, not that they come too quickly!

You might like to try building these features on top of the pure-Python interactive REPL:

https://docs.python.org/3/library/code.html

or perhaps try adding them to IDLE.

If and when you have something positive to show, you could try re-opening this task with a concrete proof-of-concept using the code module, or perhaps a PR for IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Sat Nov  9 00:52:30 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Nov 2019 05:52:30 +0000
Subject: [issue38681] 2to3 Conversion Result using BlankLine() can be
 Syntactically Incorrect
In-Reply-To: <1572851567.83.0.781319798867.issue38681@roundup.psfhosted.org>
Message-ID: <1573278750.94.0.356905178009.issue38681@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38681>
_______________________________________

From report at bugs.python.org  Sat Nov  9 01:06:04 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 09 Nov 2019 06:06:04 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573279564.56.0.301257557589.issue38692@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I got a failure in newly added test_pidfd_open:

> I'm running kernel 5.3.7-x86_64-linode130 with Arch Linux.

> I think you must still be experiencing some sort of sandboxing. I don't know how else you would get an EPERM out of pidfd_open.

I believe Benjamin is correct. On a native install of Arch Linux with kernel 5.3.7 (using latest updates from the official repos), I received no failures in test_posix. 

[aeros:~/repos/benjaminp-cpython]$ ./python -m test test_posix     (asyncio-pidfd) 
0:00:00 load avg: 1.86 Run tests sequentially
0:00:00 load avg: 1.86 [1/1] test_posix

== Tests result: SUCCESS ==

1 test OK.

Total duration: 544 ms
Tests result: SUCCESS

To confirm there weren't intermittent failures, I also ran test_posix indefinitely, sending SIGINT after ~2500 iterations. No failures occurred:

[aeros:~/repos/benjaminp-cpython]$ ./python -m test test_pty -F    (asyncio-pidfd) 
...
0:01:31 load avg: 1.57 [2506] test_pty
0:01:31 load avg: 1.57 [2507] test_pty
^C

== Tests result: INTERRUPTED ==
Test suite interrupted by signal SIGINT.

2506 tests OK.

Total duration: 1 min 31 sec
Tests result: INTERRUPTED

It seems that the issue is likely specific to Chih-Hsuan Yen's environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Sat Nov  9 01:09:54 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 09 Nov 2019 06:09:54 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573279794.58.0.575277979445.issue38692@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> [aeros:~/repos/benjaminp-cpython]$ ./python -m test test_pty -F    (asyncio-pidfd) 
...
0:01:31 load avg: 1.57 [2506] test_pty
0:01:31 load avg: 1.57 [2507] test_pty

Oops, looks like I copied the wrong results of a separate test I was running earlier. I'll post the results of ~1000 iterations of test_posix below, once it is completed again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Sat Nov  9 01:17:38 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 09 Nov 2019 06:17:38 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573280258.86.0.339735535329.issue38692@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

[aeros:~/repos/benjaminp-cpython]$ ./python -m test test_posix -F  (asyncio-pidfd) 
...
0:08:52 load avg: 1.89 [1008] test_posix
0:08:52 load avg: 2.22 [1009] test_posix
...

1008 tests OK.

Total duration: 8 min 52 sec
Tests result: INTERRUPTED

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Sat Nov  9 01:31:31 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Nov 2019 06:31:31 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573281091.21.0.61396863548.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

It seems like systemd-nspawn is just breaking everything: https://sourceware.org/ml/libc-alpha/2019-11/msg00277.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Sat Nov  9 01:48:54 2019
From: report at bugs.python.org (John Belmonte)
Date: Sat, 09 Nov 2019 06:48:54 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
Message-ID: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>


New submission from John Belmonte <john at neggie.net>:

AsyncMock appears to be new in Python 3.8, but doc is missing info on when it was introduced.

https://docs.python.org/3.8/library/unittest.mock.html#unittest.mock.AsyncMock

----------
assignee: docs at python
components: Documentation
messages: 356290
nosy: John Belmonte, docs at python
priority: normal
severity: normal
status: open
title: AsyncMock not cited as new in 3.8
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Sat Nov  9 01:57:06 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 09 Nov 2019 06:57:06 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
In-Reply-To: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>
Message-ID: <1573282626.71.0.347845010704.issue38753@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +lisroach, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Sat Nov  9 03:13:26 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Nov 2019 08:13:26 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1573287206.84.0.0235294253583.issue38678@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll replace this example with more representative one that works.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Sat Nov  9 04:02:07 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Nov 2019 09:02:07 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1573290127.05.0.855638442447.issue16576@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +16603
pull_request: https://github.com/python/cpython/pull/17097

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Sat Nov  9 04:57:44 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 09 Nov 2019 09:57:44 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573293464.5.0.279061390148.issue38692@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Benjamin Peterson, Kyle Stanley: Thank you both very much for intensive testing and helpful information! Yes on my Arch Linux box tests are also fine without systemd-nspawn. However, as I have to use systemd-nspawn for some reasons, and investigating how it blocks system calls is beyond my ability, I just add a workaround for now: https://aur.archlinux.org/cgit/aur.git/tree/python-git-issue38692.diff?h=python-git.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Sat Nov  9 05:45:59 2019
From: report at bugs.python.org (nerd)
Date: Sat, 09 Nov 2019 10:45:59 +0000
Subject: [issue38754] Python3.7 site-packages
Message-ID: <1573296359.45.0.502022034855.issue38754@roundup.psfhosted.org>


New submission from nerd <tsgh at riseup.net>:

Everytime I do anything related to updating arch or installing anything python3.7 for some reason really breaks. I've waited over 6 months for a single fix for this and have yet to find a solution to it. I am not a python nerd so idk whats going on here but overall my experience with python has been a total flop. I can actively program and write advanced stuff with it and this is still baffling me. 



warning: could not get file information for usr/lib/python3.7/site-packages/PyGObject-3.34.0.egg-info
warning: could not get file information for usr/lib/python3.7/site-packages/gi/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_compat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_compat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_constants.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_constants.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_error.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_error.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_gtktemplate.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_gtktemplate.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_option.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_option.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_ossighelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_ossighelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_propertyhelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_propertyhelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_signalhelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_signalhelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/docstring.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/docstring.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/importer.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/importer.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/module.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/module.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/pygtkcompat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/pygtkcompat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/types.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/types.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_compat.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_constants.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_error.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gtktemplate.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_option.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_ossighelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_propertyhelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_signalhelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/docstring.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/importer.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/module.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GIMarshallingTests.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GLib.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GObject.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gdk.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GdkPixbuf.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gio.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gtk.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Pango.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GIMarshallingTests.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GIMarshallingTests.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GLib.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GLib.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GObject.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GObject.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gdk.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gdk.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GdkPixbuf.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GdkPixbuf.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gio.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gio.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gtk.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gtk.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Pango.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Pango.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/keysyms.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/keysyms.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/keysyms.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/pygtkcompat.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/types.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/generictreemodel.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/generictreemodel.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/pygtkcompat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/pygtkcompat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/generictreemodel.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/pygtkcompat.py





^^^^=https://pastebin.com/iuZWHQse ^^^^

----------
messages: 356293
nosy: twister100
priority: normal
severity: normal
status: open
title: Python3.7 site-packages

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38754>
_______________________________________

From report at bugs.python.org  Sat Nov  9 05:46:41 2019
From: report at bugs.python.org (nerd)
Date: Sat, 09 Nov 2019 10:46:41 +0000
Subject: [issue38754] Python3.7 site-packages
In-Reply-To: <1573296359.45.0.502022034855.issue38754@roundup.psfhosted.org>
Message-ID: <1573296401.63.0.306984679495.issue38754@roundup.psfhosted.org>


nerd <tsgh at riseup.net> added the comment:

Everytime I do anything related to updating arch or installing anything python3.7 for some reason really breaks. I've waited over 6 months for a single fix for this and have yet to find a solution to it. I am not a python nerd so idk whats going on here but overall my experience with python has been a total flop. I can actively program and write advanced stuff with it and this is still baffling me. 



warning: could not get file information for usr/lib/python3.7/site-packages/PyGObject-3.34.0.egg-info
warning: could not get file information for usr/lib/python3.7/site-packages/gi/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_compat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_compat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_constants.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_constants.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_error.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_error.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_gtktemplate.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_gtktemplate.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_option.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_option.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_ossighelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_ossighelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_propertyhelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_propertyhelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_signalhelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_signalhelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/docstring.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/docstring.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/importer.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/importer.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/module.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/module.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/pygtkcompat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/pygtkcompat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/types.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/types.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_compat.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_constants.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_error.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gtktemplate.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_option.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_ossighelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_propertyhelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_signalhelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/docstring.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/importer.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/module.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GIMarshallingTests.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GLib.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GObject.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gdk.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GdkPixbuf.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gio.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gtk.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Pango.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GIMarshallingTests.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GIMarshallingTests.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GLib.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GLib.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GObject.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GObject.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gdk.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gdk.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GdkPixbuf.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GdkPixbuf.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gio.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gio.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gtk.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gtk.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Pango.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Pango.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/keysyms.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/keysyms.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/keysyms.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/pygtkcompat.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/types.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/generictreemodel.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/generictreemodel.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/pygtkcompat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/pygtkcompat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/generictreemodel.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/pygtkcompat.py





^^^^=https://pastebin.com/iuZWHQse ^^^^

----------
type:  -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38754>
_______________________________________

From report at bugs.python.org  Sat Nov  9 06:12:32 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 09 Nov 2019 11:12:32 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573297952.89.0.0540858654966.issue22367@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 85e415108226cc5f3fdddd70196fc4c2a1d0f7f4 by Miss Islington (bot) in branch '3.8':
bpo-22367: Add tests for fcntl.lockf(). (GH-17010)
https://github.com/python/cpython/commit/85e415108226cc5f3fdddd70196fc4c2a1d0f7f4


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Sat Nov  9 06:12:39 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 09 Nov 2019 11:12:39 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573297959.57.0.788211087666.issue22367@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 917dbe350a762ed6d75b7d074f3fb87975ba717b by Miss Islington (bot) in branch '3.7':
bpo-22367: Add tests for fcntl.lockf(). (GH-17010)
https://github.com/python/cpython/commit/917dbe350a762ed6d75b7d074f3fb87975ba717b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Sat Nov  9 06:13:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Nov 2019 11:13:39 +0000
Subject: [issue38635] Simplify decoding the ZIP64 extra field and make it
 tolerant to extra data
In-Reply-To: <1572381300.43.0.604148893279.issue38635@roundup.psfhosted.org>
Message-ID: <1573298019.76.0.861144886923.issue38635@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e27449da92b13730a5e11182f329d5da98a5e05b by Serhiy Storchaka in branch 'master':
bpo-38635: Simplify decoding the ZIP64 extra field and make it tolerant to extra data. (GH-16988)
https://github.com/python/cpython/commit/e27449da92b13730a5e11182f329d5da98a5e05b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38635>
_______________________________________

From report at bugs.python.org  Sat Nov  9 06:15:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Nov 2019 11:15:36 +0000
Subject: [issue38635] Simplify decoding the ZIP64 extra field and make it
 tolerant to extra data
In-Reply-To: <1572381300.43.0.604148893279.issue38635@roundup.psfhosted.org>
Message-ID: <1573298136.57.0.927205556376.issue38635@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38635>
_______________________________________

From report at bugs.python.org  Sat Nov  9 07:26:48 2019
From: report at bugs.python.org (Andrew Ushakov)
Date: Sat, 09 Nov 2019 12:26:48 +0000
Subject: [issue38755] Long unicode string causes SyntaxError: Non-UTF-8 code
 starting with '\xe2' in file ..., but no encoding declared;
 see http://python.org/dev/peps/pep-0263/ for details
Message-ID: <1573302408.95.0.156655994529.issue38755@roundup.psfhosted.org>


New submission from Andrew Ushakov <andrew.ushakov at gmail.com>:

Not very long unicode comment #, space and then 170 or more repetitions of the utf8 symbol ? (b'\xe2\x96\x91'.decode()) 

# ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

causes syntax error:

SyntaxError: Non-UTF-8 code starting with '\xe2' in file tst112.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

Python file is attached. Second example is similar, but here unicode string with similar length is used as an argument of a print function.

print('\n????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????')

Similar Issue34979 was submitted one year ago...

----------
components: Interpreter Core
files: tst112.py
messages: 356298
nosy: Andrew Ushakov
priority: normal
severity: normal
status: open
title: Long unicode string causes SyntaxError: Non-UTF-8 code starting with '\xe2' in file ..., but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
versions: Python 3.8
Added file: https://bugs.python.org/file48703/tst112.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38755>
_______________________________________

From report at bugs.python.org  Sat Nov  9 07:43:01 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Nov 2019 12:43:01 +0000
Subject: [issue38755] Long unicode string causes SyntaxError: Non-UTF-8 code
 starting with '\xe2' in file ..., but no encoding declared;
 see http://python.org/dev/peps/pep-0263/ for details
In-Reply-To: <1573302408.95.0.156655994529.issue38755@roundup.psfhosted.org>
Message-ID: <1573303381.37.0.454825915248.issue38755@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38755>
_______________________________________

From report at bugs.python.org  Sat Nov  9 08:08:09 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 09 Nov 2019 13:08:09 +0000
Subject: [issue38740] Line count mismatch between open() vs sys.stdin api calls
In-Reply-To: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>
Message-ID: <1573304889.37.0.548749756104.issue38740@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38740>
_______________________________________

From report at bugs.python.org  Sat Nov  9 08:09:41 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 09 Nov 2019 13:09:41 +0000
Subject: [issue35278] [security] directory traversal in tempfile prefix
In-Reply-To: <1542631563.19.0.788709270274.issue35278@psf.upfronthosting.co.za>
Message-ID: <1573304981.13.0.748531806761.issue35278@roundup.psfhosted.org>


Martijn Pieters <mj at python.org> added the comment:

I found this issue after helping someone solve a Stack Overflow question at https://stackoverflow.com/q/58767241/100297; they eventually figured out that their prefix was a path, not a path element.

I'd be all in favour of making tempfile._sanitize_params either reject a prefix or suffix with `os.sep` or `os.altsep` characters, or just take the last element of os.path.split().

----------
nosy: +mjpieters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35278>
_______________________________________

From report at bugs.python.org  Sat Nov  9 08:10:46 2019
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 09 Nov 2019 13:10:46 +0000
Subject: [issue36852] Python3.7.2 fails to cross-compile (yocto /
 openembedded) when target is mips softfloat
In-Reply-To: <1557331268.61.0.662119534756.issue36852@roundup.psfhosted.org>
Message-ID: <1573305046.36.0.290140781295.issue36852@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

The idea with the extension names is to have different names for different ABIs. See https://wiki.debian.org/Multiarch/Tuples for the list of ABIs that are "known", or documented.

mips-linux-gnu is documented as MIPS32r2+FPXX, which is a different ABI than MIPS32r2 apparently, and not compatible, so it should have a different name.

Other architectures like arm-linux-gnueabi and arm-linux-gnueabihf have the hard/soft difference encode in their GNU triplet name, and apparently nobody did that for mips.

One solution would be to define a mips-linux-gnusf Multiarch name, which then would be different than the GNU triplet.  Note that there's no "authority" to define the Multiarch names, however in most cases the GNU quadruplet without the vendor is chosen as the MA name.

Other solutions could be to define no MA name, or go with your solution, just ignoring things. I'd still prefer something defining a name for this ABI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36852>
_______________________________________

From report at bugs.python.org  Sat Nov  9 08:25:26 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Sat, 09 Nov 2019 13:25:26 +0000
Subject: [issue33695] Have shutil.copytree(),
 copy() and copystat() use cached scandir() stat()s
In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za>
Message-ID: <1573305926.23.0.535381960635.issue33695@roundup.psfhosted.org>


Change by Bruno P. Kinoshita <brunodepaulak at yahoo.com.br>:


----------
pull_requests: +16605
pull_request: https://github.com/python/cpython/pull/17098

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33695>
_______________________________________

From report at bugs.python.org  Sat Nov  9 08:25:26 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Sat, 09 Nov 2019 13:25:26 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1573305926.12.0.37801136051.issue38688@roundup.psfhosted.org>


Change by Bruno P. Kinoshita <brunodepaulak at yahoo.com.br>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Sat Nov  9 08:26:16 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Sat, 09 Nov 2019 13:26:16 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1573305976.69.0.63189632597.issue38688@roundup.psfhosted.org>


Bruno P. Kinoshita <brunodepaulak at yahoo.com.br> added the comment:

Hi,

I did a quick `git bisect` using the example provided, and looks like this regression was added in the fix for bpo-33695, commit 19c46a4c96553b2a8390bf8a0e138f2b23e28ed6.

It looks to me that the iterator returned by with os.scandir(...) is including the newly created dst directory (see the call for `os.makedirs(dst, exist_ok=dirs_exist_ok)` in https://github.com/python/cpython/blob/e27449da92b13730a5e11182f329d5da98a5e05b/Lib/shutil.py#L449).

This results in the function finding an extra directory, and repeating the steps for this folder and its subfolder recursively. This only happens because in the example in this issue, dst is a subdirectory of src.

The bpo-33695 commit had more changes, so I've reverted just this block of the copytree as a tentative fix, and added a unit test: https://github.com/python/cpython/pull/17098

--

Here's a simplified version of what's going on:

```
import os
import shutil

shutil.rmtree('/tmp/test/', True)
os.makedirs('/tmp/test')
with open('/tmp/test/foo', 'w+') as f:
  f.write('foo')

# now we have /tmp/test/foo, let's simulate what happens in copytree on master

with os.scandir('/tmp/test') as entries:
  # up to this point, /tmp/test/foo is the only entry
  os.makedirs('/tmp/test/1/2/3/', exist_ok=True) # <---- when the iterator starts below in `f in entries`, it will find 1 too
  # now 1 will have been added too
  for f in entries:
    print(f)
```

----------
nosy: +kinow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Sat Nov  9 09:58:29 2019
From: report at bugs.python.org (Ralf Gommers)
Date: Sat, 09 Nov 2019 14:58:29 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1573311509.46.0.427909116122.issue38501@roundup.psfhosted.org>


Change by Ralf Gommers <ralf.gommers at gmail.com>:


----------
nosy: +ralf.gommers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38501>
_______________________________________

From report at bugs.python.org  Sat Nov  9 09:59:21 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 09 Nov 2019 14:59:21 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573311561.25.0.103120056344.issue22367@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +16607
pull_request: https://github.com/python/cpython/pull/17099

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Sat Nov  9 11:43:27 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 09 Nov 2019 16:43:27 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1573317807.89.0.0143608860556.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> (a) design the API correctly; 
(b) ship something that definitely works with a proven ThreadPoolExecutor; 
(c) write lots of tests;
(d) write docs;
(e) if (a-d) are OK, refine the implementation later by replacing ThreadPoolExecutor with a proper (eager threads creation) implementation.

That sounds like a good strategy. I'll start working on step a, to build a more robust working implementation (that only uses ThreadPoolExecutor's public API), and then work on c and d once the API is approved. 

> 2. Not using ThreadPoolExecutor at all. We can write our own threads orchestration code, it's not that complicated. If we do that, our implementation will become quite faster than the current run_in_executor.  We can use curio as inspiration.  Last time I profiled asyncio I saw that the code binding concurrent.Future to asyncio.Future is quite complex, brittle, and slow.

> I'm in favor of (2), but let's go through (a-d) steps to get there.

Agreed, I'm also in favor of option (2), but doing (a-d) first. I think this approach will provide far more stability (rather than implementing (2) immediately), as we'll be able to write extensive test coverage using a ThreadPoolExecutor implementation as a base, and then ensure the native asyncio threadpool implementation has the same intended behavior. Afterwards, could even keep the ThreadPoolExecutor version as private for testing purposes. 

The native asyncio version will likely require some additional tests to ensure that the threads are being spawned eagerly, but they should have very similar overall behavior, with the asyncio version having better performance. 

I'm thinking that we could create a new Lib/asyncio/pools.py, for the initial ThreadPoolExecutor implementation, to give us a separate area to work with for native asyncio one in the future. A similar asyncio.ProcessPool API could also be eventually created there as well. It might be feasible to fit the initial implementation in Lib/asyncio/base_events.py, but IMO the native asyncio version would not fit. 

(From the user end it would make no difference, as long as we add pools.__all__ to Lib/asyncio/__init__.py)

My only remaining question that I can think of: should we implement an asyncio.ProcessPool API (using ProcessPoolExecutor's public API) before working on the native asyncio version of asyncio.ThreadPool? 

This would likely allow us to release the executor versions well before the 3.9 beta (2020-05-18), and then the native asyncio versions (with eager spawning) either before 3.9rc1 (2020-08-10) or at some point during 3.10 alpha. I suspect that writing the extensive test coverage will take the most time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Sat Nov  9 12:03:42 2019
From: report at bugs.python.org (Nils Kattenbeck)
Date: Sat, 09 Nov 2019 17:03:42 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
Message-ID: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>


New submission from Nils Kattenbeck <nilskemail at gmail.com>:

I would like to request the addition of generic variants of some of the types in weakref to the typing module.
This would for example include weakref.WeakKeyDictionary among others.

Doing so would allow one to add type annotations to code using such data structures.

----------
components: Library (Lib)
messages: 356304
nosy: Nils Kattenbeck
priority: normal
severity: normal
status: open
title: Add generic versions of weakref types to typing module
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sat Nov  9 12:12:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 09 Nov 2019 17:12:47 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573319567.34.0.133064240114.issue38756@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sat Nov  9 15:19:55 2019
From: report at bugs.python.org (Troulet-lambert Odile)
Date: Sat, 09 Nov 2019 20:19:55 +0000
Subject: [issue38757] mocking an exception,
 arguments do not seem to be passed to the mock
Message-ID: <1573330795.77.0.297424168509.issue38757@roundup.psfhosted.org>


New submission from Troulet-lambert Odile <piscvau at yahoo.fr>:

When patching an Exception with a side_effect to another exception, it seems like the exceiption arguments are not passed to the mock.

----------
components: Tests
files: essai mock_exception.py
messages: 356305
nosy: piscvau
priority: normal
severity: normal
status: open
title: mocking an exception, arguments do not seem to be passed to the mock
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48704/essai mock_exception.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38757>
_______________________________________

From report at bugs.python.org  Sat Nov  9 15:29:38 2019
From: report at bugs.python.org (Anthony)
Date: Sat, 09 Nov 2019 20:29:38 +0000
Subject: [issue38758] @dataclass defaults
Message-ID: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>


New submission from Anthony <anthonysarkis at gmail.com>:

Given one of the motivations of @dataclass is to reduce boilerplate code then, in the context of @dataclass,

x: list = [] should be equal to x: list = field(default_factory=lambda: [])

The example in PEP 557 is not reasonable. It should be:

class D:
    def __init__(self, x=[]):
        self.x = x

That x = None works (without specifying a default factory, and is different from plain "x")  makes the whole "factory" argument even more bizarre. Why would a None Type work, but a List Type not?

I think either the behavior of this should be different or the docs should at address this more clearly.

----------
components: Interpreter Core
messages: 356306
nosy: anthony
priority: normal
severity: normal
status: open
title: @dataclass defaults
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Sat Nov  9 16:41:01 2019
From: report at bugs.python.org (Ben Barbour)
Date: Sat, 09 Nov 2019 21:41:01 +0000
Subject: [issue38759] Python 2.7.9 x64 for Windows version is 2.7.13
Message-ID: <1573335661.07.0.0172616496506.issue38759@roundup.psfhosted.org>


New submission from Ben Barbour <bbarbour at gmail.com>:

When downloading Python 2.7.9 x64, the actual python executable is Python 2.7.13. The 32-bit version has the correct executable.

----------
messages: 356307
nosy: Ben Barbour
priority: normal
severity: normal
status: open
title: Python 2.7.9 x64 for Windows version is 2.7.13
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38759>
_______________________________________

From report at bugs.python.org  Sat Nov  9 16:54:08 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Nov 2019 21:54:08 +0000
Subject: [issue38759] Python 2.7.9 x64 for Windows version is 2.7.13
In-Reply-To: <1573335661.07.0.0172616496506.issue38759@roundup.psfhosted.org>
Message-ID: <1573336448.14.0.205408913475.issue38759@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38759>
_______________________________________

From report at bugs.python.org  Sat Nov  9 17:46:08 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 09 Nov 2019 22:46:08 +0000
Subject: [issue38759] Python 2.7.9 x64 for Windows version is 2.7.13
In-Reply-To: <1573335661.07.0.0172616496506.issue38759@roundup.psfhosted.org>
Message-ID: <1573339568.42.0.320349730428.issue38759@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

That's a shame.

If someone has the actual file (I don't), they can publish it elsewhere. Or if one of our team is prepared to validate it (I'm not) we can overwrite what's there.

Otherwise, the fix is to use the latest version of Python, which is neither of those mentioned in this report.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38759>
_______________________________________

From report at bugs.python.org  Sat Nov  9 17:49:15 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 09 Nov 2019 22:49:15 +0000
Subject: [issue38734] Python 3.7 and 3.8 in Windows Store do not start under
 git bash
In-Reply-To: <1573122494.13.0.703066612304.issue38734@roundup.psfhosted.org>
Message-ID: <1573339755.37.0.395907094168.issue38734@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The problem is that Cygwin (on which MinGW and Git Bash are based) tries to read the contents of the executable file, rather than just executing it. The type of link used by Windows here cannot be read as a normal file.

The provided workaround is the best we can offer. Someone who is allowed to handle GPL code without impacting their job (not me) could try removing whatever additional check is being attempted here in Cygwin.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38734>
_______________________________________

From report at bugs.python.org  Sat Nov  9 17:53:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 09 Nov 2019 22:53:38 +0000
Subject: [issue38728] Update PC/pyconfig.h to support disabling auto linking
In-Reply-To: <1573080091.42.0.697826916573.issue38728@roundup.psfhosted.org>
Message-ID: <1573340018.0.0.671187400932.issue38728@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I'm not totally averse to just removing the link pragmas completely, but since that's got significant compatibility impact, I'm happy with this approach.

Let's shorten the name though. "PY_NO_LINK_LIB" might be better?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38728>
_______________________________________

From report at bugs.python.org  Sat Nov  9 17:55:28 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 09 Nov 2019 22:55:28 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573340128.14.0.252938086438.issue38756@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

OK, can you give some example use cases? Can you provide a list of types that you want to see added?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sat Nov  9 18:18:29 2019
From: report at bugs.python.org (Han You)
Date: Sat, 09 Nov 2019 23:18:29 +0000
Subject: [issue38760] Document for urllib.error.HTTPError.headers Should
 Specify What Version
Message-ID: <1573341509.41.0.260213311106.issue38760@roundup.psfhosted.org>


New submission from Han You <hanyourmd at gmail.com>:

It says "New in version 3.4." so I put `urllib3>=3.4` in my requirements.txt. Turned out it is referring to the Python version.

https://docs.python.org/3.7/library/urllib.error.html#urllib.error.HTTPError.headers

----------
assignee: docs at python
components: Documentation
messages: 356312
nosy: Han You, docs at python
priority: normal
severity: normal
status: open
title: Document for urllib.error.HTTPError.headers Should Specify What Version
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38760>
_______________________________________

From report at bugs.python.org  Sat Nov  9 19:20:51 2019
From: report at bugs.python.org (Nils Kattenbeck)
Date: Sun, 10 Nov 2019 00:20:51 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573345251.28.0.161181541738.issue38756@roundup.psfhosted.org>


Nils Kattenbeck <nilskemail at gmail.com> added the comment:

A possible use case would be having multiple users and some groups said users can belong to. When using a WeakSet a user won't be part of a groups after he deleted his account without having to iterate over all groups.

class User: pass

class Group:
  users: WeakSet[User]

  def __init__(self, users: Iterable[User]):
    self.users = WeakSet(users)

# somewhere else a collection of all active users


Types I would like to see added as a generic would be primarily:
- WeakKeyDictionary
- WeakValueDictionary
- WeakSet

Additionally it would be nice to have generic versions of:
- ref (would probably return Optional[T] on call?)
- WeakMethod
- ProxyType
- CallableProxyType

Although the last two could probably be just annotated using T because they mostly should behave the same...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sat Nov  9 19:40:21 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 10 Nov 2019 00:40:21 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573346421.18.0.134265251916.issue38758@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Sat Nov  9 21:44:44 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Nov 2019 02:44:44 +0000
Subject: [issue38757] mocking an exception,
 arguments do not seem to be passed to the mock
In-Reply-To: <1573330795.77.0.297424168509.issue38757@roundup.psfhosted.org>
Message-ID: <1573353884.44.0.738820562879.issue38757@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38757>
_______________________________________

From report at bugs.python.org  Sat Nov  9 23:49:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Nov 2019 04:49:26 +0000
Subject: [issue38757] mocking an exception,
 arguments do not seem to be passed to the mock
In-Reply-To: <1573330795.77.0.297424168509.issue38757@roundup.psfhosted.org>
Message-ID: <1573361366.33.0.271459329886.issue38757@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Currently, the exception is not instantiated. Maybe we can check if it's callable and pass args, kwargs to the exception constructor to be raised.

diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index a48132c5b1..f5bcb911f5 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -1145,7 +1145,10 @@ class CallableMixin(Base):
         effect = self.side_effect
         if effect is not None:
             if _is_exception(effect):
-                raise effect
+                if _callable(effect):
+                    raise effect(*args, **kwargs)
+                else:
+                    raise effect
             elif not _callable(effect):
                 result = next(effect)
                 if _is_exception(result):

----------
nosy: +cjw296, lisroach, mariocj89, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38757>
_______________________________________

From report at bugs.python.org  Sat Nov  9 23:52:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Nov 2019 04:52:51 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
In-Reply-To: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>
Message-ID: <1573361571.96.0.707791843629.issue38753@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

John, would you like to raise a PR for this? The fix would be to add versionadded sphinx directive to https://github.com/python/cpython/blob/master/Doc/library/unittest.mock.rst . I am marking it as easy.

----------
keywords: +easy, newcomer friendly
stage:  -> needs patch
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Sat Nov  9 23:57:02 2019
From: report at bugs.python.org (John Belmonte)
Date: Sun, 10 Nov 2019 04:57:02 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
In-Reply-To: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>
Message-ID: <1573361822.76.0.377061735078.issue38753@roundup.psfhosted.org>


John Belmonte <john at neggie.net> added the comment:

yes, will do

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Sat Nov  9 23:57:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Nov 2019 04:57:40 +0000
Subject: [issue38760] Document for urllib.error.HTTPError.headers Should
 Specify What Version
In-Reply-To: <1573341509.41.0.260213311106.issue38760@roundup.psfhosted.org>
Message-ID: <1573361860.14.0.0876501575176.issue38760@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. But this is a common convention across the docs to add versionadded and versionchanged directive that are rendered as new in version and changed in version with version being Python's version since docs is for CPython. I am not sure if this could be clarified further without being verbose and changing directive would cause all docs to be changed.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38760>
_______________________________________

From report at bugs.python.org  Sun Nov 10 00:23:33 2019
From: report at bugs.python.org (John Belmonte)
Date: Sun, 10 Nov 2019 05:23:33 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
In-Reply-To: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>
Message-ID: <1573363413.34.0.0027858819143.issue38753@roundup.psfhosted.org>


Change by John Belmonte <john at neggie.net>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Sun Nov 10 00:36:00 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Nov 2019 05:36:00 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573364160.79.0.432616536657.issue38756@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Well, in typeshed, weakref.WeakSet and the others are generic, so you should be able to write

  from __future__ import annotations

  from weakref import WeakSet

  users: WeakSet[User]

Or if you need to support Python versions < 3.7, you could write

  users: 'WeakSet[User]'

Does that not solve your problem? It would be easier than adding yet another random class (or classes) to typing, which won't work for Python < 3.9 because typing.py is in the stdlib (and PEP 484 is no longer provisional).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sun Nov 10 00:53:43 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Nov 2019 05:53:43 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1573365223.69.0.510610554192.issue38673@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Regarding the IDLE mystery, *if* there's a difference between how it treats " # a" and "# a", this must be due to some part of the code that's invoked before _maybe_compile() is called, right?

But that's immaterial to this bug -- I'm only complaining about the "builtin" REPL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Sun Nov 10 01:57:52 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 10 Nov 2019 06:57:52 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573369072.95.0.832825795615.issue26353@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +16609
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/17103

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Sun Nov 10 02:00:43 2019
From: report at bugs.python.org (Chris Withers)
Date: Sun, 10 Nov 2019 07:00:43 +0000
Subject: [issue38757] mocking an exception,
 arguments do not seem to be passed to the mock
In-Reply-To: <1573361366.33.0.271459329886.issue38757@roundup.psfhosted.org>
Message-ID: <B30E9C22-E5FB-40D2-B1A0-EAFD1765499C@withers.org>


Chris Withers <chris at withers.org> added the comment:

Not sure this is correct, if an effect is an exception and requires args, then it should be passed as an instance, not a class:

Mock(side_effect=MyException(?foo?))

> On 10 Nov 2019, at 04:49, Karthikeyan Singaravelan <report at bugs.python.org> wrote:
> 
> 
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
> 
> Currently, the exception is not instantiated. Maybe we can check if it's callable and pass args, kwargs to the exception constructor to be raised.
> 
> diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
> index a48132c5b1..f5bcb911f5 100644
> --- a/Lib/unittest/mock.py
> +++ b/Lib/unittest/mock.py
> @@ -1145,7 +1145,10 @@ class CallableMixin(Base):
>         effect = self.side_effect
>         if effect is not None:
>             if _is_exception(effect):
> -                raise effect
> +                if _callable(effect):
> +                    raise effect(*args, **kwargs)
> +                else:
> +                    raise effect
>             elif not _callable(effect):
>                 result = next(effect)
>                 if _is_exception(result):
> 
> ----------
> nosy: +cjw296, lisroach, mariocj89, michael.foord
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38757>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38757>
_______________________________________

From report at bugs.python.org  Sun Nov 10 04:39:21 2019
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 10 Nov 2019 09:39:21 +0000
Subject: [issue38757] mocking an exception,
 arguments do not seem to be passed to the mock
In-Reply-To: <1573330795.77.0.297424168509.issue38757@roundup.psfhosted.org>
Message-ID: <1573378761.96.0.339960166572.issue38757@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

The reason why it seems that "no arguments are beeing passed" is because the exception is not being raised by you, but by mock itself when the exception is trying to be created. When an exception type is passed as side_effect, the mock modules raises such exception on the callable (the creation of the initial exception) To confirm this, just try removing the "raise" and leave the creation of the exception only.

I'd suggest that you use `wraps` rather than `side_effect`. That will make your example work.

Alternatively, if you need to use `side_effect`, you can use a wrapper so mock won't raise an exception when it sees that one:

```

def wrapper(*args, **kwargs):
    return MockError(*args, **kwargs)

patcher = patch('__main__.ProductionError', side_effect=wrapper)

```


I think this can be closed as a non-issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38757>
_______________________________________

From report at bugs.python.org  Sun Nov 10 05:13:04 2019
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 10 Nov 2019 10:13:04 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573380784.97.0.877299995256.issue38747@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Well, maybe too much feature requests in a single report. I'll report them separately, with more rationale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Sun Nov 10 05:22:44 2019
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 10 Nov 2019 10:22:44 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573381364.62.0.0591084653873.issue38747@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Steven: currently I'm developing `frozendict` as part of CPython. About IDLE, IDLE can't be used on a server without a GUI. Furthermore, I *really* hope that IDLE is simply a GUI wrapper of REPL, with some additional features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Sun Nov 10 05:58:25 2019
From: report at bugs.python.org (Nils Kattenbeck)
Date: Sun, 10 Nov 2019 10:58:25 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573383505.7.0.1473193104.issue38756@roundup.psfhosted.org>


Nils Kattenbeck <nilskemail at gmail.com> added the comment:

Yes thank you, using 'from __future__ import annotations' works fantastic.

I did not knew about this functionality of the annotations future import statement, I thought it was only for postponed evaluation but I probably missed something in the PEP...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sun Nov 10 06:30:45 2019
From: report at bugs.python.org (Nils Kattenbeck)
Date: Sun, 10 Nov 2019 11:30:45 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573385445.58.0.747599794799.issue38756@roundup.psfhosted.org>


Nils Kattenbeck <nilskemail at gmail.com> added the comment:

Okay nevermind, after looking in the PEP again and inspecting the __annotations__ property I learned that annotations are never evaluated and just saved as a string when using said future statement.

However this may still be relevant as typing.get_type_hints will still fail. For my use case however this is sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sun Nov 10 06:39:15 2019
From: report at bugs.python.org (Nils Kattenbeck)
Date: Sun, 10 Nov 2019 11:39:15 +0000
Subject: [issue38761] weakref.WeakSet not instanceof collections.abc.Set
Message-ID: <1573385955.24.0.347004236069.issue38761@roundup.psfhosted.org>


New submission from Nils Kattenbeck <nilskemail at gmail.com>:

Instances of weakref.WeakSet are not instances of Set and therefore not of MutableSet but they are instances of Collection.
They however implement all required methods for a MutableSet and Weak(Key|Value)Dictionary are correctly identified.
Is this just an oversight or am I missing something?


from weakref import WeakKeyDictionary, WeakValueDictionary, WeakSet
from collections.abc import MutableMapping, Collection, Set, MutableSet

wkdict = WeakKeyDictionary()
wvdict = WeakValueDictionary()
ws = WeakSet()

assert isinstance(wkdict, MutableMapping)
assert isinstance(wvdict, MutableMapping)
assert isinstance(ws, Collection)
assert not isinstance(ws, Set)
assert not isinstance(ws, MutableSet)

----------
components: Library (Lib)
messages: 356326
nosy: Nils Kattenbeck
priority: normal
severity: normal
status: open
title: weakref.WeakSet not instanceof collections.abc.Set
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38761>
_______________________________________

From report at bugs.python.org  Sun Nov 10 08:41:04 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 10 Nov 2019 13:41:04 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573393264.83.0.851612683264.issue38747@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> For example, I would be shocked if it wasn't absolutely trivial 
> for the current implementation to add auto-indenting following 
> a colon. That feature alone would be a win for usability.

That would be a non-trivial change in Windows. I think it's at least possible using the high-level console API. It could be implemented with the pInputControl parameter of ReadConsoleW in combination with WriteConsoleW. This is how the CMD shell implements tab completion for file paths. That said, many of the proposed UI enhancements cannot be implemented in Windows using the high-level console API. 

IPython used to depend on readline. (5.0 switched to prompt_toolkit instead.) In Windows this was via the pyreadline package, which uses the low-level console API via ctypes. pyreadline is apparently abandoned (last updated in 2015). Maybe CPython could incorporate a fork of pyreadline that fixes bugs (Unicode support in particular) and updates it to use a C extension instead of ctypes.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Sun Nov 10 10:30:20 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 10 Nov 2019 15:30:20 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573399820.8.0.44272263145.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

One question:
Is there any reason to choose the name is `open_file_descriptor` not `open_file_description`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Sun Nov 10 10:51:56 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 10 Nov 2019 15:51:56 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573401115.99.0.252148697196.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

According to https://www.gnu.org/software/libc/manual/html_node/Open-File-Description-Locks.html

It is important to distinguish between the open file description (an instance of an open file, usually created by a call to open) and an open file descriptor, which is a numeric value that refers to the open file description. The locks described here are associated with the open file description and not the open file descriptor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Sun Nov 10 11:25:58 2019
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 10 Nov 2019 16:25:58 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573403158.48.0.905581370786.issue38747@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

@Eryk: why a C extension apart and not a patch to `readline`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Sun Nov 10 11:33:42 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Nov 2019 16:33:42 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573403622.75.0.22701709271.issue38756@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@ilevkivskyi Is this important enough to change get_type_hints()?

Otherwise let?s close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sun Nov 10 12:19:46 2019
From: report at bugs.python.org (Daniel Kahn Gillmor)
Date: Sun, 10 Nov 2019 17:19:46 +0000
Subject: [issue37564] ArgumentParser should support bool type according to
 truth values
In-Reply-To: <1562857832.91.0.995710130518.issue37564@roundup.psfhosted.org>
Message-ID: <1573406386.39.0.29104857297.issue37564@roundup.psfhosted.org>


Daniel Kahn Gillmor <dkg at fifthhorseman.net> added the comment:

this is a common enough question, and enough people want this behavior, that argparse should supply it.

I'm imagining that:  

   type='bool'

would be fine for triggering this behavior, instead of the shadowing that could happen with:

   type=bool

so if type='bool' is supplied, the following things would happen:

 * argparse could use strtobool to interpret the incoming string
 * the default metavar would look something like "{true,false}"
 * followon packages like argcomplete could enumerate the range of different values that strtobool accepts

This is still english-specific -- but it's because strtobool is english-specific, and fixes in strtobool would automatically fix type='bool' here.

----------
nosy: +dkg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37564>
_______________________________________

From report at bugs.python.org  Sun Nov 10 13:26:16 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 10 Nov 2019 18:26:16 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573410376.04.0.236405920632.issue38756@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

We already have https://github.com/python/typing/issues/508 for "smart" `get_type_hints()` that would use LBYL. Also we had a similar discussion about PathLike, and ultimately decided not to make `typing` a place for generic versions of everything.

Finally, in view of PEP 585 some of these things may actually become subscriptable at runtime. So I propose to just close this issue.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sun Nov 10 16:02:00 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Nov 2019 21:02:00 +0000
Subject: [issue37564] ArgumentParser should support bool type according to
 truth values
In-Reply-To: <1562857832.91.0.995710130518.issue37564@roundup.psfhosted.org>
Message-ID: <1573419720.43.0.063450138336.issue37564@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Right now "type" has a clear and understandable action of invoking a callable.   Imbuing "type" with other semi-magical capabilities opens a new can of worms.

Unless some persuasive new commentary appears in the next few days, I'm going to close this feature request and the associated PR.

At some point, we should consider adding a recipes/faq section to the docs.  That would help people bridge from their goals to the actual capabilities offered by the module.

Also, we should make strong suggestions about the separation of responsibilities between the parser and the downstream code that acts on the parsed variables (much like the discussion in the templating world about keeping business logic outside of the template and instead focusing on formatting logic).

For the case at hand, there are several ways to go:

      # proposed new magic with hard-wired
      # truthy/false words: yes True 1 true Y si oui ...
      parser.add_argument("--mybool", type='bool')

      # existing capability where the user controls
      # exactly which logic to apply
      parser.add_argument("--mybool", type=str_to_bool)

      # Existing capability with downstream processing
      parser.add_argument("--mybool", choices={'True', 'False', 'Yes', 'No'}
      args = parser.parse_args()
      mybool = args.mybool in {'True', 'Yes'}

----------
assignee:  -> rhettinger
nosy: +rhettinger
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37564>
_______________________________________

From report at bugs.python.org  Sun Nov 10 16:04:48 2019
From: report at bugs.python.org (Nils Kattenbeck)
Date: Sun, 10 Nov 2019 21:04:48 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573419888.02.0.46029133623.issue38756@roundup.psfhosted.org>


Nils Kattenbeck <nilskemail at gmail.com> added the comment:

Okay, if I want to start a discussion about adding weakref types to PEP 585 where should do it? The mailing list or as an issue in the PEP repo?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sun Nov 10 16:08:36 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Nov 2019 21:08:36 +0000
Subject: [issue37564] ArgumentParser should support bool type according to
 truth values
In-Reply-To: <1562857832.91.0.995710130518.issue37564@roundup.psfhosted.org>
Message-ID: <1573420116.5.0.676963756117.issue37564@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg356334

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37564>
_______________________________________

From report at bugs.python.org  Sun Nov 10 16:08:49 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Nov 2019 21:08:49 +0000
Subject: [issue37564] ArgumentParser should support bool type according to
 truth values
In-Reply-To: <1562857832.91.0.995710130518.issue37564@roundup.psfhosted.org>
Message-ID: <1573420129.09.0.862956790456.issue37564@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Right now "type" has a clear and understandable action of invoking a callable.   Imbuing "type" with other semi-magical capabilities opens a new can of worms.

Unless some persuasive new commentary appears in the next few days, I'm going to close this feature request and the associated PR.

At some point, we should consider adding a recipes/faq section to the docs.  That would help people bridge from their goals to the actual capabilities offered by the module.

Also, we should make strong suggestions about the separation of responsibilities between the parser and the downstream code that acts on the parsed variables (much like the discussion in the templating world about keeping business logic outside of the template and instead focusing on formatting logic).

For the case at hand, there are several ways to go:

      # Proposed new magic with hard-wired
      # truthy/false words: yes True 1 true Y si oui ...
      parser.add_argument("--mybool", type='bool')

      # Existing capability where the user controls
      # exactly which logic to apply
      parser.add_argument("--mybool", type=str_to_bool)

      # Existing capability with downstream processing
      parser.add_argument("--mybool", choices={'True', 'False', 'Yes', 'No'}
      args = parser.parse_args()
      mybool = args.mybool in {'True', 'Yes'}

      # Existing capability with explicit flag arguments
      # (the highly upvoted "canonical" solution StackOverflow)
      parser.add_argument('--feature', dest='feature', action='store_true')
      parser.add_argument('--no-feature', dest='feature', action='store_false')
      parser.set_defaults(feature=True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37564>
_______________________________________

From report at bugs.python.org  Sun Nov 10 16:32:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Nov 2019 21:32:50 +0000
Subject: [issue38761] weakref.WeakSet not instanceof collections.abc.Set
In-Reply-To: <1573385955.24.0.347004236069.issue38761@roundup.psfhosted.org>
Message-ID: <1573421570.26.0.137125968997.issue38761@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We could register the WeakSet in _collections_abc, right after MutableSet is defined.  That module only registered builtins so that it can avoid imports; however, since we know that WeakSet is already loaded, it is reasonable to add an import for registration purposes.

This was likely omitted because WeakSet is used in the implementation of the ABC.

Marking this as a proposed enhancement rather than as a bug because the collections ABCs are under no obligation to register anything more than the builtins.

----------
assignee:  -> rhettinger
nosy: +gvanrossum, rhettinger
type:  -> enhancement
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38761>
_______________________________________

From report at bugs.python.org  Sun Nov 10 16:42:36 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Nov 2019 21:42:36 +0000
Subject: [issue38761] weakref.WeakSet not instanceof collections.abc.Set
In-Reply-To: <1573385955.24.0.347004236069.issue38761@roundup.psfhosted.org>
Message-ID: <1573422156.68.0.590044827167.issue38761@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38761>
_______________________________________

From report at bugs.python.org  Sun Nov 10 16:53:15 2019
From: report at bugs.python.org (Delgan)
Date: Sun, 10 Nov 2019 21:53:15 +0000
Subject: [issue38762] Logging displays wrong "processName" if "sys.modules" is
 cleared in child process
Message-ID: <1573422795.72.0.548665383031.issue38762@roundup.psfhosted.org>


New submission from Delgan <delgan.py at gmail.com>:

Hi.

In order to display the process name in logs, the "logging" module checks for the presence of "multiprocessing" in "sys.modules" before calling "current_process()". If "multiprocessing" is not found in "sys.modules", it assumes that the current process is the main one.

See : https://github.com/python/cpython/blob/af46450bb97ab9bd38748e75aa849c29fdd70028/Lib/logging/__init__.py#L340-L341

However, nothing prevents a child process to delete "sys.module['multiprocessing']", which causes the process name to be wrongly displayed as "MainProcess".

I attached a reproducible example, but this is straightforward to understand. Although it should not happen very often in practice, it is still theoretically possible. Obviously, one could say "just don't clear sys.modules", but I suppose there might exist tools doing such thing for good reasons (like resetting the test environment).

Issues which lead to the current implementation:
- issue4301
- issue7120
- issue8200

Possible fixes: 
- Force import "multiprocessing.current_process()" even if not already loaded
- Add function "os.main_pid()" and set "processName" to "MainProcess" only if "os.getpid() == os.main_pid()"

----------
components: Library (Lib)
files: test.py
messages: 356338
nosy: Delgan
priority: normal
severity: normal
status: open
title: Logging displays wrong "processName" if "sys.modules" is cleared in child process
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48705/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38762>
_______________________________________

From report at bugs.python.org  Sun Nov 10 16:59:56 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Nov 2019 21:59:56 +0000
Subject: [issue38751] Document maximum JSON depth or remove it.
In-Reply-To: <1573258979.82.0.0958429006244.issue38751@roundup.psfhosted.org>
Message-ID: <1573423196.77.0.644808179656.issue38751@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

There is nothing here specific to JSON.  It is Python's normal (and documented) limit on recursion. 

If needed, you can change the limit to as large as needed:

    import json
    import sys
    sys.setrecursionlimit(50_000)

    foo = {}

    for i in range(10_000):
        foo = {'bar': foo}
    s = json.dumps(foo)
    print(len(s))

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38751>
_______________________________________

From report at bugs.python.org  Sun Nov 10 17:00:09 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Nov 2019 22:00:09 +0000
Subject: [issue38751] Document maximum JSON depth or remove it.
In-Reply-To: <1573258979.82.0.0958429006244.issue38751@roundup.psfhosted.org>
Message-ID: <1573423209.13.0.496924018489.issue38751@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38751>
_______________________________________

From report at bugs.python.org  Sun Nov 10 17:05:56 2019
From: report at bugs.python.org (Eric Meyer)
Date: Sun, 10 Nov 2019 22:05:56 +0000
Subject: [issue32879] Race condition in multiprocessing Queue
In-Reply-To: <1519091702.0.0.467229070634.issue32879@psf.upfronthosting.co.za>
Message-ID: <1573423556.68.0.212373185241.issue32879@roundup.psfhosted.org>


Eric Meyer <ericallenmeyer at gmail.com> added the comment:

The problem I was seeing ended up being improper GIL management in a c++ extension. It seems putting items that were created without the GIL on the queue causes a seg fault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32879>
_______________________________________

From report at bugs.python.org  Sun Nov 10 17:09:23 2019
From: report at bugs.python.org (Troulet-lambert Odile)
Date: Sun, 10 Nov 2019 22:09:23 +0000
Subject: [issue38763] mock with side effect : assert_called_once returns None
 while call_count returns 1
Message-ID: <1573423763.08.0.825923255021.issue38763@roundup.psfhosted.org>


New submission from Troulet-lambert Odile <piscvau at yahoo.fr>:

Using a mock with side_effect, I would expect that assert_called_once returns True if the mock has been called.
Yet it returns None while call_count== 1 returns True.

If this is not a bug, I would welcome some explanation in the documentation.

----------
components: Tests
files: bugmock.tar
messages: 356341
nosy: piscvau
priority: normal
severity: normal
status: open
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48706/bugmock.tar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38763>
_______________________________________

From report at bugs.python.org  Sun Nov 10 18:29:02 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Nov 2019 23:29:02 +0000
Subject: [issue38756] Add generic versions of weakref types to typing module
In-Reply-To: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>
Message-ID: <1573428542.98.0.939214512972.issue38756@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

PEP 585 says

Discussions-To: Typing-Sig <typing-sig at python.org>

So I'd start there.

(But honestly I think what Ivan meant is that it would automatically work. Read the PEP carefully before posting if you disagree.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38756>
_______________________________________

From report at bugs.python.org  Sun Nov 10 18:37:39 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Nov 2019 23:37:39 +0000
Subject: [issue38761] weakref.WeakSet not instanceof collections.abc.Set
In-Reply-To: <1573385955.24.0.347004236069.issue38761@roundup.psfhosted.org>
Message-ID: <1573429059.38.0.997666246095.issue38761@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

As I wrote between the lines in the PR, this would be a bug in the weakref module, not a bug in collections.abc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38761>
_______________________________________

From report at bugs.python.org  Sun Nov 10 21:31:05 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 11 Nov 2019 02:31:05 +0000
Subject: [issue38764] Deterministic globbing.
Message-ID: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

This has been discussed before, but we now have examples in the news of glob's non-deterministic behavior causing some real headaches for hundreds of people in the scientific community. After some cursory discussion (https://discuss.python.org/t/a-code-glitch-may-have-caused-errors-in-more-than-100-published-studies/2583) it was suggested that this issue would at least be worth revisiting, given the damage... bad programming practices aside.

The attached patch guarantees glob/iglob traversal order across all platforms, and modifies all of the existing tests to check for this.

One reason this was rejected twice before (in both issue 21748, four years ago, and issue 30461, two years ago) was the argument that the user could always just call "sorted" on the returned list if they wanted ordered results. Aside from losing the laziness of iglob, this solution also loses the traversal order, since recursive globs use a breadth-first search. In the attached patch, iglob is still just as lazy as ever, and the traversal is unchanged for anyone using a platform that already returns sorted results.

----------
components: Library (Lib)
messages: 356344
nosy: brandtbucher, njs
priority: normal
severity: normal
status: open
title: Deterministic globbing.
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Sun Nov 10 21:31:58 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 11 Nov 2019 02:31:58 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573439518.2.0.982951308009.issue38764@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Sun Nov 10 22:04:15 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Nov 2019 03:04:15 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573441455.73.0.187701121421.issue38747@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Stephen, I think *you* were the one over-anxious to be dismissive.  In the title Marco refers to "Jupyter console (IPython)" features and in his opening, to "Jupyter console, aka IPython".  Jupyter Console is, I read, QT based.  IPython/Jupyter Notebooks are GUI-based also.  

However, I agree that single process terminal IPython, such as illustrated near the top of
https://ipython.readthedocs.io/en/stable/index.html
is the better reference for comparison.  As pictured, it requires a color terminal with full screen edit.

An important constraint is that instead of users talking to the UI program with menu clicks, they must use "?magic? commands" entered after the '>>>' prompt instead of code.  Guido specifically vetoed the idea of allowing these into IDLE, so he must not want them in the REPL either.

Skipping the rest of your post, I will just restate why I closed this issue.

1. It introduces too many features not directly related.  The existing unix-only completions uses two modules.  I suspect some of the other features would also need new modules.  (But Marco, please don't rush to immediately open 8 new issues.)

Furthest removed, no new module needed: Adding builtins that can be used in REPL as it is. I suspect the answer to that proposal would be to use a PYTHONSTARTUP module with code such as "import pprint as _; pprint = _.pprint"

2. It introduces policy issues that might require a policy change, and that I think should better be discussed on, say, pydev.  Steven and I have obviously gotten different policy impressions from Brett and Guido respectively. I will try to ask on pydev what the current REPL feature policy is, and what people think it should be.  For instance, how far do we want to go is adding features that only work on a subset of systems?

3. I believe that some of the concrete proposals have even more implementation problems than Marco himself acknowledged.  Difficult does not mean prohibited, but coredevs are mostly not interested in working on UIs and it has been Guido's stated-to-me policy that 'advanced' UI/IDE features (not defined) should be left to other projects.

One communication problem is that once python is running in interactive mode, the only thing the user can send to it is lines of Python code.  Consider pasting multiline code with blank lines.  The console feeds pasted lines *1 at a time* to interactive Python, the same as if the user typed them.  So Python does not know if they were typed or pasted.  Nor does it know that there might be a next line already waiting, and if so, what it is (dedented?).  If it does not execute on receiving '\n', when will it?

There are also communication issues in the other direction.  When REPL sends a prompt, everything up to and including a prompt is somehow marked read-only.  But autoindents must be left erasable so a user can dedent.

If that can be solved, including on Windows, I would like IDLE's autoindent code moved to an stdlib module (and polished, if need be) to be used by REPL, IDLE, and anyone else who wishes.  The main function would map a sequence of lines to a PEP-8 compliant indent for the next line.

Syntax-coloring opens a much bigger can of worms.  It requires full screen editing to overwrite existing input.  It also needs to be configurable as part of a configuration system.  IPython requires the user to write "a dictionary mapping Pygments token types to strings defining the style." in a python file with other needed code in a place where IPython can find it.  IDLE lets one modify an existing scheme by clicking on an element in sample code and then a new color and let IDLE handle the storage.

Marco, you said "I *really* hope that IDLE is simply a GUI wrapper of REPL".  Nope.  In a single process, python cannot simultaneous execute a file in batch mode and input lines in interactive mode.  IDLE uses "exec(code, simulated_main_namespace)" and I suspect other simulated shells do something similar.  An advantage is that 'code' can represent complete multiline statements or even an entire module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Sun Nov 10 22:24:48 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Nov 2019 03:24:48 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1573442688.33.0.833694624849.issue38673@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Fix corner case bugs in IDLE would definitely be a separate issue.  But is the 'fix' in _maybe_compile at all applicable to the REPL?  Or might a parser change REPL fix make the code in _maybe_compile unneeded?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Sun Nov 10 22:41:44 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 03:41:44 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573443704.73.0.565727261817.issue38764@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I saw the article as well, but think auto-sorting would have just provided a thin mask over their serious data pipeline bugs.

Also, this isn't the only pathway to seeing file lists:  os.listdir, fnmatch, etc.

I say that we leave it alone and not unnecessarily introduce a breadth-first, recursive sort.  The reasons for the previous rejections still apply.  For the most part our tools that access os services only provide a thin pass-through and tend to neither promise nor do anything extra (even SQL only gives sorted data when the user explicitly requests ORDER By -- the could have provided a default sort but choose not to).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Sun Nov 10 23:11:11 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Nov 2019 04:11:11 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1573445471.08.0.215760493248.issue38673@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> But is the 'fix' in _maybe_compile at all applicable to the REPL?  Or might a parser change REPL fix make the code in _maybe_compile unneeded?

I don't know.  Most of the contortions in code.py codeop.py are meant to emulate what the parser does without help in the REPL: keep asking for input until one of the following happens:

- a syntax error is found;

- a simple statement is parsed till completion;

- an empty line is found at a point where a compound statement is potentially complete.

The bug here is that apparently the above conditions aren't quite enough, and it seems we need to add:

- a line that contains just whitespace and/or a comment is seen before anything else.

The reason that IDLE has to reimplement similar logic is that the parser (actually, the tokenizer) isn't written as a coroutine to which you send lines you read -- it's written as a blocking function that you pass a file and the function will attempt to read lines from the file.  The function returns a parse tree or raise an error.  That model doesn't work in IDLE, which needs to stay reactive while the shell window is in the middle of a statement.

I think we'll find that the bug is *very* old.  IIRC the initial releases of Python didn't have the rule that indentation is ignored between matching parentheses/brackets/braces.  In those days the tokenizer also didn't gracefully skip blank lines, or lines with comments that weren't aligned with the current indentation level.  So then checking for empty lines was good enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Sun Nov 10 23:12:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 04:12:23 +0000
Subject: [issue38761] weakref.WeakSet not instanceof collections.abc.Set
In-Reply-To: <1573385955.24.0.347004236069.issue38761@roundup.psfhosted.org>
Message-ID: <1573445543.88.0.923140502346.issue38761@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 84ac4376587e35d16b4d0977c4f330d9d04b690a by Raymond Hettinger in branch 'master':
bpo-38761: Register WeakSet as a MutableSet (GH-17104)
https://github.com/python/cpython/commit/84ac4376587e35d16b4d0977c4f330d9d04b690a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38761>
_______________________________________

From report at bugs.python.org  Sun Nov 10 23:13:30 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 04:13:30 +0000
Subject: [issue38761] weakref.WeakSet not instanceof collections.abc.Set
In-Reply-To: <1573385955.24.0.347004236069.issue38761@roundup.psfhosted.org>
Message-ID: <1573445610.08.0.158000536489.issue38761@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Nils, thanks for the report.

Guido, thanks for the clarification.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38761>
_______________________________________

From report at bugs.python.org  Sun Nov 10 23:26:19 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 11 Nov 2019 04:26:19 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573446379.23.0.684526023997.issue38764@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

> I saw the article as well, but think auto-sorting would have just provided a thin mask over their serious data pipeline bugs.

This seems like an inappropriately elitist attitude. I'm sure their code has bugs; so does mine and yours. But in fact they did test their code thoroughly, demonstrated that it produced correct results on their system, and it would have produced correct results for their downstream users too if Python's 'glob' had behaved consistently across platforms. Python isn't just for folks who can "git gud" to meet your arbitrary standards.

In addition, auto-sorting has a number of ergonomic benefits, beyond this one case: it makes output more deterministic, makes it easy to estimate progress given just a list of filenames being processed ("hmm, this script has been running for ten minutes and it's only on the Cs, I guess this will take a few hours"), and so on.

> Also, this isn't the only pathway to seeing file lists:  os.listdir, fnmatch, etc.

os.listdir is a genuinely low-level OS-level tool, as indicated by the name, versus 'glob' which is designed as a convenient interface for high-level scripting.

fnmatch doesn't deal with either files or lists, so I'm not sure why you're bringing it up here.

> The reasons for the previous rejections still apply.

The reasons I see in the previous issues are:

- Sorting adds overhead
- It's hard to implement, esp. if iglob uses scandir internally
- iglob can't sort, so glob should be consistent
- it's easy to sort after the fact

But these are all false.

- The overhead added by sorting is negligible. In some informal benchmarks I measured it as ~4% extra CPU time in the worst case, if you're (a) running on Linux with it's ultra-optimized VFS caching, (b) all the directories are already cached in RAM, (c) you're not actually doing anything with the files except calling glob() and then discarding the result. Of course, it's always possible my benchmarks missed an important case; if you have benchmarks that show otherwise please post them so we can discuss.

- The implementation is trivial, as shown from the PR ? literally just replacing two calls to 'list' with calls to 'sorted'.

- iglob being incremental doesn't actually pose any obstacles to sorting. Even if it's using scandir(), it still has to load each individual directory list into memory in one batch, to avoid the risk of leaking file descriptors.

- It's actually not trivial to sort filenames in the natural order afterwards, because you have to split each filename into components. It's also asymptotically slower than doing the sort as-you-go, O(total-files log total-files), versus O(total-files log maximum-individual-directory).

Given that there's at least one extremely clear case where not-sorting caused substantial harm, that there are lots of other minor cases where it's a nice win, and that the costs are negligible, sorting seems like the obviously correct default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Sun Nov 10 23:27:17 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 11 Nov 2019 04:27:17 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573446437.49.0.999534491172.issue38764@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I disagree somewhat with the assessment that glob provides "thin" access to OS services. It is composed of a few low-level utilities, but it exposes them through what I consider to be a fairly high-level, abstract, friendly interface that (aside from ordering, and some symlink stuff) is surprisingly cross-platform.

I originally felt that this was "their own fault", since the behavior is well-documented and the data pipeline was so susceptible to error. But I started thinking more about the fact that the bad globbing made it into peer-reviewed cancer research over a hundred times. Python is a friendly language and glob is a friendly library, so it would be natural for someone without formal engineering experience to reach for both. I'm becoming more and more surprised that glob exposes this type of quirk, for trivial gain.

I respect your opinion though. Another option would be to leave the patch in, but not document the new traversal order. That way we rid ourselves of a class of user errors without exposing implementation details like the type of search used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Sun Nov 10 23:36:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Nov 2019 04:36:22 +0000
Subject: [issue38763] mock with side effect : assert_called_once returns None
 while call_count returns 1
In-Reply-To: <1573423763.08.0.825923255021.issue38763@roundup.psfhosted.org>
Message-ID: <1573446982.28.0.917559355582.issue38763@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

assert_called_once is supposed to raise an AssertionError if the mock is not called and to return None like other assert_* helpers. The return value is not supposed to be used and it's more of an assertion action where if it's None then it's implied to be True.

>>> from unittest.mock import Mock
>>> def side_effect(*args, **kwargs): print("side_effect called")
...
>>> m = Mock(side_effect=side_effect)
>>> m.call_count
0
>>> m.assert_called_once()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/kasingar/stuff/python/cpython/Lib/unittest/mock.py", line 881, in assert_called_once
    raise AssertionError(msg)
AssertionError: Expected 'mock' to have been called once. Called 0 times.
>>> m()
side_effect called
>>> m.call_count
1
>>> m.assert_called_once()
>>> m.assert_called()
>>> m.assert_has_calls([call()])

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38763>
_______________________________________

From report at bugs.python.org  Sun Nov 10 23:36:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Nov 2019 04:36:51 +0000
Subject: [issue38762] Logging displays wrong "processName" if "sys.modules" is
 cleared in child process
In-Reply-To: <1573422795.72.0.548665383031.issue38762@roundup.psfhosted.org>
Message-ID: <1573447010.99.0.878954208184.issue38762@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38762>
_______________________________________

From report at bugs.python.org  Sun Nov 10 23:37:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Nov 2019 04:37:29 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573447049.91.0.903609133422.issue38764@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Mon Nov 11 01:14:14 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 11 Nov 2019 06:14:14 +0000
Subject: [issue38438] argparse "usage" overly-complex with nargs="*"
In-Reply-To: <1570739079.02.0.395133592841.issue38438@roundup.psfhosted.org>
Message-ID: <1573452854.62.0.660913495471.issue38438@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38438>
_______________________________________

From report at bugs.python.org  Mon Nov 11 01:16:11 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 11 Nov 2019 06:16:11 +0000
Subject: [issue38438] argparse "usage" overly-complex with nargs="*"
In-Reply-To: <1570739079.02.0.395133592841.issue38438@roundup.psfhosted.org>
Message-ID: <1573452971.29.0.594703648328.issue38438@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I went ahead and opened a PR, since it's been a month.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38438>
_______________________________________

From report at bugs.python.org  Mon Nov 11 01:57:54 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 11 Nov 2019 06:57:54 +0000
Subject: [issue17642] IDLE add font resizing hot keys and wheel
In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za>
Message-ID: <1573455474.05.0.790977464383.issue17642@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +16613
pull_request: https://github.com/python/cpython/pull/17107

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17642>
_______________________________________

From report at bugs.python.org  Mon Nov 11 04:27:48 2019
From: report at bugs.python.org (dankreso)
Date: Mon, 11 Nov 2019 09:27:48 +0000
Subject: [issue28533] Replace asyncore
In-Reply-To: <1477420324.44.0.338895938894.issue28533@psf.upfronthosting.co.za>
Message-ID: <1573464468.24.0.272139707354.issue28533@roundup.psfhosted.org>


dankreso <dankreso at gmail.com> added the comment:

Hi, is this still open?

I'm happy to work on replacing asyncore usage in one of the other test files.

----------
nosy: +dankreso

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28533>
_______________________________________

From report at bugs.python.org  Mon Nov 11 04:51:20 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Nov 2019 09:51:20 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573465880.7.0.970992088611.issue38764@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If sort the output of glob(), we should sort also the output of Path.glob(), listdir(), and maybe walk().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Mon Nov 11 06:02:53 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 11 Nov 2019 11:02:53 +0000
Subject: [issue38762] Logging displays wrong "processName" if "sys.modules" is
 cleared in child process
In-Reply-To: <1573422795.72.0.548665383031.issue38762@roundup.psfhosted.org>
Message-ID: <1573470173.05.0.0283943193098.issue38762@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This will be a rare use case, and I would expect anyone clearing sys.modules in the child process to handle this consequence themselves (e.g. by reimporting multiprocessing after clearing out the other modules, since they apparently still want some of multiprocessing's functionality in the child process). I'll certainly look at PRs to address the issue using an import of multiprocessing if it's not already there. I'm not so keen on the other approaches you've suggested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38762>
_______________________________________

From report at bugs.python.org  Mon Nov 11 06:41:54 2019
From: report at bugs.python.org (Marco Sulla)
Date: Mon, 11 Nov 2019 11:41:54 +0000
Subject: [issue38747] Slowly introduce a subset of Jupyter console (IPython)
 features into CPython command line interactive mode
In-Reply-To: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>
Message-ID: <1573472514.69.0.659038238259.issue38747@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

@Terry:

> Jupyter Console is, I read, QT based

Nope. It's shell based by default. You can open it also as a QT app, like IDLE, but by default `jupyter console` is via terminal.

> they must use "?magic? commands" entered after the '>>>' prompt 
> instead of code.  Guido specifically vetoed the idea

Indeed I'm against too, and I wrote it. And if you read my proposals, I do not suggest any magic word

> the answer to that proposal would be to use a PYTHONSTARTUP module 
> with code such as "import pprint as _; pprint = _.pprint"

I know this, but it should be the default behaviour, IMHO. I mean, you can invoke `help()` in REPL but also in a `.py`. It makes no sense, but you can do it and you have not to import a separate module before.

> The console feeds pasted lines *1 at a time* to interactive Python

This is fixed by many terminal editors, like `vi`, with bracketed paste mode, as I wrote.

> When REPL sends a prompt, everything up to and including a prompt is 
> somehow marked read-only.

A workaround could be simulate input by user. Ugly but effective.

> Syntax-coloring [...] requires full screen editing

???

> [Syntax-coloring] also needs to be configurable

This could be IMHO delayed, or not implemented at all. If you don't like the colors, you can always not use it :D It will suffice that the colors will be as much as possible readable also by the majority of color-blind person.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38747>
_______________________________________

From report at bugs.python.org  Mon Nov 11 07:04:54 2019
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 11 Nov 2019 12:04:54 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573473894.01.0.582251602163.issue38500@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Fabio,

If the user changes the `__code__` attribute of a function then, AFAICT, your debugger does the wrong thing, but bytecode modification does the right thing.

Suppose we have two functions `spam` and `eggs`.
Set a break point in `eggs`, set `spam.__code__ = eggs.__code__`, then call `spam`.
With bytecode modification, we get the correct result. That is, execution breaks in the source code of `eggs` when `spam` is run.
I think your debugger will do the wrong thing as it will execute the original code of `spam`. Could you confirm what it does?

But that's not the main issue, IMO. The big problem is that changing out the interpreter is not composable, unlike bytecode modification.

Suppose we have MyProfiler and YourDebugger.
MyProfiler wants to record calls and YourDebugger wants to support breakpoints.

With bytecode modification, and some care, we can do both.
Swapping out the interpreter is likely to cause all sorts of errors and confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Mon Nov 11 07:49:34 2019
From: report at bugs.python.org (Chris Withers)
Date: Mon, 11 Nov 2019 12:49:34 +0000
Subject: [issue38757] mocking an exception,
 arguments do not seem to be passed to the mock
In-Reply-To: <1573330795.77.0.297424168509.issue38757@roundup.psfhosted.org>
Message-ID: <1573476574.86.0.413889803984.issue38757@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Agreed.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38757>
_______________________________________

From report at bugs.python.org  Mon Nov 11 09:13:26 2019
From: report at bugs.python.org (Marcin Kasperski)
Date: Mon, 11 Nov 2019 14:13:26 +0000
Subject: [issue36128] ResourceReader for FileLoader inconsistently handles
 path separators
In-Reply-To: <1551215100.55.0.236644911032.issue36128@roundup.psfhosted.org>
Message-ID: <1573481606.34.0.0430322805691.issue36128@roundup.psfhosted.org>


Marcin Kasperski <Marcin.Kasperski at mekk.waw.pl> added the comment:

Hmm, I noticed this but accidentally and tried to port https://github.com/pypa/setuptools/issues/1635 to new api. Well:

>>> import multiprocessing
>>> import sys
>>> reader = sys.modules['multiprocessing'].__spec__.loader.get_resource_reader('multiprocessing')
>>> reader.open_resource('../../../../etc/passwd')
<_io.FileIO name='/usr/lib/python3.7/multiprocessing/../../../../etc/passwd' mode='rb' closefd=True>

I suppose this is the case which deserve some thought (originally I faced it when some webapp used pkg_resources to provide static files and used resource api as a way to validate urls impacted by external input).

Tested on python 3.7.3, on Ubuntu 19.04.

----------
nosy: +Mekk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36128>
_______________________________________

From report at bugs.python.org  Mon Nov 11 09:31:03 2019
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Mon, 11 Nov 2019 14:31:03 +0000
Subject: [issue38765] `ast.AST._attributes` is used by `ast.dump()` but not
 documented
Message-ID: <1573482663.72.0.733055997415.issue38765@roundup.psfhosted.org>


New submission from Pekka Kl?rck <pekka.klarck at gmail.com>:

We have implemented an ast for our own tool so that we extend Python's standard `ast.AST`. When using `ast.dump(node, include_attributes=True)`, we were surprised to notice that line numbers weren't dumped although the docs of `ast.dump()` said they should be and we had set both `lineno` and `end_lineno` attributes to our nodes.

Looking at the implementation of `ast.dump()` revealed that `include_attributes=True` alone wasn't enough, the node also needed to have `_attributes` attribute similarly as it needs to have `_fields` for `ast.dump()` to be able to dump also child nodes. The problem is that `_attributes` isn't documented at all. Related to that, `ast.dump()` using `_fields` isn't documented either, but at least `_fields` is mentioned in the docs otherwise. Relevant links to `ast.dump()` docs and to the source code below.

`ast.AST` documents the `_fields` attribute but doesn't mention similar `_attributes`:
https://docs.python.org/3/library/ast.html#ast.AST

`ast.dump()` documents the `include_attributes` argument but doesn't mention that `_attributes` is needed (or that `_fields` needs to be set correctly to get child notes dumped):
https://docs.python.org/3/library/ast.html#ast.dump

`ast.dump()` source code shows that the undocumented `_attributes` needs to be set in addition to using `include_attributes=True`:
https://github.com/python/cpython/blob/3.8/Lib/ast.py#L123

----------
messages: 356362
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: `ast.AST._attributes` is used by `ast.dump()` but not documented

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38765>
_______________________________________

From report at bugs.python.org  Mon Nov 11 09:36:05 2019
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Mon, 11 Nov 2019 14:36:05 +0000
Subject: [issue38765] `ast.AST._attributes` is used by `ast.dump()` but not
 documented
In-Reply-To: <1573482663.72.0.733055997415.issue38765@roundup.psfhosted.org>
Message-ID: <1573482965.27.0.660879565002.issue38765@roundup.psfhosted.org>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

Based on the `ast` source code there are also other functions that use  the undocumented `_attributes` attribute:

- copy_location
- fix_missing_locations
- increment_lineno

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38765>
_______________________________________

From report at bugs.python.org  Mon Nov 11 09:38:11 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 11 Nov 2019 14:38:11 +0000
Subject: [issue28533] Replace asyncore
In-Reply-To: <1477420324.44.0.338895938894.issue28533@psf.upfronthosting.co.za>
Message-ID: <1573483091.14.0.132523055411.issue28533@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

@dankreso, the issue is still open and no one has claimed it yet. So feel free to open a pull request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28533>
_______________________________________

From report at bugs.python.org  Mon Nov 11 10:46:43 2019
From: report at bugs.python.org (Jean-Christophe Fillion-Robin)
Date: Mon, 11 Nov 2019 15:46:43 +0000
Subject: [issue38728] Update PC/pyconfig.h to support disabling auto linking
In-Reply-To: <1573080091.42.0.697826916573.issue38728@roundup.psfhosted.org>
Message-ID: <1573487203.98.0.317829329157.issue38728@roundup.psfhosted.org>


Jean-Christophe Fillion-Robin <jchris.fillionr at kitware.com> added the comment:

PY_NO_LINK_LIB will work well. I will work on a patch later this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38728>
_______________________________________

From report at bugs.python.org  Mon Nov 11 11:14:22 2019
From: report at bugs.python.org (mlj)
Date: Mon, 11 Nov 2019 16:14:22 +0000
Subject: [issue38766] AttributeError: 'xml.etree.ElementTree.ParseError' has
 no attribute 'filename'
Message-ID: <1573488862.44.0.586057107298.issue38766@roundup.psfhosted.org>


New submission from mlj <mlittlej at live.co.uk>:

traceback.py and how it handles 'SyntaxError's, which includes a bunch of assumptions about attributes that a SyntaxError should have defined:

https://github.com/python/cpython/blob/master/Lib/traceback.py#L516

Definition of xml.etree.ElementTree.ParseError, marking it out as a sub-class of a SyntaxError:

https://github.com/python/cpython/blob/master/Lib/xml/etree/ElementTree.py#L106

How a ParseError is raised by ElementTree, noting that it doesn't set `filename` (and probably `text` too) as an attribute of the exception isntance:

https://github.com/python/cpython/blob/master/Lib/xml/etree/ElementTree.py#L1625

The most recent commit in the code areas I've highlighted is from `6bc2c1e7ebf359224e5e547f58ffc2c42cb36a39` from March 2015, which added in the assumptions about attributes to `traceback.py`.

The whole thing is markedly confusing, because the code in `traceback.py` isn't being run inside an exception handler, so when it crashes it completly obfuscates the actual root-cause of the issue (in other cases you'd get the "while handling this error, another happened" which is much more user friendly).

I'm not sure what the correct fix here is but I tried making xml.etree.ElementTree.ParseError a standalone exception, not a sub-class of SyntaxError but it didn't take. Probably shouldn't be delving about in the guts of the python-core on my laptop, but ho-hum.

----------
components: XML
messages: 356366
nosy: mlj
priority: normal
severity: normal
status: open
title: AttributeError: 'xml.etree.ElementTree.ParseError' has no attribute 'filename'
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38766>
_______________________________________

From report at bugs.python.org  Mon Nov 11 11:28:31 2019
From: report at bugs.python.org (mlj)
Date: Mon, 11 Nov 2019 16:28:31 +0000
Subject: [issue38766] AttributeError: 'xml.etree.ElementTree.ParseError' has
 no attribute 'filename'
In-Reply-To: <1573488862.44.0.586057107298.issue38766@roundup.psfhosted.org>
Message-ID: <1573489711.7.0.0152781529989.issue38766@roundup.psfhosted.org>


mlj <mlittlej at live.co.uk> added the comment:

Bleh.

Sorry. I've crucially forgottn that this is an issue when running unit-tests under `nose` and isn't exclusively a core problem. Let me do some more debugging and then decide who the correct people to annoy are.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38766>
_______________________________________

From report at bugs.python.org  Mon Nov 11 11:43:17 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 11 Nov 2019 16:43:17 +0000
Subject: [issue37096] Add large-file tests for modules using sendfile(2)
In-Reply-To: <1559200699.13.0.758657145229.issue37096@roundup.psfhosted.org>
Message-ID: <1573490597.5.0.330893416079.issue37096@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Alright added some more disk space at the buildbots, however it seems that it is not related to that. The current Fedora rawhide buildbot has 19GB of free space and the test is still failing.

I tested on the Fedora stable buildbot for which I reduced intentionally the free disk space to 14GB and it passed: https://buildbot.python.org/all/#/builders/233/builds/398

So something else might be at play here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37096>
_______________________________________

From report at bugs.python.org  Mon Nov 11 11:54:14 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 11 Nov 2019 16:54:14 +0000
Subject: [issue28533] Replace asyncore
In-Reply-To: <1477420324.44.0.338895938894.issue28533@psf.upfronthosting.co.za>
Message-ID: <1573491254.32.0.520396854228.issue28533@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I'm happy to work on replacing asyncore usage in one of the other test files.

Sounds good, just let us know which one(s) you're working on. (:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28533>
_______________________________________

From report at bugs.python.org  Mon Nov 11 12:00:47 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 11 Nov 2019 17:00:47 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573491647.13.0.979680222875.issue38764@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I'm not sure listdir and walk should be sorted, for the reasons Raymond mentioned. And I was actually surprised to learn today that pathlib.Path.glob doesn't use the glob module internally. Was there some reasoning behind this decision? Separator handling, perhaps?

Either way, these seem to be out of the scope of this issue... not every change needs to be a repo-wide omnibus! I think incremental improvements like the proposed one are often fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Mon Nov 11 12:08:46 2019
From: report at bugs.python.org (Tilman Roeder)
Date: Mon, 11 Nov 2019 17:08:46 +0000
Subject: [issue38767] Replace Mersenne Twister RNG with a PCG family algorithm
Message-ID: <1573492126.38.0.315773504148.issue38767@roundup.psfhosted.org>


New submission from Tilman Roeder <tilmroe at gmail.com>:

Currently, the `random.random()` function / the random module uses the Mersenne Twister algorithm for generating random numbers.

While this algorithm has acceptable statistical properties for most use-cases (and does feature a ridiculously large period), it is slow and very memory intensive when compared with algorithms from the PCG family (see http://www.pcg-random.org). PCG family algorithms also have much better statistical properties than the Mersenne Twister.

I would propose to replace the underlying generator in `random` with a suitable PCG family algorithm, while not changing any of the external interfaces of the module. I think that the change would make the module faster, better in terms of memory usage, and improve the statistical properties of Python's default random numbers.

I have not done anything in the direction in terms of writing any code, but if this sounds like something that would be sensible, I would be happy to work on the change and submit a PR.

Also, this is the first time I am contributing to Python/ writing an issue here, so apologies if this is not the correct place to make a suggestion like this.

----------
components: Extension Modules
messages: 356371
nosy: dyedgreen, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Replace Mersenne Twister RNG with a PCG family algorithm
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38767>
_______________________________________

From report at bugs.python.org  Mon Nov 11 12:25:55 2019
From: report at bugs.python.org (Manjusaka)
Date: Mon, 11 Nov 2019 17:25:55 +0000
Subject: [issue38768] Support lldb enhancement in MacOS
Message-ID: <1573493155.23.0.630795788847.issue38768@roundup.psfhosted.org>


New submission from Manjusaka <lizheao940510 at gmail.com>:

After MacOS 10.15.x, Apple has changed this system feature that will make more difficult for using GDB in MacOS. 

So is there any chance to support lldb enhancement such as py-list and etc.?

----------
components: macOS
messages: 356372
nosy: Manjusaka, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Support lldb enhancement in MacOS
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38768>
_______________________________________

From report at bugs.python.org  Mon Nov 11 12:44:23 2019
From: report at bugs.python.org (Matthias Schoepfer)
Date: Mon, 11 Nov 2019 17:44:23 +0000
Subject: [issue36852] Python3.7.2 fails to cross-compile (yocto /
 openembedded) when target is mips softfloat
In-Reply-To: <1557331268.61.0.662119534756.issue36852@roundup.psfhosted.org>
Message-ID: <1573494263.4.0.764042485975.issue36852@roundup.psfhosted.org>


Matthias Schoepfer <matthias.schoepfer at googlemail.com> added the comment:

Hi Matthias,

thanks for your comment. I am not sure, if I understand correctly or if it is really the problem here. So, if you take a look at the patch, or at the current version of configure.ac right now, there is s section:

AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])

There is a handcrafted C Program (well, rather C-Preprocessor), which tries to guess, for what Platform the compiler is used for. The initial problem with my platform is this line:

# elif defined(__mips_hard_float)

The reason beeing, on mips soft float, __mips_hard_float is not defined. But the triplet should be mips-linux-gnu. Otherwise, the build will fail later down the road. 

One could add || defined (__mips_soft_float) to fix this issue. Indeed, that was my first patch. But I was not really satisfied. I think, using a custom C program for finding out the target triplet is generally not the right approach, because, you will always miss an architecture or fail to correctly guess the triplet (my guess). I think, it is much better, to rely on autotools for this. At the end of the day, autotools where made for that purpose, right? 
So I replaced the whole program with AC_CANONICAL_TARGET. It should always do the right thing *and* is Cross-Compiler aware. In the end, the triplet is mips-linux-gnu. It also removes lots of hard to maintain code (seems, like nobody really knows its internals?!). 

My trouble is, that I do not know, what other side effects this might have. On the latest release of yocto, my patch is used, and at least, I am not aware of any problems, but that does not mean, that there are none... 

Regards,
   Matthias

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36852>
_______________________________________

From report at bugs.python.org  Mon Nov 11 13:00:07 2019
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 11 Nov 2019 18:00:07 +0000
Subject: [issue36852] Python3.7.2 fails to cross-compile (yocto /
 openembedded) when target is mips softfloat
In-Reply-To: <1557331268.61.0.662119534756.issue36852@roundup.psfhosted.org>
Message-ID: <1573495207.33.0.902480422911.issue36852@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

You misunderstand. The GNU triplets are ambiguous. mips 32bit big endian soft float, and mips 32bit big endian hard float are *not* ABI compatible, but map to the same GNU triplet.

The check *is* cross compiler aware, it's run with the target preprocessor/compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36852>
_______________________________________

From report at bugs.python.org  Mon Nov 11 13:08:50 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Nov 2019 18:08:50 +0000
Subject: [issue38767] Replace Mersenne Twister RNG with a PCG family algorithm
In-Reply-To: <1573492126.38.0.315773504148.issue38767@roundup.psfhosted.org>
Message-ID: <1573495730.49.0.531316070673.issue38767@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See discussion in #30880. That issue was closed, though it's possible that it's time to reconsider.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38767>
_______________________________________

From report at bugs.python.org  Mon Nov 11 13:10:26 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Nov 2019 18:10:26 +0000
Subject: [issue38767] Replace Mersenne Twister RNG with a PCG family algorithm
In-Reply-To: <1573492126.38.0.315773504148.issue38767@roundup.psfhosted.org>
Message-ID: <1573495826.92.0.561199912163.issue38767@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Also worth noting that NumPy 1.17 has now adopted PCG for their default BitGenerator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38767>
_______________________________________

From report at bugs.python.org  Mon Nov 11 13:23:31 2019
From: report at bugs.python.org (Tim Peters)
Date: Mon, 11 Nov 2019 18:23:31 +0000
Subject: [issue38767] Replace Mersenne Twister RNG with a PCG family algorithm
In-Reply-To: <1573492126.38.0.315773504148.issue38767@roundup.psfhosted.org>
Message-ID: <1573496611.59.0.405996940746.issue38767@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Python is a general-purpose language, and as such I believe it's inappropriate for it to be "a leader" in adopting new PRNGs.  That's for area specialists to pioneer.

If NumPy switched, that is a good reason to evaluate this again.  But for backward compatibility we'd probably still need to support the current Twister anyway (for programs that set the seed, we try to keep results bit-for-bit reproducible across releases).

Note that Python didn't switch _to_ the Twister before it was, in effect, a de facto standard across many scientific libraries.

Something not noted in the earlier report:  TOMS rejected the PCG paper, so it will probably never be published.  I don't much care, but those who do care about peer-reviewed publication may see that as a deal killer.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38767>
_______________________________________

From report at bugs.python.org  Mon Nov 11 13:24:24 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 11 Nov 2019 18:24:24 +0000
Subject: [issue36128] ResourceReader for FileLoader inconsistently handles
 path separators
In-Reply-To: <1551215100.55.0.236644911032.issue36128@roundup.psfhosted.org>
Message-ID: <1573496664.72.0.85719324467.issue36128@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

One simple restriction would be to disallow relative paths outside of the resource anchor location.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36128>
_______________________________________

From report at bugs.python.org  Mon Nov 11 13:38:00 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 18:38:00 +0000
Subject: [issue38767] Replace Mersenne Twister RNG with a PCG family algorithm
In-Reply-To: <1573492126.38.0.315773504148.issue38767@roundup.psfhosted.org>
Message-ID: <1573497480.83.0.193875618571.issue38767@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We had looked at this once before and the proposal was rejected (better to stick with the devil you know than than one that hasn't been extensively studied).

Also, there is some value to having a large state space, shuffle() and sample() consume a lot of entropy to assure that a selection from the entire population is possible.

At best, PCG would be an additional algorithm rather than a replacement -- it is already possible to subclass Random and substitute other generators (the docs link to an example for the complementary-multiply-with-carry generator).

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38767>
_______________________________________

From report at bugs.python.org  Mon Nov 11 13:40:42 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Nov 2019 18:40:42 +0000
Subject: [issue38767] Replace Mersenne Twister RNG with a PCG family algorithm
In-Reply-To: <1573492126.38.0.315773504148.issue38767@roundup.psfhosted.org>
Message-ID: <1573497642.97.0.60699719061.issue38767@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

FWIW, here's the NumPy GitHub issue that led to PCG64 being chosen as the default BitGenerator. Warning: the comment thread is long (with many contributions from the PCG author).

https://github.com/numpy/numpy/issues/13635

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38767>
_______________________________________

From report at bugs.python.org  Mon Nov 11 14:06:04 2019
From: report at bugs.python.org (Matthias Schoepfer)
Date: Mon, 11 Nov 2019 19:06:04 +0000
Subject: [issue36852] Python3.7.2 fails to cross-compile (yocto /
 openembedded) when target is mips softfloat
In-Reply-To: <1557331268.61.0.662119534756.issue36852@roundup.psfhosted.org>
Message-ID: <1573499164.19.0.567729090647.issue36852@roundup.psfhosted.org>


Matthias Schoepfer <matthias.schoepfer at googlemail.com> added the comment:

Hi Matthias,

thanks for clarification. Maybe I am under a totally wrong impression, but to me is having soft float comparable to not having some special SSE instruction sets with x86. You are missing some instructions, that your code may or may not need, and the compiler replaces them with some other, not hardware accelerated functions. 

To what extend is the handcrafted version better than the one, autotools are providing? 

I really like to learn here. 

Many thanks already!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36852>
_______________________________________

From report at bugs.python.org  Mon Nov 11 14:40:25 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 11 Nov 2019 19:40:25 +0000
Subject: [issue38769] generators are currently hashable
Message-ID: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

We recently found a bug in one of our codebases that looked ~roughly like this:

class C:
    ...

    def __hash__(self):
        return hash((v for k, v in sorted(self.__dict__.items())))

which resulted in a production bug

The *intention* was to hash a tuple of those elements but the author had forgotten the `tuple(...)` call (or incorrectly assumed a parenthesized generator was a tuple comprehension) -- either way it seems wrong that generators are currently hashable as they are mutable

Thoughts on `__hash__ = None` for generators?

----------
components: Interpreter Core
messages: 356382
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: generators are currently hashable
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 14:44:22 2019
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 11 Nov 2019 19:44:22 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573501462.67.0.190637055693.issue38769@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 15:21:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 20:21:39 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573503699.46.0.275809861506.issue38769@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> the author had forgotten the `tuple(...)` call (or incorrectly 
> assumed a parenthesized generator was a tuple comprehension)

Presumably that will bite the author in many ways, not just hashability.  There are many other places where substituting a generator for a tuple would result in a downstream error.  ISTM, this user error would have been caught with even minimal testing or code review.


> it seems wrong that generators are currently hashable as they are mutable

It is perfectly reasonable given that generators compare based on object identity.


> Thoughts on `__hash__ = None` for generators?

That would break currently working code that depends on hashability.  I have seen such code in production more than once (using distinct generator instances as dictionary keys for example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 15:27:19 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 20:27:19 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573504039.61.0.478387055057.issue38764@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> This seems like an inappropriately elitist attitude.

Please drop the personal attacks and abusive tone.  The tracker is for technical discussions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Mon Nov 11 15:43:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 20:43:51 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573505031.88.0.582116997031.issue38764@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

ISTM that if glob had been sorted, it would have only thinly masked the data pipeline issues that were encountered.  The code would still have been easily broken by someone renaming, adding, or removing a file.  In their case, it was the semantic context of the files where the application order was important, the actual filenames were incidental to the bug.

Also having user depend on sorting may lead to other bugs as well.  1) Sorts in one version of Python but not another, 2) Sorts in some functions but not others, and 3) The sort is text based so that file1, file2, ..., file11, file12 don't sort as expected.

FWIW, I didn't put a strong -1.  However, the "sorting of discovered children" is a warning sign that we're doing too much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Mon Nov 11 15:47:58 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 20:47:58 +0000
Subject: [issue38438] argparse "usage" overly-complex with nargs="*"
In-Reply-To: <1570739079.02.0.395133592841.issue38438@roundup.psfhosted.org>
Message-ID: <1573505277.97.0.906144280475.issue38438@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset a0ed99bca8475cbc82e9202aa354faba2a4620f4 by Raymond Hettinger (Brandt Bucher) in branch 'master':
bpo-38438: Simplify argparse "star nargs" usage. (GH-17106)
https://github.com/python/cpython/commit/a0ed99bca8475cbc82e9202aa354faba2a4620f4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38438>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:06:37 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 11 Nov 2019 21:06:37 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573506397.3.0.833620783951.issue38769@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

:shrugs: it did go through a round of code review but was simply missed -- the testing bit is fair

there are other such mutable objects in python which do define __hash__ = None such as list and dict

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:10:17 2019
From: report at bugs.python.org (Saim Raza)
Date: Mon, 11 Nov 2019 21:10:17 +0000
Subject: [issue38770] Pickle handle self references in classes
Message-ID: <1573506617.89.0.382822936013.issue38770@roundup.psfhosted.org>


New submission from Saim Raza <saimorsaim at gmail.com>:

If the __qualname__ of a class is set to have a circular reference to itself, pickle behaves differently based on protocol. Following script demonstrates the issue:

======================================================
from __future__ import print_function

import pickle, sys

class Foo:
    __name__ = __qualname__ = "Foo.ref"
    pass

Foo.ref = Foo

print(sys.version_info)

for proto in range(0, pickle.HIGHEST_PROTOCOL + 1):
    print("{}:".format(proto), end=" ")
    try:
        pkl = pickle.dumps(Foo, proto)
        print("Dump OK,", end=" ")
        assert(pickle.loads(pkl) is Foo)
        print("Load OK,")
    except Exception as err:
        print(repr(err))
======================================================
OUTPUT:
Python2.7:
sys.version_info(major=2, minor=7, micro=16, releaselevel='final', serial=0)
0: Dump OK, Load OK,
1: Dump OK, Load OK,
2: Dump OK, Load OK,

Python3.7:
sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0)
0: RecursionError('maximum recursion depth exceeded while pickling an object')
1: RecursionError('maximum recursion depth exceeded while pickling an object')
2: RecursionError('maximum recursion depth exceeded while pickling an object')
3: RecursionError('maximum recursion depth exceeded while pickling an object')
4: Dump OK, Load OK,
======================================================

This was introduced as a side effect of issue#23611 (?). I can think of the following approaches to fix the issue and make the behavior consistent:

1. Check if the class has a self-reference and raise an error for all protocols.
2. Use memoization to handle self-references. I am not sure what should be dumped in this case. In the example above `Foo` will exist in the namespace but not `Foo.ref`. 
3. Dump such classes similar to Python 2 pickle and Python 3 pickle protocol >= 4.

I had a stab at pickle.py and had a bit of success in doing point 3 above. Posting this issue for discussions. I would be happy to submit a PR for this issue.

Thanks,
Saim Raza

----------
components: Library (Lib)
messages: 356388
nosy: Saim Raza, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Pickle handle self references in classes
type: behavior
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38770>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:21:22 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Nov 2019 21:21:22 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573507282.73.0.595656044033.issue38769@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> there are other such mutable objects in python which do define
> __hash__ = None such as list and dict

Those objects compare on their contents, not on object identity.

Take a look at how hashing works in dataclasses.  You can have a mix of mutable and immutable fields as long as both __eq__ and __hash__ depend on only the immutable fields.

Also, take a look at database cursor objects.  Both __eq__ and __hash__ use object identity even though fetchone() advances the internal state (just like an iterator).

Anyway, the breaking of existing working code makes this a non-starter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:33:08 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 11 Nov 2019 21:33:08 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1573507988.3.0.321653460694.issue37838@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords:  -patch
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:33:41 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 11 Nov 2019 21:33:41 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1573508021.71.0.917145858675.issue37838@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
pull_requests:  -16560

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:34:16 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 11 Nov 2019 21:34:16 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1573508056.26.0.0159056895814.issue37838@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

The PR was linked by mistake (it is for a different issue), so I unlinked it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:36:07 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Nov 2019 21:36:07 +0000
Subject: [issue38770] Pickle handle self references in classes
In-Reply-To: <1573506617.89.0.382822936013.issue38770@roundup.psfhosted.org>
Message-ID: <1573508167.13.0.685817666615.issue38770@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38770>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:48:13 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 11 Nov 2019 21:48:13 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573508893.64.0.190907102919.issue38764@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I could also add: would sorting be case-sensitive or case-insensitive? Windows is case-insensitive, Linux is case-sensitive.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Mon Nov 11 16:50:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Nov 2019 21:50:53 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573509053.7.0.479475557821.issue38769@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I agree with Raymond. By default all objects are compared by identity and are hashable. User classes are hashable, files are hashable, iterators are hashable. Generator objects are just not special enough to be non-hashable.

We can reconsider this. But it a part of much larger Python language change. It should be discussed on Python-Dev. We should estimate the benefit and the amount of possible breakage. I think there is a chance of changing this, but we need more information.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:02:49 2019
From: report at bugs.python.org (Tim Peters)
Date: Mon, 11 Nov 2019 22:02:49 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573509769.39.0.533472289187.issue38769@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Function objects can be used as dict keys too.  Given that, it would be _very_ surprising if generator-iterators weren't.  I don't really see a good point to leaving this open.  Live with it - it's a feature ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:14:19 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 11 Nov 2019 22:14:19 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573510459.16.0.844535910547.issue38769@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

function objects are immutable though

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:18:30 2019
From: report at bugs.python.org (Tim Peters)
Date: Mon, 11 Nov 2019 22:18:30 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573510710.4.0.939398415741.issue38769@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

What makes you think generator-iterator objects are mutable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:24:46 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 11 Nov 2019 22:24:46 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573511086.91.0.231655367077.issue38769@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I think I'm missing what you're saying, apologies I'm probably confused :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:35:33 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 11 Nov 2019 22:35:33 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573511733.77.0.0839847130688.issue38769@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Anthony, can you please explain what you mean when you describe generators as "mutable"? I don't understand what you mean.

To *me*, the value of a generator, in so far as comparisons goes, is its identity, not its invisible internal state. You can test that by noting that two generators with the same state compare unequal:

    py> def gen():
    ...     yield 1
    ...
    py> a = gen()
    py> b = gen()
    py> a == b
    False

Furthermore, the hash of the generator doesn't change when its internal state changes.

    py> hash(a)
    192456114
    py> next(a)
    1
    py> hash(a)
    192456114


And as for functions being "immutable", you can attach arbitrary attributes to them, so their object state can change. Does that make them mutable? Either way, it doesn't matter, since functions are also compared by identity. Their value is their identity, not their state. (Two functions with the same internal state are compared as unequal.)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:39:04 2019
From: report at bugs.python.org (Jonathan Scholbach)
Date: Mon, 11 Nov 2019 22:39:04 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
Message-ID: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>


New submission from Jonathan Scholbach <j.scholbach at posteo.de>:

Below "Examples and Recipes", the Documentation of collections.ChainMap has an "Example of letting user specified command-line arguments take precedence over environment variables which in turn take precedence over default values:" In there, a ChainMap is created which represents the default values, updated by the command-line arguments, if they have been set. The relevant code snippet is the following:
   
    parser = argparse.ArgumentParser()
    parser.add_argument('-u', '--user')
    parser.add_argument('-c', '--color')
    namespace = parser.parse_args()
    command_line_args = {k:v for k, v in vars(namespace).items() if v}

If user passes an empty string as value for any of the command-line arguments, that argument would not appear in `command_line_args` (because the boolean value of empty string is `False`). However, passing the empty string as a value for a command-line argument, would reflect the intent of overwriting the default value (setting it to the empty string). With the current example code, this would erroneously not be reflected in the `command_line_args`. This is caused by checking for the boolean of `v` instead of checking for `v` not being `None`. So, this should be handled correctly by writing

    command_line_args = {k: v for k, v in vars(namespace).items() if v is not None}

----------
assignee: docs at python
components: Documentation
messages: 356398
nosy: docs at python, jonathan.scholbach
priority: normal
severity: normal
status: open
title: Bug in example of collections.ChainMap
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:42:58 2019
From: report at bugs.python.org (Jonathan Scholbach)
Date: Mon, 11 Nov 2019 22:42:58 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573512178.95.0.891443645454.issue38771@roundup.psfhosted.org>


Change by Jonathan Scholbach <j.scholbach at posteo.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:46:12 2019
From: report at bugs.python.org (Tim Peters)
Date: Mon, 11 Nov 2019 22:46:12 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573512372.56.0.170977314888.issue38769@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Yes, what Steven said.  All kinds of functions (including, but not limited to, generator-iterators) are compared by object identity, nothing at all about internal state.  The contract of hash() is that if a == b, then we must have that hash(a) == hash(b) too.  That's got nothing to do with internal state either, _only_ with how __eq__ is implemented.

There is no sense in which any kind of function object is "mutable" that has any effect on its object identity, so also no sense in which it can affect __eq__ results, so no reason at all for __hash__ to care.  It's all working as designed and as intended.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:47:47 2019
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 11 Nov 2019 22:47:47 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573512467.36.0.640204367165.issue38769@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

An easier way to understand might be to just write out the generator expression "manually":

  def generator_expression():
    for k, v in sorted(self.__dict__.items()):
      yield k
  return hash(my_generator_expression())

Would you say that `generator_expression` here is mutable or immutable? The code that underpins how it generates values is clearly immutable just like functions but the values it closes over can be changed.

Another minimal example:

>>> def f():
...   yield from some_list
...
>>> some_list = [1,2,3]
>>> list(f())
[1, 2, 3]
>>> some_list = [1,2,3,4,5]
>>> list(f())
[1, 2, 3, 4, 5]

Would you say that `f` is immutable or mutable in this case?

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 17:58:17 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 11 Nov 2019 22:58:17 +0000
Subject: [issue38769] generators are currently hashable
In-Reply-To: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>
Message-ID: <1573513097.55.0.50995135133.issue38769@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I can see that making generators unhashable would have found your bug earlier, but it is otherwise unjustified: generators are just objects that are compared by identity. It would break other people's code, which is a very invasive change to make just so that a small subset of "forgot to call tuple" bugs might sometimes be found earlier.

Personally, I think that Serhiy's comment that there is "a chance" that this will be accepted is over-optimistic, but either way this would need to have a PEP.

I'm going to close this as "Not a bug" but that doesn't mean discussion has to stop. If you feel strongly enough about this issue to write a PEP proposing this change, please take the discussion to the Python-Dev mailing list with a summary and see if you can get somebody to sponsor the PEP. If you do, feel free to re-open as an Enhancement.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38769>
_______________________________________

From report at bugs.python.org  Mon Nov 11 18:22:48 2019
From: report at bugs.python.org (Travis Lazar)
Date: Mon, 11 Nov 2019 23:22:48 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
In-Reply-To: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>
Message-ID: <1573514568.26.0.607981866867.issue38739@roundup.psfhosted.org>


Travis Lazar <travis.lazar at gmail.com> added the comment:

FYI: this affects tornado_http and django_template as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:00:16 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 00:00:16 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573516816.55.0.17085852493.issue38771@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:08:50 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Archer?=)
Date: Tue, 12 Nov 2019 00:08:50 +0000
Subject: [issue38772] shutil.copytree fail to copy some bytes
Message-ID: <1573517330.77.0.396990745191.issue38772@roundup.psfhosted.org>


New submission from St?phane Archer <archerstephane at gmail.com>:

I use shutil.copytree to copy photos from many sd cards to a hard drive.
I use thread for each sd card. then I check if the content has been copying correctly with filecmp.cmpfiles with shallow to false. and surprise!!!
some files are not identical. usually, just one byte has not been properly copying

----------
components: IO
files: diff.png
messages: 356403
nosy: St?phane Archer
priority: normal
severity: normal
status: open
title: shutil.copytree fail to copy some bytes
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48707/diff.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38772>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:13:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 00:13:03 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573517583.24.0.650285616276.issue38771@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The example was just meant to be a quick snippet to suggest a possible use case.  It isn't a stand-alone application.  However, stylistically, this is an improvement and I'll accept some variation of the PR.

----------
priority: normal -> low
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:49:59 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 00:49:59 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573519799.01.0.946872587199.issue38771@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 98480cef9dba04794bd61c7e7cca643d384c8c35 by Raymond Hettinger (Jonathan Scholbach) in branch 'master':
bpo-38771:  Explict test for None in code example (GH-17108)
https://github.com/python/cpython/commit/98480cef9dba04794bd61c7e7cca643d384c8c35


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:50:08 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 00:50:08 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573519808.24.0.986783635222.issue38771@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16616
pull_request: https://github.com/python/cpython/pull/17109

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:50:15 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 00:50:15 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573519814.99.0.669314205664.issue38771@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16617
pull_request: https://github.com/python/cpython/pull/17110

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:52:29 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 00:52:29 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573519949.7.0.144746248477.issue38771@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:58:55 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 00:58:55 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573520335.42.0.523617143229.issue38771@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset cb1c06e3bfbce7f4e8dcb0db84bcee54c8d4fa21 by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-38771:  Explict test for None in code example (GH-17108) (GH-17110)
https://github.com/python/cpython/commit/cb1c06e3bfbce7f4e8dcb0db84bcee54c8d4fa21


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:59:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 00:59:17 +0000
Subject: [issue38771] Bug in example of collections.ChainMap
In-Reply-To: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>
Message-ID: <1573520357.23.0.70931611303.issue38771@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset d8e08456025d9349abbf76035c821d3f7b2d722a by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-38771:  Explict test for None in code example (GH-17108) (GH-17109)
https://github.com/python/cpython/commit/d8e08456025d9349abbf76035c821d3f7b2d722a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 21:56:49 2019
From: report at bugs.python.org (Clem Flory)
Date: Tue, 12 Nov 2019 02:56:49 +0000
Subject: [issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 >
 alledged missing X509_VERIFY_PARAM_set1_host() support
In-Reply-To: <1530609211.5.0.56676864532.issue34028@psf.upfronthosting.co.za>
Message-ID: <1573527409.89.0.713835935631.issue34028@roundup.psfhosted.org>


Change by Clem Flory <cjflory at gmail.com>:


----------
nosy: +cjflory

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34028>
_______________________________________

From report at bugs.python.org  Mon Nov 11 22:12:45 2019
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 12 Nov 2019 03:12:45 +0000
Subject: [issue36128] ResourceReader for FileLoader inconsistently handles
 path separators
In-Reply-To: <1551215100.55.0.236644911032.issue36128@roundup.psfhosted.org>
Message-ID: <1573528365.91.0.957855224719.issue36128@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

I think disallowing relative paths that are parents of the current anchor point is a reasonable restriction and acceptable backwards incompatible behavior.

Disallowing all relative paths with slashes is a larger issue. I would support that if designing/implementing things today as it simplifies things greatly. But since an implementation allowing slashes has shipped in 3.7 and 3.8, I'm not sure if the backwards incompatibility could be stomached, so I'm not going to advocate for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36128>
_______________________________________

From report at bugs.python.org  Mon Nov 11 22:18:08 2019
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 12 Nov 2019 03:18:08 +0000
Subject: [issue36128] ResourceReader for FileLoader inconsistently handles
 path separators
In-Reply-To: <1551215100.55.0.236644911032.issue36128@roundup.psfhosted.org>
Message-ID: <1573528688.97.0.166483855942.issue36128@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

I just noticed that there is a parallel discussion ongoing in https://gitlab.com/python-devs/importlib_resources/issues/58.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36128>
_______________________________________

From report at bugs.python.org  Mon Nov 11 23:19:07 2019
From: report at bugs.python.org (Rohit)
Date: Tue, 12 Nov 2019 04:19:07 +0000
Subject: [issue38773] Fatal Python error: Aborted
Message-ID: <1573532347.12.0.111468520107.issue38773@roundup.psfhosted.org>


New submission from Rohit <rohitlal.125555 at gmail.com>:

Python is crashing frequently. The frequency lies anywhere in between 10 hours to 24 hours of running the program.

Packages used in my program:
numba.cuda, numpy, sklearn.cluster, cv2, falcon, multiprocessing, faulthandler 

Priority: High

----------
components: Interpreter Core
files: python_error.txt
messages: 356410
nosy: rohitlal.125555 at gmail.com
priority: normal
severity: normal
status: open
title: Fatal Python error: Aborted
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file48708/python_error.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38773>
_______________________________________

From report at bugs.python.org  Tue Nov 12 00:09:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 05:09:42 +0000
Subject: [issue38438] argparse "usage" overly-complex with nargs="*"
In-Reply-To: <1570739079.02.0.395133592841.issue38438@roundup.psfhosted.org>
Message-ID: <1573535382.18.0.0900394433349.issue38438@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Bob, thanks for the suggestion.

Brandt, thanks for the PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38438>
_______________________________________

From report at bugs.python.org  Tue Nov 12 00:36:29 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 05:36:29 +0000
Subject: [issue38385] statistics: incorrect documentation
In-Reply-To: <1570389016.13.0.165369947537.issue38385@roundup.psfhosted.org>
Message-ID: <1573536989.47.0.870317074194.issue38385@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38385>
_______________________________________

From report at bugs.python.org  Tue Nov 12 00:37:25 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 05:37:25 +0000
Subject: [issue37759] Polish whatsnew for 3.8
In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org>
Message-ID: <1573537045.91.0.845494743697.issue37759@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37759>
_______________________________________

From report at bugs.python.org  Tue Nov 12 00:44:31 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 05:44:31 +0000
Subject: [issue9399] Provide a 'print' action for argparse
In-Reply-To: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>
Message-ID: <1573537471.34.0.378996804439.issue9399@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Marking this as closed because there has been no activity or interest for over five years.

If anyone wants to revive this and write a PR, feel free to reopen.  The core idea is plausible, but this doesn't seem to be a recurring need.

----------
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9399>
_______________________________________

From report at bugs.python.org  Tue Nov 12 00:45:38 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 05:45:38 +0000
Subject: [issue27805] io.open('/dev/stdout',
 'a') raises OSError with errno=ESPIPE
In-Reply-To: <1471637472.92.0.246311076418.issue27805@psf.upfronthosting.co.za>
Message-ID: <1573537538.07.0.213810403163.issue27805@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +16619
pull_request: https://github.com/python/cpython/pull/17112

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27805>
_______________________________________

From report at bugs.python.org  Tue Nov 12 01:03:27 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Nov 2019 06:03:27 +0000
Subject: [issue17642] IDLE add font resizing hot keys and wheel
In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za>
Message-ID: <1573538607.56.0.513640108012.issue17642@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#33397 add a FontSizer class to textview.py and uses it there and for the doc viewer in help.py.  It should be used for this issue also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17642>
_______________________________________

From report at bugs.python.org  Tue Nov 12 01:27:34 2019
From: report at bugs.python.org (Tal Einat)
Date: Tue, 12 Nov 2019 06:27:34 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1573540054.84.0.866139176631.issue37903@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

> Can you also show a script running with F5 showing a restart, the output from the script and a subsequent interactive session that shows the inspecting variables.  Also show what an exception and SyntaxError looks like.

I've attached a screenshot showing everything that Raymond asked for.

----------
Added file: https://bugs.python.org/file48709/screenshot2.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Tue Nov 12 01:36:31 2019
From: report at bugs.python.org (Tal Einat)
Date: Tue, 12 Nov 2019 06:36:31 +0000
Subject: [issue37903] IDLE Shell sidebar.
In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org>
Message-ID: <1573540591.34.0.3263686099.issue37903@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Raymond, FWIW, this will fix at least one of the issues you've mentioned: "Cntl-A on macOS jumps before the >>> prompt".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37903>
_______________________________________

From report at bugs.python.org  Tue Nov 12 01:42:58 2019
From: report at bugs.python.org (Tal Einat)
Date: Tue, 12 Nov 2019 06:42:58 +0000
Subject: [issue38440] Possible new issues with IDLE
In-Reply-To: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>
Message-ID: <1573540978.1.0.136787720385.issue38440@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

> * The pop-up message box for interrupting currently running code will appear several times in succession.  Dismissing the box doesn't clear a queue of events, so the message may occur several times in a row.

I've been unable to reproduce this on Windows. Raymond, is this specific to macOS?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38440>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:05:52 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Nov 2019 07:05:52 +0000
Subject: [issue38754] Python3.7 site-packages
In-Reply-To: <1573296359.45.0.502022034855.issue38754@roundup.psfhosted.org>
Message-ID: <1573542352.45.0.337616744114.issue38754@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Sorry you are having problems. Unfortunately, those messages are not coming from Python itself so there doesn't appear to be anything we can do here.  Searching on the web for "could not get file information for" suggests that the messages are coming from Arch's package manager, pacman.  Suggest you ask on a Arch-related forum or perhaps on something like StackOverflow.  Good luck!

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38754>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:30:26 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 07:30:26 +0000
Subject: [issue38565] Expose the value passed of typed passed to
 functools.lru_cache
In-Reply-To: <1571842254.4.0.33528560442.issue38565@roundup.psfhosted.org>
Message-ID: <1573543826.27.0.985251323039.issue38565@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 051ff526b5dc2c40c4a53d87089740358822edfa by Raymond Hettinger (Manjusaka) in branch 'master':
bpo-38565: add new cache_parameters method for lru_cache (GH-16916)
https://github.com/python/cpython/commit/051ff526b5dc2c40c4a53d87089740358822edfa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38565>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:32:24 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 07:32:24 +0000
Subject: [issue38565] Expose the value passed of typed passed to
 functools.lru_cache
In-Reply-To: <1571842254.4.0.33528560442.issue38565@roundup.psfhosted.org>
Message-ID: <1573543944.96.0.464440142271.issue38565@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Scott, thank you for the suggestion.
Serhiy, thank for pointing to the simplest implementation.
Zheaoli, thanks for the patch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38565>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:34:21 2019
From: report at bugs.python.org (Manjusaka)
Date: Tue, 12 Nov 2019 07:34:21 +0000
Subject: [issue38565] Expose the value passed of typed passed to
 functools.lru_cache
In-Reply-To: <1571842254.4.0.33528560442.issue38565@roundup.psfhosted.org>
Message-ID: <1573544061.16.0.362031239465.issue38565@roundup.psfhosted.org>


Manjusaka <lizheao940510 at gmail.com> added the comment:

Raymond, thanks for fixing many errors for my patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38565>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:35:09 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 07:35:09 +0000
Subject: [issue38385] statistics: incorrect documentation
In-Reply-To: <1570389016.13.0.165369947537.issue38385@roundup.psfhosted.org>
Message-ID: <1573544109.49.0.495874093004.issue38385@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 733b9a308e3c49855888e2e12397ae56d831e780 by Raymond Hettinger in branch 'master':
bpo-38385: Fix iterator/iterable terminology in statistics docs (GH-17111)
https://github.com/python/cpython/commit/733b9a308e3c49855888e2e12397ae56d831e780


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38385>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:35:20 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 07:35:20 +0000
Subject: [issue38385] statistics: incorrect documentation
In-Reply-To: <1570389016.13.0.165369947537.issue38385@roundup.psfhosted.org>
Message-ID: <1573544120.49.0.66181132298.issue38385@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16620
pull_request: https://github.com/python/cpython/pull/17113

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38385>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:36:28 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 07:36:28 +0000
Subject: [issue38385] statistics: incorrect documentation
In-Reply-To: <1570389016.13.0.165369947537.issue38385@roundup.psfhosted.org>
Message-ID: <1573544188.26.0.337110758901.issue38385@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38385>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:40:00 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 07:40:00 +0000
Subject: [issue17306] Improve the way abstract base classes are shown in help()
In-Reply-To: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za>
Message-ID: <1573544400.78.0.511214208513.issue17306@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Benjamin, are you still interested in working on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17306>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:45:33 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Nov 2019 07:45:33 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573544733.94.0.273261862898.issue26353@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Zachary determined that the issue is that writing calls iomenu.IOBinding.fixlastline, which unconditionally adds \n at the end if there is one.  That is not needed for the Shell and wrong when it ends with a prompt, which is the normal case.

----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:47:50 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 12 Nov 2019 07:47:50 +0000
Subject: [issue38328] Speed up the creation time of constant list literals.
In-Reply-To: <1569862645.36.0.924344090693.issue38328@roundup.psfhosted.org>
Message-ID: <1573544870.82.0.550483207997.issue38328@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16621
pull_request: https://github.com/python/cpython/pull/17114

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38328>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:50:18 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 12 Nov 2019 07:50:18 +0000
Subject: [issue38328] Speed up the creation time of constant list literals.
In-Reply-To: <1569862645.36.0.924344090693.issue38328@roundup.psfhosted.org>
Message-ID: <1573545018.08.0.401266253826.issue38328@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I have created a new patch (PR 17114) that performs this optimization directly in the compiler, rather than the peephole optimizer. I think I like the new one better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38328>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:53:14 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Nov 2019 07:53:14 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1573545194.71.0.239879716301.issue37309@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +16622
pull_request: https://github.com/python/cpython/pull/17115

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Tue Nov 12 02:54:31 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 12 Nov 2019 07:54:31 +0000
Subject: [issue38328] Speed up the creation time of constant list and set
 literals.
In-Reply-To: <1569862645.36.0.924344090693.issue38328@roundup.psfhosted.org>
Message-ID: <1573545271.28.0.758998643968.issue38328@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
title: Speed up the creation time of constant list literals. -> Speed up the creation time of constant list and set literals.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38328>
_______________________________________

From report at bugs.python.org  Tue Nov 12 03:04:20 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Nov 2019 08:04:20 +0000
Subject: [issue38385] statistics: incorrect documentation
In-Reply-To: <1570389016.13.0.165369947537.issue38385@roundup.psfhosted.org>
Message-ID: <1573545860.15.0.00839095889263.issue38385@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 3562439eb293c5fe90b1f1fe507d57d2f4fcd044 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-38385: Fix iterator/iterable terminology in statistics docs (GH-17111) (GH-17113)
https://github.com/python/cpython/commit/3562439eb293c5fe90b1f1fe507d57d2f4fcd044


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38385>
_______________________________________

From report at bugs.python.org  Tue Nov 12 04:18:56 2019
From: report at bugs.python.org (Jackson Riley)
Date: Tue, 12 Nov 2019 09:18:56 +0000
Subject: [issue36092] unittest.mock's patch.object and patch.dict are not
 supported on classmethod, propery and staticmethod
In-Reply-To: <1550904704.81.0.829273897144.issue36092@roundup.psfhosted.org>
Message-ID: <1573550336.11.0.871178782494.issue36092@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Hi Karthikeyan,

It seems that test_patch_descriptor has been removed by Chris Withers on 1st of May 2019 under commit adbf178.

I would therefore propose that this bug be marked as closed/resolved.

Cheers,
Jackson

----------
nosy: +jacksonriley

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36092>
_______________________________________

From report at bugs.python.org  Tue Nov 12 04:23:36 2019
From: report at bugs.python.org (Jackson Riley)
Date: Tue, 12 Nov 2019 09:23:36 +0000
Subject: [issue17306] Improve the way abstract base classes are shown in help()
In-Reply-To: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za>
Message-ID: <1573550616.93.0.0239886400555.issue17306@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Hi Raymond,

I'm working with Ben on the EnHackathon project (https://enhackathon.github.io/) and am planning on working on this issue. Is that alright? Please do say if there's anything extra wanted or if you have any guidance (this is my first time contributing to python).

----------
nosy: +jacksonriley

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17306>
_______________________________________

From report at bugs.python.org  Tue Nov 12 04:29:04 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 12 Nov 2019 09:29:04 +0000
Subject: [issue38773] Fatal Python error: Aborted
In-Reply-To: <1573532347.12.0.111468520107.issue38773@roundup.psfhosted.org>
Message-ID: <1573550944.89.0.597338746079.issue38773@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm pretty sure you should be reporting this to Anaconda. Its a crash involving a third-party distribution of Python and third-party applications like numba and cython.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38773>
_______________________________________

From report at bugs.python.org  Tue Nov 12 04:48:10 2019
From: report at bugs.python.org (=?utf-8?q?Torbj=C3=B8rn_Wikestad?=)
Date: Tue, 12 Nov 2019 09:48:10 +0000
Subject: [issue38774] Statements in try block still executes after raised error
Message-ID: <1573552090.89.0.826307199314.issue38774@roundup.psfhosted.org>


New submission from Torbj?rn Wikestad <torbjorn.wikestad at gmail.com>:

In a script that runs in a IPython 3.6 console (Spyder IDE, part of a WinPython bundle), a counter increment statement is executed after a function call which raises an ValueError exception in try ... except structure. This does not seem to be the correct interpreter behavior, from the resources that I found, as the expected behaviour is said for execution to jump directly to the except block.

----------
assignee: docs at python
components: Documentation, Interpreter Core, Windows
messages: 356429
nosy: Torbj?rn Wikestad, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Statements in try block still executes after raised error
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38774>
_______________________________________

From report at bugs.python.org  Tue Nov 12 04:49:13 2019
From: report at bugs.python.org (Kafeel Ansari)
Date: Tue, 12 Nov 2019 09:49:13 +0000
Subject: [issue38775] Cloudpickle.py file is crashing due to data type
 incompatibility.
Message-ID: <1573552153.69.0.800822929594.issue38775@roundup.psfhosted.org>


New submission from Kafeel Ansari <kafeelansari24 at gmail.com>:

I tried python3.8 for my project. But it is crashing in the beginning . When debugged , found out that "Line 145 in cloudpickle.py" is returning the value in bytes which is not expected.

Code Snippet: 
 
 _cell_set_template_code = _make_cell_set_template_code()

Error: 

return types.CodeType(
TypeError: an integer is required (got type bytes)

----------
components: Windows
messages: 356430
nosy: kafeel.ansari, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cloudpickle.py file is crashing due to data type incompatibility.
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38775>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:00:07 2019
From: report at bugs.python.org (toywei)
Date: Tue, 12 Nov 2019 10:00:07 +0000
Subject: [issue38776] rlock_count<0
Message-ID: <1573552807.68.0.797994213494.issue38776@roundup.psfhosted.org>


New submission from toywei <g1e2t3 at foxmail.com>:

Modules\_threadmodule.c
    if (self->rlock_count == 0 || self->rlock_owner != tid) {
==>
    if (self->rlock_count <= 0 || self->rlock_owner != tid) {

----------
components: Build
messages: 356431
nosy: toywei
priority: normal
severity: normal
status: open
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38776>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:02:58 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Nov 2019 10:02:58 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1573552978.08.0.0659583308421.issue37309@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 8341a4d918ca96f8a5523444e056ffa82fa039d5 by Terry Jan Reedy in branch '3.8':
[3.8] bpo-37309: idlelib/NEWS.txt - add missing period. (#17115)
https://github.com/python/cpython/commit/8341a4d918ca96f8a5523444e056ffa82fa039d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:03:08 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 10:03:08 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1573552988.47.0.248917401667.issue37309@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16623
pull_request: https://github.com/python/cpython/pull/17117

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:06:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 10:06:18 +0000
Subject: [issue38776] rlock_count<0
In-Reply-To: <1573552807.68.0.797994213494.issue38776@roundup.psfhosted.org>
Message-ID: <1573553178.74.0.611653812266.issue38776@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Hello. Please elaborate your bug report. What is your problem? What are you trying to do? What is the current behavior?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38776>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:21:09 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 10:21:09 +0000
Subject: [issue37309] idlelib/NEWS.txt for 3.9.0 and backports
In-Reply-To: <1560723721.58.0.865881864361.issue37309@roundup.psfhosted.org>
Message-ID: <1573554069.67.0.316364560375.issue37309@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 832341a07158955c2df899c18779b72fb379b0d0 by Miss Islington (bot) in branch '3.7':
[3.8] bpo-37309: idlelib/NEWS.txt - add missing period. (GH-17115)
https://github.com/python/cpython/commit/832341a07158955c2df899c18779b72fb379b0d0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37309>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:33:07 2019
From: report at bugs.python.org (Jackson Riley)
Date: Tue, 12 Nov 2019 10:33:07 +0000
Subject: [issue23692] Undocumented feature prevents re module from finding
 certain matches
In-Reply-To: <1426618184.57.0.811463464384.issue23692@psf.upfronthosting.co.za>
Message-ID: <1573554787.41.0.219531025951.issue23692@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Hi Matthew, Serhiy,

I tried to identify the right places in re to fix things but have found it a bit difficult.
I wrote up my attempt (at https://enhackathon.github.io/2019/11/04/JacksonRiley.html) which includes some examples that behave differently from how I would have expected this bug to manifest itself. 
Any further guidance would be greatly appreciated!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23692>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:54:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Nov 2019 10:54:13 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573556053.79.0.932201599371.issue26353@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset c8b53dc3d8f721ed8519aa5a35530a42fbfb9424 by Terry Jan Reedy (Zackery Spytz) in branch 'master':
bpo-26353: IDLE adds an unneeded newline when saving a shell window (GH-17103)
https://github.com/python/cpython/commit/c8b53dc3d8f721ed8519aa5a35530a42fbfb9424


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:54:25 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 10:54:25 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573556065.09.0.831430705156.issue26353@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16624
pull_request: https://github.com/python/cpython/pull/17118

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Tue Nov 12 05:54:32 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 10:54:32 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573556072.19.0.175889090152.issue26353@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16625
pull_request: https://github.com/python/cpython/pull/17119

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:00:17 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 11:00:17 +0000
Subject: [issue38775] Cloudpickle.py file is crashing due to data type
 incompatibility.
In-Reply-To: <1573552153.69.0.800822929594.issue38775@roundup.psfhosted.org>
Message-ID: <1573556417.2.0.971688272836.issue38775@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is this on Python 3.8.0 ? There was a similar report in the past with cloudpickle at https://bugs.python.org/issue36886#msg342182 due to PEP 570 with which CodeType.replace was introduced. cloudpickle also added support for this with https://github.com/cloudpipe/cloudpickle/pull/269 and has Python 3.8 in their CI matrix. Can you please add the version of cloudpickle and python version with which this error is caused? I guess it's more of an issue to be fixed with cloudpickle.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38775>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:01:32 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 11:01:32 +0000
Subject: [issue38774] Statements in try block still executes after raised error
In-Reply-To: <1573552090.89.0.826307199314.issue38774@roundup.psfhosted.org>
Message-ID: <1573556492.3.0.605337684517.issue38774@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please add the script without any dependencies to reproduce this?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38774>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:07:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 11:07:20 +0000
Subject: [issue36092] unittest.mock's patch.object and patch.dict are not
 supported on classmethod, propery and staticmethod
In-Reply-To: <1550904704.81.0.829273897144.issue36092@roundup.psfhosted.org>
Message-ID: <1573556840.53.0.877136002597.issue36092@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Jackson for the information. I am fine with closing it as outdated and one can reopen if they need this along with reviving the removed tests in the PR.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36092>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:08:52 2019
From: report at bugs.python.org (David Nicolson)
Date: Tue, 12 Nov 2019 11:08:52 +0000
Subject: [issue38777] plist handling of real data type
Message-ID: <1573556932.79.0.676110045358.issue38777@roundup.psfhosted.org>


New submission from David Nicolson <david.nicolson at gmail.com>:

Converting float values stored as strings with the real data type can result in an integer value or a rounding error.

import plistlib

xml = """<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>FloatExample</key>
<real>100.0</real>
<key>FloatExample2</key>
<real>0.1</real>
</dict>
</plist>
"""

pl = plistlib.loads(str.encode(xml), fmt=plistlib.FMT_XML)
with open('test.plist', 'wb') as fp:
  plistlib.dump(pl, fp, fmt=plistlib.FMT_BINARY)

cat test.plist | plutil -convert xml1 -o - -- -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>FloatExample</key>
	<real>100</real>
	<key>FloatExample2</key>
	<real>0.10000000000000001</real>
</dict>
</plist>

This might be related to the following issue:

https://bugs.python.org/issue14896

----------
messages: 356440
nosy: David Nicolson
priority: normal
severity: normal
status: open
title: plist handling of real data type
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38777>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:13:40 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 11:13:40 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573557220.49.0.342687871503.issue26353@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8ce1a9ce038d1a5fda03ae76964002857a2a52f9 by Miss Islington (bot) in branch '3.8':
bpo-26353: IDLE adds an unneeded newline when saving a shell window (GH-17103)
https://github.com/python/cpython/commit/8ce1a9ce038d1a5fda03ae76964002857a2a52f9


----------
nosy: +miss-islington, miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:13:40 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 11:13:40 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573557220.38.0.81017210175.issue26353@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 177b12682cad7edf9cdea91382acc4232c0167e6 by Miss Islington (bot) in branch '3.7':
bpo-26353: IDLE adds an unneeded newline when saving a shell window (GH-17103)
https://github.com/python/cpython/commit/177b12682cad7edf9cdea91382acc4232c0167e6


----------
nosy: +miss-islington, miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:13:40 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 11:13:40 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573557220.38.0.81017210175.issue26353@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 177b12682cad7edf9cdea91382acc4232c0167e6 by Miss Islington (bot) in branch '3.7':
bpo-26353: IDLE adds an unneeded newline when saving a shell window (GH-17103)
https://github.com/python/cpython/commit/177b12682cad7edf9cdea91382acc4232c0167e6


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:14:07 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Nov 2019 11:14:07 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573557247.96.0.79671303834.issue26353@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:22:24 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 11:22:24 +0000
Subject: [issue38777] plist handling of real data type
In-Reply-To: <1573556932.79.0.676110045358.issue38777@roundup.psfhosted.org>
Message-ID: <1573557744.13.0.110016451829.issue38777@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38777>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:26:46 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 11:26:46 +0000
Subject: [issue38777] plist handling of real data type
In-Reply-To: <1573556932.79.0.676110045358.issue38777@roundup.psfhosted.org>
Message-ID: <1573558006.2.0.208087774925.issue38777@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This looks like a plutil issue.

----------
nosy: +ronaldoussoren, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38777>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:27:28 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 11:27:28 +0000
Subject: [issue38763] mock with side effect : assert_called_once returns None
 while call_count returns 1
In-Reply-To: <1573423763.08.0.825923255021.issue38763@roundup.psfhosted.org>
Message-ID: <1573558048.5.0.449975723053.issue38763@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think we can close this as not a bug. I don't think we need to add boolean return value of True if the assert statements are True since it's never meant to be used. I would wait for others opinion on this.

----------
nosy: +cjw296, lisroach, mariocj89, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38763>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:28:07 2019
From: report at bugs.python.org (Jackson Riley)
Date: Tue, 12 Nov 2019 11:28:07 +0000
Subject: [issue36092] unittest.mock's patch.object and patch.dict are not
 supported on classmethod, propery and staticmethod
In-Reply-To: <1550904704.81.0.829273897144.issue36092@roundup.psfhosted.org>
Message-ID: <1573558087.04.0.919949519604.issue36092@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Thanks Karthikeyan!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36092>
_______________________________________

From report at bugs.python.org  Tue Nov 12 06:53:49 2019
From: report at bugs.python.org (Alex)
Date: Tue, 12 Nov 2019 11:53:49 +0000
Subject: [issue9495] argparse unittest tracebacks are confusing if an error is
 raised when not expected
In-Reply-To: <1280852518.56.0.709280463518.issue9495@psf.upfronthosting.co.za>
Message-ID: <1573559629.68.0.363403639289.issue9495@roundup.psfhosted.org>


Change by Alex <alexpclarkson at gmail.com>:


----------
pull_requests: +16626
pull_request: https://github.com/python/cpython/pull/17120

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9495>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:10:17 2019
From: report at bugs.python.org (Anj-A)
Date: Tue, 12 Nov 2019 12:10:17 +0000
Subject: [issue37436] os.path.isfile() with big number cause OverflowError: fd
 is greater than maximum
In-Reply-To: <1561686823.22.0.469835611791.issue37436@roundup.psfhosted.org>
Message-ID: <1573560617.09.0.384325224879.issue37436@roundup.psfhosted.org>


Anj-A <2017anj at gmail.com> added the comment:

Hey, if there is no bug here, could we get this issue closed?
Alternatively, I'd be interested in doing the required change in documentation/error type if that's seen to be the right solution.

Personally, I think returning False instead of raising an error would indeed mask bugs as mentioned by Zufu. As for the error type to be raised, the argument type itself isn't wrong, it's just greater than the maximum so I feel an OverflowError type is right instead of TypeError. So maybe just clearer documentation is needed as suggested by Aldwin and no code change? Just my two cents though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37436>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:26:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 12:26:21 +0000
Subject: [issue37436] os.path.isfile() with big number cause OverflowError: fd
 is greater than maximum
In-Reply-To: <1561686823.22.0.469835611791.issue37436@roundup.psfhosted.org>
Message-ID: <1573561581.22.0.813928022182.issue37436@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37436>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:29:43 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 12 Nov 2019 12:29:43 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1573561783.01.0.706554047497.issue16576@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 106271568c58cfebae58f0c52b640dbe716ba2ce by Vinay Sajip in branch 'master':
bpo-16576: Add checks for bitfields passed by value to functions. (GH-17097)
https://github.com/python/cpython/commit/106271568c58cfebae58f0c52b640dbe716ba2ce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:31:01 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 12:31:01 +0000
Subject: [issue37855] Compiling Python 3.7.4 with Intel compilers 2019
In-Reply-To: <1565808494.42.0.743401642234.issue37855@roundup.psfhosted.org>
Message-ID: <1573561861.71.0.597678111224.issue37855@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also issue37415

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37855>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:38:54 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 12:38:54 +0000
Subject: [issue38421] email.utils.parsetime_tz does not return "None" as the
 tz offset
In-Reply-To: <1570625103.37.0.0601159046628.issue38421@roundup.psfhosted.org>
Message-ID: <1573562334.93.0.877355405945.issue38421@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a12255d8def0c82560545e66c1be981a447751c3 by Miss Islington (bot) (David K) in branch 'master':
bpo-38421: Update email.utils documentation (GH-16678)
https://github.com/python/cpython/commit/a12255d8def0c82560545e66c1be981a447751c3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38421>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:39:05 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 12:39:05 +0000
Subject: [issue38421] email.utils.parsetime_tz does not return "None" as the
 tz offset
In-Reply-To: <1570625103.37.0.0601159046628.issue38421@roundup.psfhosted.org>
Message-ID: <1573562345.26.0.128316505533.issue38421@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16627
pull_request: https://github.com/python/cpython/pull/17121

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38421>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:39:35 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 12:39:35 +0000
Subject: [issue38421] email.utils.parsetime_tz does not return "None" as the
 tz offset
In-Reply-To: <1570625103.37.0.0601159046628.issue38421@roundup.psfhosted.org>
Message-ID: <1573562375.83.0.0915961056271.issue38421@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16628
pull_request: https://github.com/python/cpython/pull/17122

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38421>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:43:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 12:43:16 +0000
Subject: [issue35856] bundled pip syntaxwarning
In-Reply-To: <1548822232.71.0.928620315145.issue35856@roundup.psfhosted.org>
Message-ID: <1573562596.82.0.816836490747.issue35856@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this is fixed in pip's side with requests package upgraded with https://github.com/pypa/pip/commit/785ecf476a63e00819ef1b14bc8ee758dc9c12cb#diff-9235561c186d44f2bb0eef8b7f1d57ceR3 using raw string literls. I think we can close this as outdated and further issues also need to be fixed from pip's repo. Adding pradyun.

----------
nosy: +pradyunsg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35856>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:46:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 12:46:57 +0000
Subject: [issue35666] Update design FAQ about assignment expression
In-Reply-To: <1546704480.61.0.245493701505.issue35666@roundup.psfhosted.org>
Message-ID: <1573562817.1.0.475568461861.issue35666@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is updated with 6357c95716d89ac1f80587fbc4133df8d2e8396c . Closing this as fixed. Feel free to reopen if needed. Thanks.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35666>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:50:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Nov 2019 12:50:16 +0000
Subject: [issue35192] pathlib mkdir throws FileExistsError when not supposed to
In-Reply-To: <1541707708.76.0.788709270274.issue35192@psf.upfronthosting.co.za>
Message-ID: <1573563016.85.0.943170624877.issue35192@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing this as duplicate of issue29694. I hope this is backported to Ubuntu repos and there is not much pending work to this issue. Thanks.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> race condition in pathlib mkdir with flags parents=True

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35192>
_______________________________________

From report at bugs.python.org  Tue Nov 12 07:50:33 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 12 Nov 2019 12:50:33 +0000
Subject: [issue35856] bundled pip syntaxwarning
In-Reply-To: <1548822232.71.0.928620315145.issue35856@roundup.psfhosted.org>
Message-ID: <1573563033.7.0.530807441154.issue35856@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35856>
_______________________________________

From report at bugs.python.org  Tue Nov 12 08:08:04 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 13:08:04 +0000
Subject: [issue36974] Implement PEP 590
In-Reply-To: <1559154718.16.0.347735090162.issue36974@roundup.psfhosted.org>
Message-ID: <1573564084.06.0.54473150714.issue36974@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9a13a388f202268dd7b771638adbec132449b98b by Miss Islington (bot) (Jeroen Demeyer) in branch 'master':
bpo-36974: expand call protocol documentation (GH-13844)
https://github.com/python/cpython/commit/9a13a388f202268dd7b771638adbec132449b98b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36974>
_______________________________________

From report at bugs.python.org  Tue Nov 12 08:30:12 2019
From: report at bugs.python.org (Chris Withers)
Date: Tue, 12 Nov 2019 13:30:12 +0000
Subject: [issue38763] mock with side effect : assert_called_once returns None
 while call_count returns 1
In-Reply-To: <1573423763.08.0.825923255021.issue38763@roundup.psfhosted.org>
Message-ID: <1573565412.71.0.903609073167.issue38763@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38763>
_______________________________________

From report at bugs.python.org  Tue Nov 12 08:34:23 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 13:34:23 +0000
Subject: [issue38421] email.utils.parsetime_tz does not return "None" as the
 tz offset
In-Reply-To: <1570625103.37.0.0601159046628.issue38421@roundup.psfhosted.org>
Message-ID: <1573565663.29.0.400961729837.issue38421@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset eadddad6b093bca74601b1ea91ab96119bc543d8 by Miss Islington (bot) in branch '3.7':
[3.7] bpo-38421: Update email.utils documentation (GH-16678) (GH-17121)
https://github.com/python/cpython/commit/eadddad6b093bca74601b1ea91ab96119bc543d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38421>
_______________________________________

From report at bugs.python.org  Tue Nov 12 08:34:27 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 13:34:27 +0000
Subject: [issue38421] email.utils.parsetime_tz does not return "None" as the
 tz offset
In-Reply-To: <1570625103.37.0.0601159046628.issue38421@roundup.psfhosted.org>
Message-ID: <1573565667.18.0.423980130791.issue38421@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 29fd6a77d509cffacc5691ebd9dab53455ad959e by Miss Islington (bot) in branch '3.8':
[3.8] bpo-38421: Update email.utils documentation (GH-16678) (GH-17122)
https://github.com/python/cpython/commit/29fd6a77d509cffacc5691ebd9dab53455ad959e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38421>
_______________________________________

From report at bugs.python.org  Tue Nov 12 08:39:15 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 12 Nov 2019 13:39:15 +0000
Subject: [issue38421] email.utils.parsetime_tz does not return "None" as the
 tz offset
In-Reply-To: <1570625103.37.0.0601159046628.issue38421@roundup.psfhosted.org>
Message-ID: <1573565955.16.0.0149263199312.issue38421@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Thank you for the fix!

----------
nosy: +petr.viktorin
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38421>
_______________________________________

From report at bugs.python.org  Tue Nov 12 08:52:43 2019
From: report at bugs.python.org (Pradyun Gedam)
Date: Tue, 12 Nov 2019 13:52:43 +0000
Subject: [issue35856] bundled pip syntaxwarning
In-Reply-To: <1573563033.72.0.000633801591201.issue35856@roundup.psfhosted.org>
Message-ID: <CAPA-Eqvxr=G9tq627J+j0rXHnPQOJ14vdD17pBXXbqtrunJ-wQ@mail.gmail.com>


Pradyun Gedam <pradyunsg at gmail.com> added the comment:

Closing this sounds reasonable to me!

There are a couple of pending PRs for updating the pip, in the current
versions of CPython. That's being tracked separately so likely don't need
this to stay open anymore.

On Tue, 12 Nov 2019 at 6:20 PM, Inada Naoki <report at bugs.python.org> wrote:

>
> Change by Inada Naoki <songofacandy at gmail.com>:
>
>
> ----------
> resolution:  -> third party
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35856>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35856>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:09:51 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 12 Nov 2019 14:09:51 +0000
Subject: [issue38774] Statements in try block still executes after raised error
In-Reply-To: <1573552090.89.0.826307199314.issue38774@roundup.psfhosted.org>
Message-ID: <1573567791.51.0.952155726469.issue38774@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Please try your script in the vanilla Python interpreter. If it behaves correctly, you should report this issue to Spyder and/or IPython.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38774>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:17:51 2019
From: report at bugs.python.org (=?utf-8?b?0JPRgNC40LPQvtGA0LjQuSDQqNC10LLRh9C10L3QutC+?=)
Date: Tue, 12 Nov 2019 14:17:51 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1573568271.2.0.791952517223.issue38731@roundup.psfhosted.org>


Change by ???????? ???????? <gvsheva at gmail.com>:


----------
nosy: +???????? ????????

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:38:20 2019
From: report at bugs.python.org (Phil Connell)
Date: Tue, 12 Nov 2019 14:38:20 +0000
Subject: [issue38778] Document that os.fork is not allowed in subinterpreters
Message-ID: <1573569500.54.0.207485115661.issue38778@roundup.psfhosted.org>


New submission from Phil Connell <pconnell at gmail.com>:

Add a comment to the os.fork docs to note that forking from a subinterpreter is no longer allowed (see issue34651)

----------
assignee: docs at python
components: Documentation
messages: 356459
nosy: docs at python, eric.snow, pconnell
priority: normal
severity: normal
status: open
title: Document that os.fork is not allowed in subinterpreters
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38778>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:39:47 2019
From: report at bugs.python.org (Zufu Liu)
Date: Tue, 12 Nov 2019 14:39:47 +0000
Subject: [issue37436] os.path.isfile() with big number cause OverflowError: fd
 is greater than maximum
In-Reply-To: <1561686823.22.0.469835611791.issue37436@roundup.psfhosted.org>
Message-ID: <1573569587.95.0.688556118092.issue37436@roundup.psfhosted.org>


Zufu Liu <zufuliu at 163.com> added the comment:

I'm fine with this been closed.
Maybe it's better to have a RawFd type like Julia:

julia> RawFD
RawFD

julia> typeof(RawFD)
DataType

julia> RawFD(0)
RawFD(0x00000000)

julia> RawFD(0)==0
false

Rust has RawFd as c_int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37436>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:41:03 2019
From: report at bugs.python.org (Michael H)
Date: Tue, 12 Nov 2019 14:41:03 +0000
Subject: [issue38779] Simple typo in strings module documentation
Message-ID: <1573569663.29.0.774933037403.issue38779@roundup.psfhosted.org>


New submission from Michael H <mchartley.uk at gmail.com>:

https://docs.python.org/3/tutorial/introduction.html#strings

In the strings part of the basic tutorial, there is an output error regarding the escaping of the single quote

>>> '"Isn\'t," they said.'
'"Isn\'t," they said.' # I think the output should be correct

Thanks

----------
assignee: docs at python
components: Documentation
messages: 356461
nosy: Michael H2, docs at python
priority: normal
severity: normal
status: open
title: Simple typo in strings module documentation
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38779>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:44:18 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Nov 2019 14:44:18 +0000
Subject: [issue38778] Document that os.fork is not allowed in subinterpreters
In-Reply-To: <1573569500.54.0.207485115661.issue38778@roundup.psfhosted.org>
Message-ID: <1573569858.1.0.512488295148.issue38778@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38778>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:44:18 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Nov 2019 14:44:18 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>
Message-ID: <1573569858.27.0.297990011622.issue34651@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +16630
pull_request: https://github.com/python/cpython/pull/17123

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:45:15 2019
From: report at bugs.python.org (Michael H)
Date: Tue, 12 Nov 2019 14:45:15 +0000
Subject: [issue38779] Simple typo in strings module documentation
In-Reply-To: <1573569663.29.0.774933037403.issue38779@roundup.psfhosted.org>
Message-ID: <1573569915.68.0.911705503023.issue38779@roundup.psfhosted.org>


Michael H <mchartley.uk at gmail.com> added the comment:

Sorry, its my bad, it is correct as it is, I hadn't read further on about the print statement being needed. As I am working through the tutorial in pycharm, I am had already used print statement.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38779>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:53:01 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Nov 2019 14:53:01 +0000
Subject: [issue38779] Simple typo in strings module documentation
In-Reply-To: <1573569663.29.0.774933037403.issue38779@roundup.psfhosted.org>
Message-ID: <1573570381.02.0.00210562100404.issue38779@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

You're right, it is correct as is; the regular output of the REPL is essentially `print(repr(_))`.

Please do feel free to report any issues you find, though you may want to send a message to tutor at python.org to check anything you're not sure about.

Welcome to Python!

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38779>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:54:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 14:54:06 +0000
Subject: [issue37436] os.path.isfile() with big number cause OverflowError: fd
 is greater than maximum
In-Reply-To: <1561686823.22.0.469835611791.issue37436@roundup.psfhosted.org>
Message-ID: <1573570446.92.0.611261356613.issue37436@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I considered this. There is a limited number of functions that can produce RawFD (os.open(), os.dup(), etc), and this is a single source of file descriptors in an isolated program. File descriptors can be inherited by child processes. But there are other methods of interprocess communication, and depending of the serialization method the type of the file descriptor can be lost. So there is a possibility to break existing programs. The transition can be made smooth, with corresponding deprecation period if we decide that the final befit is larger than the transition cost.

In any case this is a large change. It should be discussed on the Python-ideas or Python-Dev mailing lists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37436>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:55:46 2019
From: report at bugs.python.org (Michael H)
Date: Tue, 12 Nov 2019 14:55:46 +0000
Subject: [issue38779] Simple typo in strings module documentation
In-Reply-To: <1573569663.29.0.774933037403.issue38779@roundup.psfhosted.org>
Message-ID: <1573570546.71.0.321692139111.issue38779@roundup.psfhosted.org>


Michael H <mchartley.uk at gmail.com> added the comment:

Many thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38779>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:57:10 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 14:57:10 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573570630.74.0.691781658642.issue38738@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 138ccbb02216ca086047c3139857fb44f3dab1f9 by Serhiy Storchaka in branch 'master':
bpo-38738: Fix formatting of True and False. (GH-17083)
https://github.com/python/cpython/commit/138ccbb02216ca086047c3139857fb44f3dab1f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Tue Nov 12 09:59:58 2019
From: report at bugs.python.org (Alex)
Date: Tue, 12 Nov 2019 14:59:58 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1573570798.08.0.152482659698.issue15243@roundup.psfhosted.org>


Change by Alex <alexpclarkson at gmail.com>:


----------
pull_requests: +16632
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17124

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Tue Nov 12 10:02:49 2019
From: report at bugs.python.org (Jackson Riley)
Date: Tue, 12 Nov 2019 15:02:49 +0000
Subject: [issue17306] Improve the way abstract base classes are shown in help()
In-Reply-To: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za>
Message-ID: <1573570969.65.0.21154175103.issue17306@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Hi Raymond - here's a first attempt at adding class-level docstrings, based off the format of Sequence.__doc__. Apologies if some things are not well worded etc.

It looks like all of the non-magic methods have docstrings already but if you think the magic methods need docstrings then I will add them.

----------
keywords: +patch
Added file: https://bugs.python.org/file48710/abc_class_level.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17306>
_______________________________________

From report at bugs.python.org  Tue Nov 12 10:04:07 2019
From: report at bugs.python.org (Alex)
Date: Tue, 12 Nov 2019 15:04:07 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1573571047.15.0.633788872349.issue15243@roundup.psfhosted.org>


Change by Alex <alexpclarkson at gmail.com>:


----------
nosy: +alclarks

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Tue Nov 12 10:05:56 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 Nov 2019 15:05:56 +0000
Subject: [issue38777] plist handling of real data type
In-Reply-To: <1573556932.79.0.676110045358.issue38777@roundup.psfhosted.org>
Message-ID: <1573571156.78.0.344048219677.issue38777@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't think this is a bug. The value's in the plutil output are correct, and marked up with the correct type in both cases. 

The difference between 0.1 and 0.10000000000000001 is the usual problem with floating point representation (see the python.org FAQ).  Plutil uses a different algorithm for printing float's than Python, but both evaluate to the same binary representation for the float value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38777>
_______________________________________

From report at bugs.python.org  Tue Nov 12 10:08:00 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 15:08:00 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573571280.26.0.0490213245228.issue38738@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +16633
pull_request: https://github.com/python/cpython/pull/17125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Tue Nov 12 10:12:09 2019
From: report at bugs.python.org (Jackson Riley)
Date: Tue, 12 Nov 2019 15:12:09 +0000
Subject: [issue34716] MagicMock.__divmod__ should return a pair
In-Reply-To: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>
Message-ID: <1573571529.09.0.0172157341785.issue34716@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Hi Serhiy,

Option 3 sounds most sensible to me.
I'd be happy to pick up this issue, please do let me know.

----------
nosy: +jacksonriley

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34716>
_______________________________________

From report at bugs.python.org  Tue Nov 12 10:19:21 2019
From: report at bugs.python.org (Benjamin Edwards)
Date: Tue, 12 Nov 2019 15:19:21 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1573571961.31.0.785874714836.issue37838@roundup.psfhosted.org>


Change by Benjamin Edwards <benjaminedwards at live.co.uk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Tue Nov 12 10:20:46 2019
From: report at bugs.python.org (Benjamin Edwards)
Date: Tue, 12 Nov 2019 15:20:46 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1573572046.39.0.329680021117.issue37838@roundup.psfhosted.org>


Benjamin Edwards <benjaminedwards at live.co.uk> added the comment:

Have opened a PR, let me know if there is anything that needs fixing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Tue Nov 12 10:34:44 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Nov 2019 15:34:44 +0000
Subject: [issue38723] Pdb._runscript should use io.open_code() instead of
 open()
In-Reply-To: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>
Message-ID: <1573572884.41.0.667683178761.issue38723@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38723>
_______________________________________

From report at bugs.python.org  Tue Nov 12 11:03:19 2019
From: report at bugs.python.org (Phil Connell)
Date: Tue, 12 Nov 2019 16:03:19 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1573574599.49.0.770783345602.issue33608@roundup.psfhosted.org>


Change by Phil Connell <pconnell at gmail.com>:


----------
nosy: +pconnell

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Tue Nov 12 11:29:04 2019
From: report at bugs.python.org (=?utf-8?q?Torbj=C3=B8rn_Wikestad?=)
Date: Tue, 12 Nov 2019 16:29:04 +0000
Subject: [issue38774] Statements in try block still executes after raised error
In-Reply-To: <1573552090.89.0.826307199314.issue38774@roundup.psfhosted.org>
Message-ID: <1573576144.77.0.327936706985.issue38774@roundup.psfhosted.org>


Torbj?rn Wikestad <torbjorn.wikestad at gmail.com> added the comment:

The script has been tried and found to work as intended in the Idle IDE, which runs on a standard win32 python shell. So the error is linked only with IPython or Spyder.

----------
Added file: https://bugs.python.org/file48711/2019-11-12_try-clause,numpy,random,copy,time,ipython,spyder,python36.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38774>
_______________________________________

From report at bugs.python.org  Tue Nov 12 11:34:57 2019
From: report at bugs.python.org (=?utf-8?q?Torbj=C3=B8rn_Wikestad?=)
Date: Tue, 12 Nov 2019 16:34:57 +0000
Subject: [issue38774] Statements in try block still executes after raised error
In-Reply-To: <1573552090.89.0.826307199314.issue38774@roundup.psfhosted.org>
Message-ID: <1573576497.13.0.116883201293.issue38774@roundup.psfhosted.org>


Torbj?rn Wikestad <torbjorn.wikestad at gmail.com> added the comment:

I could not reproduce the error when I open the script in Spyder anew.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38774>
_______________________________________

From report at bugs.python.org  Tue Nov 12 11:54:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 16:54:30 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573577670.49.0.0410098148519.issue38738@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d360346640e19231032b072216195484fa2450b4 by Serhiy Storchaka in branch '3.8':
[3.8] bpo-38738: Fix formatting of True and False. (GH-17083) (GH-17125)
https://github.com/python/cpython/commit/d360346640e19231032b072216195484fa2450b4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Tue Nov 12 12:00:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 17:00:15 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573578015.16.0.310498242232.issue38738@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +16637
pull_request: https://github.com/python/cpython/pull/17128

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Tue Nov 12 12:01:34 2019
From: report at bugs.python.org (David Nicolson)
Date: Tue, 12 Nov 2019 17:01:34 +0000
Subject: [issue38777] plist handling of real data type
In-Reply-To: <1573556932.79.0.676110045358.issue38777@roundup.psfhosted.org>
Message-ID: <1573578094.41.0.877018830034.issue38777@roundup.psfhosted.org>


David Nicolson <david.nicolson at gmail.com> added the comment:

It looks like it's just inconsistency in plutil that is causing the confusion.

/usr/libexec/PlistBuddy -c Print test.plist
Dict {
    FloatExample2 = 0.100000
    FloatExample3 = 100.000000
    FloatExample = 0.000000
}

cat test.plist | plutil -convert xml1 -o - -- -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>FloatExample</key>
	<real>0.0</real>
	<key>FloatExample2</key>
	<real>0.10000000000000001</real>
	<key>FloatExample3</key>
	<real>100</real>
</dict>
</plist>

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38777>
_______________________________________

From report at bugs.python.org  Tue Nov 12 12:09:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 17:09:11 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1573578551.15.0.811560950186.issue38731@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Tue Nov 12 12:26:09 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 17:26:09 +0000
Subject: [issue38780] SysLogHandler crash atexit
Message-ID: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

On Python 3.8.0:

$ python -c "import logging.handlers, socket; handler = logging.handlers.SysLogHandler(facility=logging.handlers.SysLogHandler.LOG_LOCAL7, address='/dev/log', socktype=socket.SOCK_RAW)"                                                     
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/logging/__init__.py", line 2112, in shutdown
    h.close()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/logging/handlers.py", line 892, in close
    self.socket.close()
AttributeError: 'SysLogHandler' object has no attribute 'socket'

Probably that shouldn't happen.

----------
messages: 356475
nosy: jaraco
priority: normal
severity: normal
status: open
title: SysLogHandler crash atexit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 12:26:38 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 17:26:38 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573579598.52.0.0576815173757.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Same error on Python 2.7 and 3.7

----------
versions: +Python 2.7, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:07:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 18:07:30 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573582050.62.0.965597880402.issue38738@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 42b619ac9aa7f889dcd8eeb14d813f17468454d9 by Serhiy Storchaka in branch '3.7':
[3.7] bpo-38738: Fix formatting of True and False. (GH-17083) (GH-17128)
https://github.com/python/cpython/commit/42b619ac9aa7f889dcd8eeb14d813f17468454d9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:11:48 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Nov 2019 18:11:48 +0000
Subject: [issue16885] SQLite3 iterdump ordering
In-Reply-To: <1357569830.11.0.727312766793.issue16885@psf.upfronthosting.co.za>
Message-ID: <1573582308.2.0.432763539683.issue16885@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16885>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:21:01 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 18:21:01 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573582861.84.0.945156246105.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I only observe this issue on macOS. On Linux, the error doesn't occur.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:21:21 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 18:21:21 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573582881.33.0.710857085134.issue38780@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
components: +Library (Lib), macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:39:32 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Nov 2019 18:39:32 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573583972.87.0.360013046794.issue38780@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:44:16 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 18:44:16 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573584256.76.0.790609317389.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I guess that makes sense, as `/dev/log` doesn't exist on macOS. So maybe this usage is invalid. But still I'd expect the handler to error early or at least not error on shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:47:51 2019
From: report at bugs.python.org (Jason Killen)
Date: Tue, 12 Nov 2019 18:47:51 +0000
Subject: [issue38741] Definition of multiple ']' in header configparser
In-Reply-To: <1573193272.74.0.118296138456.issue38741@roundup.psfhosted.org>
Message-ID: <1573584471.67.0.90478101725.issue38741@roundup.psfhosted.org>


Change by Jason Killen <jsnklln at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38741>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:52:16 2019
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 12 Nov 2019 18:52:16 +0000
Subject: [issue29302] add contextlib.AsyncExitStack
In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za>
Message-ID: <1573584736.46.0.630393486683.issue29302@roundup.psfhosted.org>


Change by Ilya Kulakov <kulakov.ilya at gmail.com>:


----------
pull_requests: +16640
pull_request: https://github.com/python/cpython/pull/17130

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29302>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:52:16 2019
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 12 Nov 2019 18:52:16 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1573584736.28.0.921385976681.issue26467@roundup.psfhosted.org>


Change by Ilya Kulakov <kulakov.ilya at gmail.com>:


----------
pull_requests: +16639
pull_request: https://github.com/python/cpython/pull/17130

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26467>
_______________________________________

From report at bugs.python.org  Tue Nov 12 13:56:17 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 18:56:17 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573584977.91.0.982028510471.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

For background, this issue originated from https://github.com/pytest-dev/pytest-services/issues/20.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 14:18:52 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 19:18:52 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573586332.75.0.865851878502.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The issue probably stems from https://github.com/python/cpython/blob/138ccbb02216ca086047c3139857fb44f3dab1f9/Lib/logging/handlers.py#L828-L835. I doubt the logic of that comment, as in the non-unix-socket case, the error is raised if a connection cannot be established. Fixing the issue by re-considering that comment would have backward-incompatible implications and would violate the intention of the comment's author.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 14:21:30 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 19:21:30 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573586490.91.0.0521838705209.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In the downstream issue, it's also reported that crashes occur in emit as well, suggesting that the comment is additionally wrong on that front.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 14:32:03 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Nov 2019 19:32:03 +0000
Subject: [issue38773] Fatal Python error: Aborted
In-Reply-To: <1573532347.12.0.111468520107.issue38773@roundup.psfhosted.org>
Message-ID: <1573587123.57.0.300306900516.issue38773@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38773>
_______________________________________

From report at bugs.python.org  Tue Nov 12 14:38:47 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Nov 2019 19:38:47 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1573587527.5.0.712528005259.issue38500@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I would like to bring this issue back on topic as this about how to expose PEP 523 support in Python 3.8, not whether Fabio should be using a different approach when he has been something sanctioned in an accepted PEP and was previously doable that was (accidentally) taken away from him.

If people want to do a separate PEP to roll back PEP 523 that's fine, but until that occurs I think we should move forward with the fact that PEP 523 is active.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Tue Nov 12 14:42:04 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 19:42:04 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573587724.47.0.646861908586.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I could imagine extending the shutdown code to catch the reported error (https://github.com/python/cpython/blob/138ccbb02216ca086047c3139857fb44f3dab1f9/Lib/logging/__init__.py#L2130-L2135), but that wouldn't address the error in emit.

Similarly, the SysLogHandler could override shutdown to bypass the error if no socket attribute is present, but that again wouldn't address the emit case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 14:43:16 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Nov 2019 19:43:16 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1573587796.66.0.313166398232.issue26467@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Adding Lisa to potentially add the PR from Ilya.

----------
assignee:  -> lisroach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26467>
_______________________________________

From report at bugs.python.org  Tue Nov 12 15:41:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 20:41:16 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573591276.76.0.579820318564.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16641
pull_request: https://github.com/python/cpython/pull/17131

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:12:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 21:12:23 +0000
Subject: [issue37855] Compiling Python 3.7.4 with Intel compilers 2019
In-Reply-To: <1565808494.42.0.743401642234.issue37855@roundup.psfhosted.org>
Message-ID: <1573593143.56.0.975010475943.issue37855@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue looks like a variant of bpo-37415 which has been fixed in the 3.7 branch by:

New changeset b102e4f05278c1b06130885eba961bd0193733b4 by Miss Skeleton (bot) in branch '3.7':
bpo-37415: Fix stdatomic.h header check for ICC compiler (GH-16717)
https://github.com/python/cpython/commit/b102e4f05278c1b06130885eba961bd0193733b4

You can try the 3.7 branch to get the fix, or apply manually the fix.

Note: The icc compiler is not officially supported.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37855>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:12:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 21:12:49 +0000
Subject: [issue37855] Compiling Python 3.7.4 with Intel compilers 2019
In-Reply-To: <1565808494.42.0.743401642234.issue37855@roundup.psfhosted.org>
Message-ID: <1573593169.2.0.327750714785.issue37855@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution: fixed -> duplicate
superseder:  -> Error build Python with Intel compiler: <stdatomic.h> doesn't provide atomic_uintptr_t

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37855>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:17:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 21:17:32 +0000
Subject: [issue38739] pyperformance html5lib cannot import Mapping (and fails)
In-Reply-To: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>
Message-ID: <1573593452.61.0.352143164502.issue38739@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> FYI: this affects tornado_http and django_template as well.

Please report pyperformance issues at:
https://github.com/python/pyperformance/issues

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38739>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:23:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 21:23:37 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573593817.68.0.993083803214.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It seems like systemd-nspawn is just breaking everything: https://sourceware.org/ml/libc-alpha/2019-11/msg00277.html

Well, we can try to argue to not block syscalls, but I'm not sure that we can win such battle :-) For os.urandom(), I chose to handle EPERM as ENOSYS in bpo-27955. Extract of Python/bootstrap_hash.c:

            /* ENOSYS: the syscall is not supported by the kernel.
               EPERM: the syscall is blocked by a security policy (ex: SECCOMP)
               or something else. */
            if (errno == ENOSYS || errno == EPERM) {
                getrandom_works = 0;
                return 0;
            }

We can just skip the test if the syscall fails with EPERM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:43:12 2019
From: report at bugs.python.org (Daniel Andersson)
Date: Tue, 12 Nov 2019 21:43:12 +0000
Subject: [issue38781] Clear buffer in MemoryHandler flush
Message-ID: <1573594992.8.0.415095728854.issue38781@roundup.psfhosted.org>


New submission from Daniel Andersson <daniel.4ndersson at gmail.com>:

The `logging.handlers.MemoryHandler` has a method `flush` which clears the buffer by assigning an empty list literal:

self.buffer = []

This forces the buffer to be a list instance.
My suggestion is to clear the buffer like this instead:

self.buffer.clear()

In this way it would be possible to implement a custom buffer or use the `collections.deque` when subclassing `MemoryHandler`. At the moment you must copy-past the `flush` method and modify it accordingly in the subclass:

```
def flush(self):
    # (Docstring skipped)
    self.acquire()
    try:
        if self.target:
	    for record in self.buffer:
	        self.target.handle(record)
	    self.buffer = []  # <-- change to `self.buffer.clear()`
    finally:
        self.release()
```

Example where this change is useful
===================================
This example creates a DequeMemoryHandler which uses the `collections.deque` as a buffer. Only the latest `capacity` number of records will stored in the buffer. The buffer is then flushed if and only if a record has a level greater or equal to `logging.ERROR`.

```
import collections
import logging
from logging.handlers import MemoryHandler


class DequeMemoryHandler(MemoryHandler):

    def __init__(self, capacity, *args, **kwargs):
        super().__init__(capacity, *args, **kwargs)
        self.buffer = collections.deque(maxlen=capacity)

    def shouldFlush(self, record):
        return record.levelno >= self.flushLevel


handler = DequeMemoryHandler(capacity=5, target=logging.StreamHandler())
logging.basicConfig(level=logging.INFO, handlers=[handler])

for i in range(1, 21):
    logging.info('Spam %d', i)
    if i % 10 == 0:
        logging.error(f'---> Eggs {i}')
```


Desired output (with the change):
---------------------------------
Spam 7
Spam 8
Spam 9
Spam 10
---> Eggs 10
Spam 17
Spam 18
Spam 19
Spam 20
---> Eggs 20


Actual output (without the change):
-----------------------------------
Spam 7
Spam 8
Spam 9
Spam 10
---> Eggs 10
Spam 11
Spam 12
Spam 13
Spam 14
Spam 15
Spam 16
Spam 17
Spam 18
Spam 19
Spam 20
---> Eggs 20

----------
components: Library (Lib)
messages: 356489
nosy: penlect, vinay.sajip
priority: normal
severity: normal
status: open
title: Clear buffer in MemoryHandler flush
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38781>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:46:50 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 Nov 2019 21:46:50 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1573595210.87.0.932539047785.issue38780@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As you noted /dev/log doesn't exist on macOS (the correct path is /var/run/syslog).

I guess the change that would be most in spirit of the comment is to set self.socket to None when the socket cannot be opened and test for that before closing the socket.  Likewise, emit() can test if self.socket is None and then attempt to open the socket (and not write to the log when the socket still is None)

This makes errors pass silently, but does match the spirit of the POSIX API (where the syslog function does not return an error).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:46:41 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Tue, 12 Nov 2019 21:46:41 +0000
Subject: [issue16142] ArgumentParser inconsistent with parse_known_args
In-Reply-To: <1349448801.58.0.783623579173.issue16142@psf.upfronthosting.co.za>
Message-ID: <1573595201.3.0.88060215773.issue16142@roundup.psfhosted.org>


Change by Lewis Gaul <lewis.gaul at gmail.com>:


----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16142>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:51:34 2019
From: report at bugs.python.org (Daniel Andersson)
Date: Tue, 12 Nov 2019 21:51:34 +0000
Subject: [issue38781] Clear buffer in MemoryHandler flush
In-Reply-To: <1573594992.8.0.415095728854.issue38781@roundup.psfhosted.org>
Message-ID: <1573595494.58.0.615770817541.issue38781@roundup.psfhosted.org>


Change by Daniel Andersson <daniel.4ndersson at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38781>
_______________________________________

From report at bugs.python.org  Tue Nov 12 16:52:05 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 21:52:05 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573595525.48.0.29504379406.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

We should not claim to support running our tests in weird syscall sandboxes. There's an infinite number of possible sandboxing configurations, and we can't fix them all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:02:34 2019
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 12 Nov 2019 22:02:34 +0000
Subject: [issue17013] Allow waiting on a mock
In-Reply-To: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za>
Message-ID: <1573596154.36.0.424827520396.issue17013@roundup.psfhosted.org>


Change by Ilya Kulakov <kulakov.ilya at gmail.com>:


----------
pull_requests: +16643
pull_request: https://github.com/python/cpython/pull/17133

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17013>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:02:42 2019
From: report at bugs.python.org (Gregory Shevchenko)
Date: Tue, 12 Nov 2019 22:02:42 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1573596162.88.0.90248154053.issue38731@roundup.psfhosted.org>


Change by Gregory Shevchenko <gvsheva at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:09:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 22:09:28 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573596568.58.0.27316095388.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> We should not claim to support running our tests in weird syscall sandboxes. There's an infinite number of possible sandboxing configurations, and we can't fix them all.

There is no request to support an "an infinite number of possible sandboxing configurations". Only to skip the test if the syscall fails with EPERM. That sounds reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:16:08 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 22:16:08 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573596968.23.0.44732166758.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Sure, that change on it's own looks small and harmless. My point is that it's a slippery slope. Why is that sandbox configuration important enough to handle? It won't be tested by our CI and no one will know whether they can ever remove the EPERM skipping case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:18:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 22:18:38 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573597118.01.0.73949186367.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Why is that sandbox configuration important enough to handle? It won't be tested by our CI and no one will know whether they can ever remove the EPERM skipping case.

It's just convenient for users who use/test Python in a Linux sandbox.

The fact is that 2 days after you merged the new test, a first user reported a failure. I expect more issues if we don't simply fix the test :-) Sandboxes on Linux are more and more common.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:23:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 22:23:13 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573597393.73.0.849042053223.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I started a thread on python-dev about this issue:
"Pass the Python thread state to internal C functions"
https://mail.python.org/archives/list/python-dev at python.org/thread/PQBGECVGVYFTVDLBYURLCXA3T7IPEHHO/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:23:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2019 22:23:23 +0000
Subject: [issue36710] Pass _PyRuntimeState as an argument rather than using
 the _PyRuntime global variable
In-Reply-To: <1556110680.79.0.127639989845.issue36710@roundup.psfhosted.org>
Message-ID: <1573597403.16.0.479027409524.issue36710@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I started a thread on python-dev about this issue:
"Pass the Python thread state to internal C functions"
https://mail.python.org/archives/list/python-dev at python.org/thread/PQBGECVGVYFTVDLBYURLCXA3T7IPEHHO/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36710>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:28:14 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 22:28:14 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573597694.69.0.539765131565.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

It will be fixed, though, as soon as the user upgrades systemd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:31:00 2019
From: report at bugs.python.org (Jerrod Frost)
Date: Tue, 12 Nov 2019 22:31:00 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1573597860.21.0.298654302599.issue37095@roundup.psfhosted.org>


Jerrod Frost <piroisl33t at gmail.com> added the comment:

Curious about this as well.

----------
nosy: +Jerrod Frost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:37:59 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Nov 2019 22:37:59 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1573598279.76.0.921110098351.issue36375@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

[Belatedly updating this issue with the current status as of March]

Cameron's implementation generally looks good, but there are couple of compatibility/migration questions that we need to consider, as spelled out in the PEP update that added me as BDFL-Delegate: https://github.com/python/peps/pull/946/files

* We need a generic porting guide entry to handle projects that turn out to have been relying on their name *not* being bound in sys.modules. For example, adding this preamble:

    if __name__ == "__main__":
        # To prevent inadvertent double imports, the -m
        # switch in Python 3.9+ defaults to aliasing __main__
        # under the executed module's import name. We actually
        # want the double import, so remove the alias if it exists
        import sys
        _main_module = sys.modules.get(__name__)
        _spec_module = sys.modules.get(__spec__.name)
        if _main_module is _spec_module:
            sys.modules.pop(__spec__.name)

We'd test the above snippet by adding it to the `pdb` module (and reverting the other compatibility changes to that module)

* We need to understand the implications for pickle compatibility, and provide a porting guide snippet, similar to the one above for explicitly requesting the double-import behaviour. For example:

    if __name__ == "__main__":
        # To prevent inadvertent double imports, the -m
        # switch in Python 3.9+ defaults to aliasing __main__
        # under the executed module's import name. We need
        # pickle to use the real module name for objects from
        # __main__ though, so we set the import name here
        _running_as_main = True
        __name__ = __spec__.name

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:42:56 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Nov 2019 22:42:56 +0000
Subject: [issue38723] Pdb._runscript should use io.open_code() instead of
 open()
In-Reply-To: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>
Message-ID: <1573598576.36.0.172152275958.issue38723@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset d593881505c1f4acfd17f41312b27cc898451816 by Steve Dower (jsnklln) in branch 'master':
bpo-38723: Pdb._runscript should use io.open_code() instead of open() (GH-17127)
https://github.com/python/cpython/commit/d593881505c1f4acfd17f41312b27cc898451816


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38723>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:47:40 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Nov 2019 22:47:40 +0000
Subject: [issue38782] Convert importlib.abc to use typing.Protocol
Message-ID: <1573598860.27.0.897323663705.issue38782@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

Now that typing.Protocol exists we should convert the ABCs in importlib over to protocols as the import system functions off of structural typing and not nominal typing.

----------
components: Library (Lib)
messages: 356501
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Convert importlib.abc to use typing.Protocol
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38782>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:48:48 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 22:48:48 +0000
Subject: [issue38723] Pdb._runscript should use io.open_code() instead of
 open()
In-Reply-To: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>
Message-ID: <1573598928.66.0.981042257618.issue38723@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16645
pull_request: https://github.com/python/cpython/pull/17135

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38723>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:49:40 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Nov 2019 22:49:40 +0000
Subject: [issue38723] Pdb._runscript should use io.open_code() instead of
 open()
In-Reply-To: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>
Message-ID: <1573598980.65.0.509513068143.issue38723@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks for the PR!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38723>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:51:45 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 22:51:45 +0000
Subject: [issue27805] io.open('/dev/stdout',
 'a') raises OSError with errno=ESPIPE
In-Reply-To: <1471637472.92.0.246311076418.issue27805@psf.upfronthosting.co.za>
Message-ID: <1573599105.13.0.622795619583.issue27805@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 74fa9f723f700a342e582b5ad4b51a2c4801cd1c by Benjamin Peterson in branch 'master':
closes bpo-27805: Ignore ESPIPE in initializing seek of append-mode files. (GH-17112)
https://github.com/python/cpython/commit/74fa9f723f700a342e582b5ad4b51a2c4801cd1c


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27805>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:56:17 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 22:56:17 +0000
Subject: [issue27805] io.open('/dev/stdout',
 'a') raises OSError with errno=ESPIPE
In-Reply-To: <1471637472.92.0.246311076418.issue27805@psf.upfronthosting.co.za>
Message-ID: <1573599377.56.0.662551518607.issue27805@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +16646
pull_request: https://github.com/python/cpython/pull/17136

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27805>
_______________________________________

From report at bugs.python.org  Tue Nov 12 17:57:39 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 22:57:39 +0000
Subject: [issue27805] io.open('/dev/stdout',
 'a') raises OSError with errno=ESPIPE
In-Reply-To: <1471637472.92.0.246311076418.issue27805@psf.upfronthosting.co.za>
Message-ID: <1573599459.76.0.118502537044.issue27805@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +16647
pull_request: https://github.com/python/cpython/pull/17137

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27805>
_______________________________________

From report at bugs.python.org  Tue Nov 12 18:02:14 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Nov 2019 23:02:14 +0000
Subject: [issue38764] Deterministic globbing.
In-Reply-To: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>
Message-ID: <1573599734.13.0.419563287931.issue38764@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Let's not do this, for all the reasons brought up.

----------
nosy: +gvanrossum
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38764>
_______________________________________

From report at bugs.python.org  Tue Nov 12 18:09:11 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Nov 2019 23:09:11 +0000
Subject: [issue38723] Pdb._runscript should use io.open_code() instead of
 open()
In-Reply-To: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>
Message-ID: <1573600151.39.0.0872918529758.issue38723@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0a8e7fde064c8fb6eb8e78752d4bcdab56643065 by Miss Islington (bot) in branch '3.8':
bpo-38723: Pdb._runscript should use io.open_code() instead of open() (GH-17127)
https://github.com/python/cpython/commit/0a8e7fde064c8fb6eb8e78752d4bcdab56643065


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38723>
_______________________________________

From report at bugs.python.org  Tue Nov 12 18:34:51 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 23:34:51 +0000
Subject: [issue27805] io.open('/dev/stdout',
 'a') raises OSError with errno=ESPIPE
In-Reply-To: <1471637472.92.0.246311076418.issue27805@psf.upfronthosting.co.za>
Message-ID: <1573601691.0.0.804179771766.issue27805@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset b8b3e4377ec38c7d64570afabbd0923a51f0666c by Benjamin Peterson in branch '3.7':
[3.7] closes bpo-27805: Ignore ESPIPE in initializing seek of append-mode files. (GH-17137)
https://github.com/python/cpython/commit/b8b3e4377ec38c7d64570afabbd0923a51f0666c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27805>
_______________________________________

From report at bugs.python.org  Tue Nov 12 18:43:40 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Nov 2019 23:43:40 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573602220.35.0.959563736241.issue38738@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Serhiy, thank you for carrying this through, including the backports.

Ready to close?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Tue Nov 12 18:54:27 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Nov 2019 23:54:27 +0000
Subject: [issue27805] io.open('/dev/stdout',
 'a') raises OSError with errno=ESPIPE
In-Reply-To: <1471637472.92.0.246311076418.issue27805@psf.upfronthosting.co.za>
Message-ID: <1573602867.2.0.831854616135.issue27805@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 9788f97bf69230ec6b38a483c90e88828eba9a1b by Benjamin Peterson in branch '3.8':
[3.8] closes bpo-27805: Ignore ESPIPE in initializing seek of append-mode files. (GH-17136)
https://github.com/python/cpython/commit/9788f97bf69230ec6b38a483c90e88828eba9a1b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27805>
_______________________________________

From report at bugs.python.org  Tue Nov 12 19:32:41 2019
From: report at bugs.python.org (Cameron Simpson)
Date: Wed, 13 Nov 2019 00:32:41 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1573605161.25.0.747781671331.issue36375@roundup.psfhosted.org>


Cameron Simpson <cs at cskk.id.au> added the comment:

I want to start with an apology. I have become a little swamped by work and didn't let anyone know I've made little time for this since March.

To my naive eye Nick's snippet looks like it would work for pdb; I became a little stalled there trying to understand how pdb managed the main module.

I totally lack the expertise to address pickle; I've never used it and the long history of feature updates sugests to me that I cannot get a deep enough understanding in a meaningful time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Tue Nov 12 21:33:17 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 02:33:17 +0000
Subject: [issue29302] add contextlib.AsyncExitStack
In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za>
Message-ID: <1573612397.31.0.245021830796.issue29302@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16649
pull_request: https://github.com/python/cpython/pull/17138

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29302>
_______________________________________

From report at bugs.python.org  Tue Nov 12 21:33:17 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 02:33:17 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1573612397.1.0.771755457872.issue26467@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16648
pull_request: https://github.com/python/cpython/pull/17138

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26467>
_______________________________________

From report at bugs.python.org  Tue Nov 12 21:33:34 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Nov 2019 02:33:34 +0000
Subject: [issue29302] add contextlib.AsyncExitStack
In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za>
Message-ID: <1573612414.35.0.801217034478.issue29302@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset d6d6e2aa0249bb661541705335ddbb97a53d64c8 by Benjamin Peterson (Ilya Kulakov) in branch 'master':
Add Ilya Kulakov to Misc/ACKS. (GH-17130)
https://github.com/python/cpython/commit/d6d6e2aa0249bb661541705335ddbb97a53d64c8


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29302>
_______________________________________

From report at bugs.python.org  Tue Nov 12 21:33:34 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Nov 2019 02:33:34 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1573612414.83.0.46246688636.issue26467@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset d6d6e2aa0249bb661541705335ddbb97a53d64c8 by Benjamin Peterson (Ilya Kulakov) in branch 'master':
Add Ilya Kulakov to Misc/ACKS. (GH-17130)
https://github.com/python/cpython/commit/d6d6e2aa0249bb661541705335ddbb97a53d64c8


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26467>
_______________________________________

From report at bugs.python.org  Tue Nov 12 21:40:34 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 02:40:34 +0000
Subject: [issue29302] add contextlib.AsyncExitStack
In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za>
Message-ID: <1573612834.03.0.530075659991.issue29302@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e5125f7b3b88d8d4814ed7bddbd4f34d24d763dd by Miss Islington (bot) in branch '3.8':
Add Ilya Kulakov to Misc/ACKS. (GH-17130)
https://github.com/python/cpython/commit/e5125f7b3b88d8d4814ed7bddbd4f34d24d763dd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29302>
_______________________________________

From report at bugs.python.org  Tue Nov 12 21:40:34 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 02:40:34 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1573612834.22.0.332861336037.issue26467@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e5125f7b3b88d8d4814ed7bddbd4f34d24d763dd by Miss Islington (bot) in branch '3.8':
Add Ilya Kulakov to Misc/ACKS. (GH-17130)
https://github.com/python/cpython/commit/e5125f7b3b88d8d4814ed7bddbd4f34d24d763dd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26467>
_______________________________________

From report at bugs.python.org  Tue Nov 12 22:06:50 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Nov 2019 03:06:50 +0000
Subject: [issue38772] shutil.copytree fail to copy some bytes
In-Reply-To: <1573517330.77.0.396990745191.issue38772@roundup.psfhosted.org>
Message-ID: <1573614410.78.0.745715210712.issue38772@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

This looks much more like a hardware problem than a Python bug.

In the future, please post text instead of images.

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38772>
_______________________________________

From report at bugs.python.org  Wed Nov 13 00:07:53 2019
From: report at bugs.python.org (Cameron Simpson)
Date: Wed, 13 Nov 2019 05:07:53 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1573621673.8.0.596208511197.issue36375@roundup.psfhosted.org>


Cameron Simpson <cs at cskk.id.au> added the comment:

Just a remark about the preamble comment: it reads to me as though PEP499 is a misfeature. Possibly change:

  We actually want the double import, so remove the alias if it exists.

to:

  This module is unusual, and actually wants the double import.
  Therefore we remove the __spec__.name alias if it exists
  so that a subsequent import by name will make a distinct instance.

Verbose, but at least I know the intent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Wed Nov 13 00:15:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Nov 2019 05:15:37 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1573622137.25.0.288039370493.issue4630@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Zackary's patch toggles blinking immediately in editor/shell/output windows, but does not affect the FontSample and numerous dialog entry lines.  I changed the patch to store 'insertofftime' just once, as idleConf.blink_off_time.  This is set the first time a shell or editor is created.

This can be used in a future patch to set the option when other cursor widgets are created. (Trying to update all visible or hidden entry lines is too much work.)  For dialogs created just once, this will be the next time IDLE is started.  Having these blink for the remainder of a session, if used again, should be a minor nuisance compared to blinking in the shell and editors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Wed Nov 13 00:57:24 2019
From: report at bugs.python.org (paul j3)
Date: Wed, 13 Nov 2019 05:57:24 +0000
Subject: [issue38736] argparse: wrong type from get_default when type is set
In-Reply-To: <1573141247.89.0.957889061173.issue38736@roundup.psfhosted.org>
Message-ID: <1573624644.71.0.771457873535.issue38736@roundup.psfhosted.org>


Change by paul j3 <ajipanca at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38736>
_______________________________________

From report at bugs.python.org  Wed Nov 13 01:31:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Nov 2019 06:31:59 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1573626719.61.0.286522533112.issue4630@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My intent is that a followup patch should, for font sample and entry widgets, set insertofftime=0 on creation if not cursor_blink.  A new idleConf.set_cursor_blink(widget), something like the new EditorWindow.update_cursor_blink could be used multiple places.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Wed Nov 13 02:13:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Nov 2019 07:13:37 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1573629217.95.0.742999026107.issue4630@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 9c2844927d15b2d3e21b28d62249dead02b5b597 by Terry Jan Reedy (Zackery Spytz) in branch 'master':
bpo-4630: Add cursor no-blink option for IDLE (GH-16960)
https://github.com/python/cpython/commit/9c2844927d15b2d3e21b28d62249dead02b5b597


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Wed Nov 13 02:15:23 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 07:15:23 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1573629323.1.0.157831729298.issue4630@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16650
pull_request: https://github.com/python/cpython/pull/17141

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Wed Nov 13 02:15:30 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 07:15:30 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1573629330.09.0.988398723221.issue4630@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16651
pull_request: https://github.com/python/cpython/pull/17142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Wed Nov 13 02:34:01 2019
From: report at bugs.python.org (John Liao)
Date: Wed, 13 Nov 2019 07:34:01 +0000
Subject: [issue38783] the window size is bigger than the specific size when
 create a window with a fix size in Windows platform
Message-ID: <1573630441.73.0.71709021905.issue38783@roundup.psfhosted.org>


New submission from John Liao <johnliao52 at gmail.com>:

from tkinter import *

master = Tk()
master.resizable(False, False)
master.geometry("100x100")

master.mainloop()

When using the simple code above to create a fix size window, the actual window client area's size is about 126x126 pixels.

Environment:
Windows 10 Home 64 bit edition, python 3.7.4, tkinter verion 8.4

----------
components: Tkinter
messages: 356519
nosy: johnliao
priority: normal
severity: normal
status: open
title: the window size is bigger than the specific size when create a window with a fix size in Windows platform
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38783>
_______________________________________

From report at bugs.python.org  Wed Nov 13 02:36:46 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 07:36:46 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1573630606.1.0.848390046598.issue4630@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a67bc10e42fa9a077eb4d9d7bd767c3efddbc366 by Miss Islington (bot) in branch '3.8':
bpo-4630: Add cursor no-blink option for IDLE (GH-16960)
https://github.com/python/cpython/commit/a67bc10e42fa9a077eb4d9d7bd767c3efddbc366


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Wed Nov 13 02:37:10 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 07:37:10 +0000
Subject: [issue4630] IDLE: add cursor noblink option
In-Reply-To: <1228982754.08.0.523311497339.issue4630@psf.upfronthosting.co.za>
Message-ID: <1573630630.45.0.752977209809.issue4630@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 753d0c05b39f21d5987d59d7fe8b5a6d721bc22c by Miss Islington (bot) in branch '3.7':
bpo-4630: Add cursor no-blink option for IDLE (GH-16960)
https://github.com/python/cpython/commit/753d0c05b39f21d5987d59d7fe8b5a6d721bc22c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4630>
_______________________________________

From report at bugs.python.org  Wed Nov 13 03:08:43 2019
From: report at bugs.python.org (Johannes Erwerle)
Date: Wed, 13 Nov 2019 08:08:43 +0000
Subject: [issue38784] ip_network does not clear/update the broadcast_address
 cache when the IP address is changed.
Message-ID: <1573632523.63.0.350382995031.issue38784@roundup.psfhosted.org>


New submission from Johannes Erwerle <jo at swagspace.org>:

The ip_network class in the ipaddress module does cache the broadcast_address attribute.
But when the network address is changed the cache is not cleared/updated.

Example:

> from ipaddress import ip_network
> 
> print("------------------------------")
> 
> net = ip_network("10.0.0.0/8")
> print("net", net)
> print("broadcast_address", net.broadcast_address)
> print("increase")
> net.network_address += 2**24
> print("net", net)
> print("net.broadcast_address", net.broadcast_address)
>
> print("------------------------------")
>
> net2 = ip_network("10.0.0.0/8")
> print("net2", net2)
> print("no call to broadcast_address")
> print("increase")
> net2.network_address += 2**24
> print("net2", net2)
> print("net2.broadcast_address", net2.broadcast_address)

----------
messages: 356522
nosy: 992jo
priority: normal
severity: normal
status: open
title: ip_network does not clear/update the broadcast_address cache when  the IP address is changed.
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38784>
_______________________________________

From report at bugs.python.org  Wed Nov 13 03:09:07 2019
From: report at bugs.python.org (Johannes Erwerle)
Date: Wed, 13 Nov 2019 08:09:07 +0000
Subject: [issue38784] ip_network does not clear/update the broadcast_address
 cache when the IP address is changed.
In-Reply-To: <1573632523.63.0.350382995031.issue38784@roundup.psfhosted.org>
Message-ID: <1573632547.88.0.316022277045.issue38784@roundup.psfhosted.org>


Change by Johannes Erwerle <jo at swagspace.org>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38784>
_______________________________________

From report at bugs.python.org  Wed Nov 13 03:22:57 2019
From: report at bugs.python.org (Johannes Erwerle)
Date: Wed, 13 Nov 2019 08:22:57 +0000
Subject: [issue38784] ip_network does not clear/update the broadcast_address
 cache when network_address is changed.
In-Reply-To: <1573632523.63.0.350382995031.issue38784@roundup.psfhosted.org>
Message-ID: <1573633377.93.0.697894607002.issue38784@roundup.psfhosted.org>


Change by Johannes Erwerle <jo at swagspace.org>:


----------
title: ip_network does not clear/update the broadcast_address cache when  the IP address is changed. -> ip_network does not clear/update the broadcast_address cache when  network_address is changed.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38784>
_______________________________________

From report at bugs.python.org  Wed Nov 13 03:34:10 2019
From: report at bugs.python.org (Alex)
Date: Wed, 13 Nov 2019 08:34:10 +0000
Subject: [issue38785] Segmentation fault in asyncio
Message-ID: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>


New submission from Alex <alekskayunov at yandex.ru>:

Get Segmentation fault on run script in attachment.

----------
components: asyncio
files: scratch_15.py
messages: 356523
nosy: akayunov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Segmentation fault in asyncio
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48712/scratch_15.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 03:47:31 2019
From: report at bugs.python.org (Alex)
Date: Wed, 13 Nov 2019 08:47:31 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573634851.14.0.455066915952.issue38785@roundup.psfhosted.org>


Alex <alekskayunov at yandex.ru> added the comment:

Get seg fault on running script in attachment:

root at fake:/opt/securisync/be# python3.7 scratch_15.py
In tratata before
In tratata2 before
Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 04:30:19 2019
From: report at bugs.python.org (Jackson Riley)
Date: Wed, 13 Nov 2019 09:30:19 +0000
Subject: [issue34716] MagicMock.__divmod__ should return a pair
In-Reply-To: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>
Message-ID: <1573637419.35.0.375879202244.issue34716@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

On second thoughts, perhaps option 2 is best (more in keeping with the usual behaviour of MagicMock).
Alternatively, could I propose a fourth option:

4. Change the behaviour of MagicMock more generally such that trying to unpack a MagicMock instance into two variables, for example, would assign a new MagicMock instance to each.

This would fix this issue and also seems like a sensible thing for MagicMock in general. I may be missing something/this may not be easy to set-up, I don't know!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34716>
_______________________________________

From report at bugs.python.org  Wed Nov 13 05:20:52 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Nov 2019 10:20:52 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573640452.42.0.287348011536.issue38785@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks for the report!
I would say that deriving from the future class without calling super().__init__() is an error.
After fixing this the snippet raises expected "RuntimeError: yield was used instead of yield from in task" error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 05:36:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Nov 2019 10:36:54 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573641414.06.0.135171195281.issue38785@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The crash occurs in _asyncio_Future_get_loop():

(gdb) frame
#0  0x00007fffea2fe689 in _Py_INCREF (op=0x0) at ./Include/object.h:459
459	    op->ob_refcnt++;

(gdb) up
#1  0x00007fffea301b14 in _asyncio_Future_get_loop_impl (self=0x7fffea2615f0)
    at /home/vstinner/python/master/Modules/_asynciomodule.c:1094
1094	    Py_INCREF(self->fut_loop);

(gdb) p self->fut_loop
$1 = 0x0

(gdb) where
#0  0x00007fffea2fe689 in _Py_INCREF (op=0x0) at ./Include/object.h:459
#1  0x00007fffea301b14 in _asyncio_Future_get_loop_impl (self=0x7fffea2615f0)
    at /home/vstinner/python/master/Modules/_asynciomodule.c:1094
#2  0x00007fffea2fef01 in _asyncio_Future_get_loop (self=0x7fffea2615f0, 
    _unused_ignored=0x0)
    at /home/vstinner/python/master/Modules/clinic/_asynciomodule.c.h:252
#3  0x0000000000645364 in cfunction_vectorcall_NOARGS (
    func=<built-in method get_loop of Qwe2 object at remote 0x7fffea2615f0>, 
    args=0x0, nargsf=0, kwnames=0x0) at Objects/methodobject.c:424
#4  0x000000000042f8d1 in _PyObject_VectorcallTstate (tstate=0x81ae00, 
    callable=<built-in method get_loop of Qwe2 object at remote 0x7fffea2615f0>, args=0x0, nargsf=0, kwnames=0x0) at ./Include/cpython/abstract.h:111
#5  0x000000000042f930 in _PyObject_Vectorcall (
    callable=<built-in method get_loop of Qwe2 object at remote 0x7fffea2615f0>, args=0x0, nargsf=0, kwnames=0x0) at ./Include/cpython/abstract.h:120
#6  0x000000000042f988 in _PyObject_CallNoArg (
    func=<built-in method get_loop of Qwe2 object at remote 0x7fffea2615f0>)
    at ./Include/cpython/abstract.h:148
#7  0x000000000042fc57 in PyObject_CallNoArgs (
    func=<built-in method get_loop of Qwe2 object at remote 0x7fffea2615f0>)
    at Objects/call.c:83
#8  0x00007fffea2ffc16 in get_future_loop (
    fut=<Qwe2(value=0) at remote 0x7fffea2615f0>)
--Type <RET> for more, q to quit, c to continue without paging--q
Quit

(gdb) py-bt
Traceback (most recent call first):
  <built-in method get_loop of Qwe2 object at remote 0x7fffea2615f0>
  <built-in method run of Context object at remote 0x7fffea215170>
  File "/home/vstinner/python/master/Lib/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 2641, in _run_once
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 1101, in run_forever
    await waiter
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 621, in run_until_complete
    self.run_forever()
  File "/home/vstinner/python/master/Lib/asyncio/runners.py", line 299, in run
  File "/home/vstinner/python/master/scratch_15.py", line 56, in <module>
    asyncio.run(main())

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 05:44:31 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Nov 2019 10:44:31 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573641871.9.0.339358225463.issue38785@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Looks like get_future_loop() function misses ENSURE_FUTURE_ALIVE macro call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 06:00:46 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 13 Nov 2019 11:00:46 +0000
Subject: [issue38784] ip_network does not clear/update the broadcast_address
 cache when network_address is changed.
In-Reply-To: <1573632523.63.0.350382995031.issue38784@roundup.psfhosted.org>
Message-ID: <1573642846.59.0.810330571667.issue38784@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

All classes in the ipaddress module are designed as immutable.

While it is not documented, you can see __hash__ is overridden.  It means you must not change the object state.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38784>
_______________________________________

From report at bugs.python.org  Wed Nov 13 08:47:00 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 13:47:00 +0000
Subject: [issue38786] Add parsing of https links to pydoc
Message-ID: <1573652820.15.0.63299586441.issue38786@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
components: Library (Lib)
nosy: python273, taleinat
priority: normal
severity: normal
stage: needs patch
status: open
title: Add parsing of https links to pydoc
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38786>
_______________________________________

From report at bugs.python.org  Wed Nov 13 08:47:16 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 13:47:16 +0000
Subject: [issue38786] Add parsing of https links to pydoc
Message-ID: <1573652836.49.0.786396227619.issue38786@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38786>
_______________________________________

From report at bugs.python.org  Wed Nov 13 08:47:19 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 13:47:19 +0000
Subject: [issue38786] Add parsing of https links to pydoc
Message-ID: <1573652839.55.0.83614183577.issue38786@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +16653
pull_request: https://github.com/python/cpython/pull/17143

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38786>
_______________________________________

From report at bugs.python.org  Wed Nov 13 08:47:31 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 13:47:31 +0000
Subject: [issue38786] Add parsing of https links to pydoc
Message-ID: <1573652851.54.0.931585513086.issue38786@roundup.psfhosted.org>


New submission from Tal Einat <taleinat at gmail.com>:

See latest PR, GH-17143.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38786>
_______________________________________

From report at bugs.python.org  Wed Nov 13 08:52:07 2019
From: report at bugs.python.org (Johannes Erwerle)
Date: Wed, 13 Nov 2019 13:52:07 +0000
Subject: [issue38784] ip_network does not clear/update the broadcast_address
 cache when network_address is changed.
In-Reply-To: <1573632523.63.0.350382995031.issue38784@roundup.psfhosted.org>
Message-ID: <1573653127.67.0.209296367149.issue38784@roundup.psfhosted.org>


Johannes Erwerle <jo at swagspace.org> added the comment:

since it hasn't been documented that those classes are all designed to be immutable (and many things work when they are mutable) many people probably use it that way.
Declaring them immutable via the docs now would "break" existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38784>
_______________________________________

From report at bugs.python.org  Wed Nov 13 09:16:39 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 13 Nov 2019 14:16:39 +0000
Subject: [issue38784] ip_network does not clear/update the broadcast_address
 cache when network_address is changed.
In-Reply-To: <1573632523.63.0.350382995031.issue38784@roundup.psfhosted.org>
Message-ID: <1573654599.96.0.582658472858.issue38784@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

It is documented, if you read it carefully.

"Network objects are hashable, so they can be used as keys in dictionaries."

https://docs.python.org/3/library/ipaddress.html#network-objects

"""
An object is hashable if it has a hash value which never changes during its lifetime (it needs a __hash__() method), and can be compared to other objects (it needs an __eq__() method). Hashable objects which compare equal must have the same hash value.
"""

https://docs.python.org/3/glossary.html#term-hashable

Make it mutable is not an option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38784>
_______________________________________

From report at bugs.python.org  Wed Nov 13 09:20:49 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Nov 2019 14:20:49 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573654849.79.0.200652306662.issue38785@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 09:30:40 2019
From: report at bugs.python.org (Marcel Plch)
Date: Wed, 13 Nov 2019 14:30:40 +0000
Subject: [issue38787] PEP 573: Module State Access from C Extension Methods
Message-ID: <1573655440.57.0.563143759574.issue38787@roundup.psfhosted.org>


New submission from Marcel Plch <mplch at redhat.com>:

Currently, there is not way to access per-module state from the methods of types defined in extension modules.

This PEP provides a fix to this issue.

PEP 573 - https://www.python.org/dev/peps/pep-0573/

Reference implementation - https://github.com/Dormouse759/cpython/tree/pep-c-rebase_newer

----------
components: Extension Modules
messages: 356533
nosy: Dormouse759, ncoghlan, petr.viktorin, scoder, terry.reedy
priority: normal
severity: normal
status: open
title: PEP 573: Module State Access from C Extension Methods
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38787>
_______________________________________

From report at bugs.python.org  Wed Nov 13 09:34:10 2019
From: report at bugs.python.org (Marcel Plch)
Date: Wed, 13 Nov 2019 14:34:10 +0000
Subject: [issue38787] PEP 573: Module State Access from C Extension Methods
In-Reply-To: <1573655440.57.0.563143759574.issue38787@roundup.psfhosted.org>
Message-ID: <1573655650.02.0.408621036772.issue38787@roundup.psfhosted.org>


Change by Marcel Plch <mplch at redhat.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38787>
_______________________________________

From report at bugs.python.org  Wed Nov 13 09:36:28 2019
From: report at bugs.python.org (Ulrik Haugen)
Date: Wed, 13 Nov 2019 14:36:28 +0000
Subject: [issue38788] Inconsistent documentation of tell/seek on
 textiobase/textiowrapper
Message-ID: <1573655788.2.0.430319826045.issue38788@roundup.psfhosted.org>


New submission from Ulrik Haugen <qha at lysator.liu.se>:

The class hierarchy suggests the only tell/seek implementations one
needs to look up are in iobase and those have the semantics i was
expecting:
https://docs.python.org/3.8/library/io.html#class-hierarchy

Plowing on one might discover that there are separate implementations
of tell/seek for textiobase whose documentation probably explains the
unexpected values tell returns.


The documentation for tell available from the help() command still
reflects the semantics i was expecting.

The documentation for seek available from the help() command still
reflects the semantics i was expecting. It does however suggest that
the first argument has been renamed from offset to cookie which the
online documentation has not yet caught up to at:
https://docs.python.org/3.8/library/io.html#io.TextIOBase.seek

The documentation body for seek from the help() command still refers to
offset though there is now no argument of that name.


>>> help(fh.tell)
Help on built-in function tell:

tell() method of _io.TextIOWrapper instance
    Return current stream position.

>>> help(fh.seek)
Help on built-in function seek:

seek(cookie, whence=0, /) method of _io.TextIOWrapper instance
    Change stream position.
    
    Change the stream position to the given byte offset. The offset is
    interpreted relative to the position indicated by whence.  Values
    for whence are:
    
    * 0 -- start of stream (the default); offset should be zero or positive
    * 1 -- current stream position; offset may be negative
    * 2 -- end of stream; offset is usually negative
    
    Return the new absolute position.

----------
components: Library (Lib)
messages: 356534
nosy: qha
priority: normal
severity: normal
status: open
title: Inconsistent documentation of tell/seek on textiobase/textiowrapper
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38788>
_______________________________________

From report at bugs.python.org  Wed Nov 13 10:26:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Nov 2019 15:26:19 +0000
Subject: [issue38738] Fix formatting of True and False
In-Reply-To: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>
Message-ID: <1573658779.02.0.342602641376.issue38738@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks Vinay, Kyle and Terry for your review!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38738>
_______________________________________

From report at bugs.python.org  Wed Nov 13 10:27:56 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Nov 2019 15:27:56 +0000
Subject: [issue38786] Add parsing of https links to pydoc
In-Reply-To: <1573652851.54.0.931585513086.issue38786@roundup.psfhosted.org>
Message-ID: <1573658876.73.0.0670461784397.issue38786@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -16652

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38786>
_______________________________________

From report at bugs.python.org  Wed Nov 13 10:59:15 2019
From: report at bugs.python.org (Simon Friedberger)
Date: Wed, 13 Nov 2019 15:59:15 +0000
Subject: [issue38789] difflib lacks a way to check if results are empty
Message-ID: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>


New submission from Simon Friedberger <simon.nov2019 at a-oben.org>:

It seems there is no easy way to use difflib to show a diff but only when there actually are differences. The SequenceMatcher has ratio() but that isn't really available through Differ or any of the convenience functions. Vice versa, when using SequenceMatcher the pretty display is not available.

----------
components: Library (Lib)
messages: 356536
nosy: simon_
priority: normal
severity: normal
status: open
title: difflib lacks a way to check if results are empty
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38789>
_______________________________________

From report at bugs.python.org  Wed Nov 13 10:59:24 2019
From: report at bugs.python.org (Simon Friedberger)
Date: Wed, 13 Nov 2019 15:59:24 +0000
Subject: [issue38789] difflib lacks a way to check if results are empty
In-Reply-To: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>
Message-ID: <1573660764.5.0.943168864254.issue38789@roundup.psfhosted.org>


Change by Simon Friedberger <simon.nov2019 at a-oben.org>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38789>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:03:00 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 16:03:00 +0000
Subject: [issue38517] functools.cached_property should support partial
 functions and partialmethod's
In-Reply-To: <1571404713.25.0.542654366975.issue38517@roundup.psfhosted.org>
Message-ID: <1573660980.93.0.112251035636.issue38517@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Note that it is already possible, though awkward, to create cached properties dynamically. Using the example from PR GH-16838:

class ProcNet:
    pass

for proto in ('icmp', 'icmp6', 'raw', 'raw6', 'tcp', 'tcp6', 'udp', 'udp6', 'udplite', 'udplite6'):
    @cached_property
    def prop(self, *, proto=proto):
        with open(os.path.join("/proc/net", proto)) as file:
            return file.read()
    setattr(ProcNet, proto, prop)
    prop.__set_name__(ProcNet, proto)

IMO this is good enough, considering that this is all pretty much required for dynamically creating normal (uncached) properties and other types of descriptors.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38517>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:10:19 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 16:10:19 +0000
Subject: [issue38517] functools.cached_property should support partial
 functions and partialmethod's
In-Reply-To: <1571404713.25.0.542654366975.issue38517@roundup.psfhosted.org>
Message-ID: <1573661419.5.0.689600428148.issue38517@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

According to issue38524, this should be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38517>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:10:31 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 16:10:31 +0000
Subject: [issue38517] functools.cached_property should support partial
 functions and partialmethod's
In-Reply-To: <1571404713.25.0.542654366975.issue38517@roundup.psfhosted.org>
Message-ID: <1573661431.72.0.532209575856.issue38517@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38517>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:11:48 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 16:11:48 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1573661508.11.0.458320208396.issue38524@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

I agree with Nick: While possible, this would be unnecessarily confusing.

As Serhiy wrote, the proper way to address the situation seems to be improving the documentation. A PR would be welcome!

----------
keywords: +easy
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:14:20 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 16:14:20 +0000
Subject: [issue38786] Add parsing of https links to pydoc
In-Reply-To: <1573652851.54.0.931585513086.issue38786@roundup.psfhosted.org>
Message-ID: <1573661660.16.0.606323158996.issue38786@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 61289d436661025a3111065482275d49a4850b8d by Tal Einat (Kirill) in branch 'master':
bpo-38786: Add parsing of https links to pydoc (GH-17143)
https://github.com/python/cpython/commit/61289d436661025a3111065482275d49a4850b8d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38786>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:14:59 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 16:14:59 +0000
Subject: [issue38786] Add parsing of https links to pydoc
In-Reply-To: <1573652851.54.0.931585513086.issue38786@roundup.psfhosted.org>
Message-ID: <1573661699.19.0.737843983076.issue38786@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for bringing this up and making the PR, python273!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38786>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:15:07 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 16:15:07 +0000
Subject: [issue38786] Add parsing of https links to pydoc
In-Reply-To: <1573652851.54.0.931585513086.issue38786@roundup.psfhosted.org>
Message-ID: <1573661707.67.0.218684102109.issue38786@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38786>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:42:20 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Nov 2019 16:42:20 +0000
Subject: [issue37564] ArgumentParser should support bool type according to
 truth values
In-Reply-To: <1562857832.91.0.995710130518.issue37564@roundup.psfhosted.org>
Message-ID: <1573663340.41.0.764783516248.issue37564@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37564>
_______________________________________

From report at bugs.python.org  Wed Nov 13 11:42:36 2019
From: report at bugs.python.org (Alex)
Date: Wed, 13 Nov 2019 16:42:36 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1573663356.79.0.79298917535.issue25866@roundup.psfhosted.org>


Alex <alexpclarkson at gmail.com> added the comment:

Hi, I've taken a look at these suggestions and the documentation and I've posted a patch to get things moving :)

A couple of points about the suggested changes that I haven't included in the patch:

1) I think changing the documentation for __dir__() to say it can return an iterable needs some discussion.

The documentation also says:
"The ``__dir__`` function should accept no arguments, and return a list of strings that represents the names accessible on module. If present, this function overrides the standard :func:`dir` search on a module."
And this should definitely be updated from "list of strings" to either "sequence of strings" or "iterable of strings".

However, I'm not sure about updating docs to include "accidental" functionality - looking at the testing, news, and documentation from commit https://github.com/python/cpython/commit/3bbb72265411585e64a5d2ccb5ba51763f20e311 the intention was to allow __dir__ to return a sequence.

I think updating the docs to say __dir__ should return an iterator would be a separate issue which would also include test enchancements, so I've left that change out of my patch and I've just corrected the line I've quoted above.

2) > The docs still say that the ABCs are in `collections` rather than `collections.abc`.

I couldn't find an instance of this, it's probably been corrected at some point.

Any thoughts on the above, the other suggestions, or the patch?

----------
keywords: +patch
nosy: +alclarks
Added file: https://bugs.python.org/file48713/issue25866.v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Wed Nov 13 12:55:38 2019
From: report at bugs.python.org (Jake Tesler)
Date: Wed, 13 Nov 2019 17:55:38 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1573667738.64.0.457683853783.issue38707@roundup.psfhosted.org>


Jake Tesler <jake.tesler at gmail.com> added the comment:

PR was updated with tests and is ready for core developer review and then the merge to cpython:master. After that (if I understand correctly) a backport will automatically get picked into the 3.8 branch if there aren't any conflicts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Wed Nov 13 12:59:08 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 13 Nov 2019 17:59:08 +0000
Subject: [issue34716] MagicMock.__divmod__ should return a pair
In-Reply-To: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>
Message-ID: <1573667948.07.0.953764491591.issue34716@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Yes, this is impossible using only "universal Python" (independent of implementation). Though, of course, it's possible in CPython if you analyze the source code (or AST) and count the targets on the left side.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34716>
_______________________________________

From report at bugs.python.org  Wed Nov 13 13:11:11 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 13 Nov 2019 18:11:11 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573668671.16.0.893969470092.issue38758@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Have you read https://github.com/ericvsmith/dataclasses/issues/3?

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Wed Nov 13 13:16:34 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Nov 2019 18:16:34 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1573668994.55.0.71593210422.issue38686@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Wed Nov 13 13:59:19 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Nov 2019 18:59:19 +0000
Subject: [issue38744] python 3.8 hang in multiprocessing.Pool() locking on
 FreeBSD
In-Reply-To: <1573225244.96.0.151354887911.issue38744@roundup.psfhosted.org>
Message-ID: <1573671559.26.0.978730061355.issue38744@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

What happens if you instead write:

with Pool() as pool:
    pool.map(sleep, [0.01] * 10)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38744>
_______________________________________

From report at bugs.python.org  Wed Nov 13 14:05:34 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Nov 2019 19:05:34 +0000
Subject: [issue38744] python 3.8 hang in multiprocessing.Pool() locking on
 FreeBSD
In-Reply-To: <1573225244.96.0.151354887911.issue38744@roundup.psfhosted.org>
Message-ID: <1573671934.8.0.499262463582.issue38744@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38744>
_______________________________________

From report at bugs.python.org  Wed Nov 13 14:14:18 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Wed, 13 Nov 2019 19:14:18 +0000
Subject: [issue38721] modulefinder should use import hooks properly
In-Reply-To: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>
Message-ID: <1573672458.06.0.508662353253.issue38721@roundup.psfhosted.org>


Dominic Littlewood <11dlittlewood at gmail.com> added the comment:

Okay, I've started putting together a proper PR, and I've had some thoughts.


There's a useful script at the bottom of the importlib documentation that readers should consult. This can be used to correctly find the spec for a module, and therefore the loader. (AddPackagePath and ReplacePackage are not needed, and should be deprecated.) For modules already on sys.path, the loader can be identified from module.__loader__.

If the loader is an InspectLoader, the code can be retrieved and examined to see what is imported. (Remember to check whether None is returned.) If not, we will assume nothing is imported - which is what modulefinder currently does with extension modules.

Since run_script takes a file path rather than a module name, it will have to find the appropriate loader for the task. This will be a simple choice between SourceFileLoader and SourcelessFileLoader, depending on what kind of file is being used.


It is also possible to use functions in importlib._bootstrap instead.
This enhancement would indirectly cause open_code to be used properly, so the bug I originally posted is redundant.

----------
title: modulefinder should use io.open_code() instead of open() -> modulefinder should use import hooks properly
type: security -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Wed Nov 13 14:32:00 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Nov 2019 19:32:00 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573673520.45.0.295387839329.issue38453@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

My latest push to PR 16967 is a significant change to what ntpath.realpath will return for broken symlinks, but I think it's the right change.

Basically, if the OS fully resolves the path, great! We'll return that (and handle \\?\ stripping)

If the OS doesn't, we'll assume it's a broken link and try and read the link target from the path. Most of the time, we'll get "not a link", but if it succeeds then we'll return here. For absolute links, we'll return it. For relative symlinks, we'll join with the parent directory. For relative anything-else, we'll return the path to the link itself.

If we can't read a link (most likely), then we'll work up the path doing the same thing. Once we successfully get further than the original path, we'll join the unprocessed tail on and return without attempting to resolve anything more (assuming that the OS would have done it earlier if it was possible).

So if you look at the changed test_ntpath.py you'll see the different results (the test_shutil.py changes are mainly to avoid long/short name comparison failures when realpath() fixes them, by putting the test files in the actual test directory instead of global TEMP).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Wed Nov 13 14:33:48 2019
From: report at bugs.python.org (Jason Killen)
Date: Wed, 13 Nov 2019 19:33:48 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1573673628.87.0.983113642282.issue38722@roundup.psfhosted.org>


Jason Killen <jsnklln at gmail.com> added the comment:

I'll plan on tackling this one.  I already did pdb.

----------
nosy: +Jason.Killen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Wed Nov 13 14:35:50 2019
From: report at bugs.python.org (Jason Killen)
Date: Wed, 13 Nov 2019 19:35:50 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573673750.04.0.49581632567.issue38724@roundup.psfhosted.org>


Change by Jason Killen <jsnklln at gmail.com>:


----------
nosy: +Jason.Killen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Wed Nov 13 14:48:21 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 19:48:21 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573674501.29.0.402905095571.issue38724@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

I agree that this could be nice. A PR (with tests!) would be welcome!

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Wed Nov 13 15:18:30 2019
From: report at bugs.python.org (Dmitry Marakasov)
Date: Wed, 13 Nov 2019 20:18:30 +0000
Subject: [issue38744] python 3.8 hang in multiprocessing.Pool() locking on
 FreeBSD
In-Reply-To: <1573225244.96.0.151354887911.issue38744@roundup.psfhosted.org>
Message-ID: <1573676310.51.0.967600520582.issue38744@roundup.psfhosted.org>


Dmitry Marakasov <amdmi3 at amdmi3.ru> added the comment:

> What happens if you instead write:

It survived more than 4000 runs, it looks like it doesn't experience the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38744>
_______________________________________

From report at bugs.python.org  Wed Nov 13 15:30:37 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 20:30:37 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573677037.92.0.560122489536.issue38724@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Wed Nov 13 15:48:49 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 13 Nov 2019 20:48:49 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1573678129.6.0.963214144474.issue25866@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Wed Nov 13 15:49:16 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 13 Nov 2019 20:49:16 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1573678156.04.0.320591714406.issue11354@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:04:40 2019
From: report at bugs.python.org (Anthony)
Date: Wed, 13 Nov 2019 21:04:40 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573668671.16.0.893969470092.issue38758@roundup.psfhosted.org>
Message-ID: <CAHXb=4JX4L7BMDXnxKQyxr7U1e6-tDiEZyCdzJAW1k1P4eRT9g@mail.gmail.com>


Anthony <anthonysarkis at gmail.com> added the comment:

Thanks for adding it, I read it now.

And sorry to back track a moment - I love the idea of @dataclass and I can
only imagine how must work it was to implement as I am only a beginner.

I'm looking at this primarily from the narrow view point of a user - not so
much understanding the backdrop of how it can actually work.
But I still think this is worth considering as I think this is common
pattern based on this logic:

When using the default construction method it seems reasonable to pass a
default, such as a List.
Because
def __init__(x=[]):
  self.x = x
Is the cleanest way I can think of to write that.
In this new context, if x: list = [] is the cleanest way to write it.
Therefore it should do that, however it is actually implemented.

Let's imagine for a moment that @dataclass becomes the default way of
constructing classes in python.
Do we really want such a common case to require such verbose language?

Looking at Guido's first comment on this, I think that detection mechanism
is what I would expect to happen. To illustrate verbosely:
https://gist.github.com/swirlingsand/d59d01ef79c5ee93f430ed324199bc65
I clearly misunderstood the way classes get passed by default.
I continue to believe that defining it in the argument should be equal to
defining it after. (if there are no other context items present).

>From a beginners perspective here, It would appear that in a sense the
default init is actually "silently failing" in that the expected (because
of the two instances not being equal to each other as shown in L10 above)
isolation is not happening.
In a sense then, @dataclass is turning that silent "failure" into a
ValueError which is actually better.

What about something like this:
https://gist.github.com/swirlingsand/2494bc482902fada2248698f7b8af61e
If the common case is for it to be None, then this doesn't fire so there's
no cost.
If it's a common default then it handles it as expected.
If it's not found it raises a ValueError like before, so there's no loss or
harm.
A handful of defaults here may cover 80% of cases and the 20% can continue
to be handled by ValueError
In a project with 40 classes with 10 defaults per class that's 400 lines of
code that look like:
[]
instead of
field(default_factory=lambda: [])
(or {} etc.)

Issue #3 has many comments around copying, but that's not my concern, I'm
just talking about the defaults where the attribute is not provided at all
(ie is None).

I did the above example in regular python since I don't know enough about
how @dataclass is implemented, but it seems reasonable that if it can work
in normal python there should be a way to say augment operation() on line
21 with field()

On Wed, Nov 13, 2019 at 10:11 AM Vedran ?a?i? <report at bugs.python.org>
wrote:

>
> Vedran ?a?i? <vedgar at gmail.com> added the comment:
>
> Have you read https://github.com/ericvsmith/dataclasses/issues/3?
>
> ----------
> nosy: +veky
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38758>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:13:31 2019
From: report at bugs.python.org (Anthony)
Date: Wed, 13 Nov 2019 21:13:31 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <CAHXb=4JX4L7BMDXnxKQyxr7U1e6-tDiEZyCdzJAW1k1P4eRT9g@mail.gmail.com>
Message-ID: <CAHXb=4LUa+dFtKGc4XO7tj10GRWkaD_Hr9=tCjA=CP2cYqpQBw@mail.gmail.com>


Anthony <anthonysarkis at gmail.com> added the comment:

To clarify,
A major assumption I'm making is that the default is empty, or the
"copying" is handled as some separately coupled concept.
A motivation here is wanting to do operations like .append() that depend on
the object existing.

On Wed, Nov 13, 2019 at 1:04 PM Anthony Sarkis <anthonysarkis at gmail.com>
wrote:

> Thanks for adding it, I read it now.
>
> And sorry to back track a moment - I love the idea of @dataclass and I can
> only imagine how must work it was to implement as I am only a beginner.
>
> I'm looking at this primarily from the narrow view point of a user - not
> so much understanding the backdrop of how it can actually work.
> But I still think this is worth considering as I think this is common
> pattern based on this logic:
>
> When using the default construction method it seems reasonable to pass a
> default, such as a List.
> Because
> def __init__(x=[]):
>   self.x = x
> Is the cleanest way I can think of to write that.
> In this new context, if x: list = [] is the cleanest way to write it.
> Therefore it should do that, however it is actually implemented.
>
> Let's imagine for a moment that @dataclass becomes the default way of
> constructing classes in python.
> Do we really want such a common case to require such verbose language?
>
> Looking at Guido's first comment on this, I think that detection mechanism
> is what I would expect to happen. To illustrate verbosely:
> https://gist.github.com/swirlingsand/d59d01ef79c5ee93f430ed324199bc65
> I clearly misunderstood the way classes get passed by default.
> I continue to believe that defining it in the argument should be equal to
> defining it after. (if there are no other context items present).
>
> From a beginners perspective here, It would appear that in a sense the
> default init is actually "silently failing" in that the expected (because
> of the two instances not being equal to each other as shown in L10 above)
> isolation is not happening.
> In a sense then, @dataclass is turning that silent "failure" into a
> ValueError which is actually better.
>
> What about something like this:
> https://gist.github.com/swirlingsand/2494bc482902fada2248698f7b8af61e
> If the common case is for it to be None, then this doesn't fire so there's
> no cost.
> If it's a common default then it handles it as expected.
> If it's not found it raises a ValueError like before, so there's no loss
> or harm.
> A handful of defaults here may cover 80% of cases and the 20% can continue
> to be handled by ValueError
> In a project with 40 classes with 10 defaults per class that's 400 lines
> of code that look like:
> []
> instead of
> field(default_factory=lambda: [])
> (or {} etc.)
>
> Issue #3 has many comments around copying, but that's not my concern, I'm
> just talking about the defaults where the attribute is not provided at all
> (ie is None).
>
> I did the above example in regular python since I don't know enough about
> how @dataclass is implemented, but it seems reasonable that if it can work
> in normal python there should be a way to say augment operation() on line
> 21 with field()
>
>
>
>
>
>
> On Wed, Nov 13, 2019 at 10:11 AM Vedran ?a?i? <report at bugs.python.org>
> wrote:
>
>>
>> Vedran ?a?i? <vedgar at gmail.com> added the comment:
>>
>> Have you read https://github.com/ericvsmith/dataclasses/issues/3?
>>
>> ----------
>> nosy: +veky
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <https://bugs.python.org/issue38758>
>> _______________________________________
>>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:14:32 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 13 Nov 2019 21:14:32 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573679672.63.0.00239945391286.issue38758@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

The problem is that what you wrote isn't what most people want. Here's your example without dataclasses. I've added an "append_to_x" method, which does the obvious thing:


>>> class C:
...   def __init__(self, x=[]):
...      self.x = x
...  
...   def append_to_x(self, val):
...     self.x.append(val)
... 

Now create two objects, and inspect their "x" properties:
>>> a = C()
>>> b = C()
>>> a.x
[]
>>> b.x
[]

So far so good. Now append something to "a.x":
>>> a.append_to_x(10)
>>> a.x
[10]

And notice that "b.x" changes, too:
>>> b.x
[10]

So the naive behavior isn't what you want. dataclasses is trying to prevent you from doing this.

You should look at "mutable defaults", perhaps starting here (from a random Google search): https://blog.florimond.dev/python-mutable-defaults-are-the-source-of-all-evil

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:21:13 2019
From: report at bugs.python.org (Anthony)
Date: Wed, 13 Nov 2019 21:21:13 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573680073.92.0.636531994058.issue38758@roundup.psfhosted.org>


Anthony <anthonysarkis at gmail.com> added the comment:

Hey Eric, I think our emails crossed in the wind, please see my comment that includes (as a sub component) a similar idea to what's proposed in the article you linked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:32:32 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 13 Nov 2019 21:32:32 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573680752.01.0.86514300708.issue38692@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

We can merge this PR as is (Benjamin, thanks for working on this!), but I think that as soon as we merge it we should do some refactoring and deprecations.

The child watchers API has to go. It's confusing, painful to use, it's not compatible with third-party event loops. It increases the API surface without providing us with enough benefits.

What I propose:

* merge this watcher and try to use it as the default on modern Linuxes.  We don't document it.

* deprecate add_child_watcher and all child watcher classes in 3.9. Aim for removal in 3.11.  

In 3.9 we will use kqueue / pidfd / threads / winapis -- whatever is available, but we never use SIGCHLD by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:37:15 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 21:37:15 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573681035.48.0.237272620073.issue38785@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dad6be5ffe48beb74fad78cf758b886afddc7aed by Miss Islington (bot) (Andrew Svetlov) in branch 'master':
bpo-38785: Prevent asyncio from crashing  (GH-17144)
https://github.com/python/cpython/commit/dad6be5ffe48beb74fad78cf758b886afddc7aed


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:37:19 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Nov 2019 21:37:19 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1573681039.2.0.778396843321.issue11354@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Do we have examples of real world APIs that actually need this functionality? Offhand, I don't recall having worked with any command-line tool that would accept "at least two but no more than four filenames" for example.

Given that this isn't trivial to implement, we should take a moment to evaluate whether users actually need it.  We had eight years since the original proposal without anyone chiming in to say, "yes, I need this".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:37:16 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 21:37:16 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573681036.56.0.524395484979.issue38785@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16656
pull_request: https://github.com/python/cpython/pull/17147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:37:23 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 21:37:23 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573681043.27.0.933064267682.issue38785@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16657
pull_request: https://github.com/python/cpython/pull/17148

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:54:58 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 21:54:58 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573682098.82.0.89752577709.issue38785@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 87b4d3994e4f81d6e39a5e86c1b7040df065ea37 by Miss Islington (bot) in branch '3.7':
bpo-38785: Prevent asyncio from crashing  (GH-17144)
https://github.com/python/cpython/commit/87b4d3994e4f81d6e39a5e86c1b7040df065ea37


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:54:59 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Nov 2019 21:54:59 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573682099.57.0.684118494036.issue38785@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 694c03fabb5cf3df0102cc317670a10fc39c6786 by Miss Islington (bot) in branch '3.8':
bpo-38785: Prevent asyncio from crashing  (GH-17144)
https://github.com/python/cpython/commit/694c03fabb5cf3df0102cc317670a10fc39c6786


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:55:19 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Nov 2019 21:55:19 +0000
Subject: [issue38785] Segmentation fault in asyncio
In-Reply-To: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>
Message-ID: <1573682119.62.0.906569234465.issue38785@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38785>
_______________________________________

From report at bugs.python.org  Wed Nov 13 16:57:18 2019
From: report at bugs.python.org (Jason Killen)
Date: Wed, 13 Nov 2019 21:57:18 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573682238.29.0.118296693177.issue38724@roundup.psfhosted.org>


Jason Killen <jsnklln at gmail.com> added the comment:

I think this sounds great and I'll take a crack at it over the next few days.  If anybody wants to jump ahead of me I don't mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Wed Nov 13 17:19:07 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 13 Nov 2019 22:19:07 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573683547.34.0.00353650314433.issue38758@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not sure what you're proposing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Wed Nov 13 17:20:29 2019
From: report at bugs.python.org (Daniel Andersson)
Date: Wed, 13 Nov 2019 22:20:29 +0000
Subject: [issue38781] Clear buffer in MemoryHandler flush
In-Reply-To: <1573594992.8.0.415095728854.issue38781@roundup.psfhosted.org>
Message-ID: <1573683629.57.0.0762645438079.issue38781@roundup.psfhosted.org>


Daniel Andersson <daniel.4ndersson at gmail.com> added the comment:

The suggested change has been merged. I'm closing this issue. Thank you Vinay Sajip for reviewing.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38781>
_______________________________________

From report at bugs.python.org  Wed Nov 13 17:27:08 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Nov 2019 22:27:08 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573684028.5.0.804388754808.issue38724@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 for a more informative repr (like we did with regex match objects).

There are a lot of parameters to subprocess.Popen().  RR is on the right track suggesting that only a small, useful subset of those be included:  args and the return code.  

We could add the *pid* argument as well, but may be no more useful or attractive than the current repr's object id.

The repr should be enclosed in angle brackets because it can't recreate the object.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Wed Nov 13 17:34:24 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Nov 2019 22:34:24 +0000
Subject: [issue38790] test_fcntl failing on macOS CI
Message-ID: <1573684464.1.0.222448542247.issue38790@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

See https://dev.azure.com/Python/cpython/_build/results?buildId=53812&view=ms.vss-test-web.build-test-results-tab

Traceback (most recent call last):
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/unittest/case.py", line 60, in testPartExecutor
    yield
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/unittest/case.py", line 659, in run
    self._callTestMethod(testMethod)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/unittest/case.py", line 616, in _callTestMethod
    method()
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/test/test_fcntl.py", line 149, in test_lockf_exclusive
    p.start()
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/context.py", line 283, in _Popen
    return Popen(process_obj)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'TestFcntl.test_lockf_exclusive.<locals>.try_lockf_on_other_process'

----------
components: Tests, macOS
messages: 356565
nosy: alexandre.vassalotti, ned.deily, ronaldoussoren, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: test_fcntl failing on macOS CI
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38790>
_______________________________________

From report at bugs.python.org  Wed Nov 13 17:54:53 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 13 Nov 2019 22:54:53 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573685693.55.0.389897057051.issue38692@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> We can merge this PR as is (Benjamin, thanks for working on this!), but I think that as soon as we merge it we should do some refactoring and deprecations.

> The child watchers API has to go. It's confusing, painful to use, it's not compatible with third-party event loops. It increases the API surface without providing us with enough benefits.

+1

> In 3.9 we will use kqueue / pidfd / threads / winapis -- whatever is available, but we never use SIGCHLD by default.

IIRC, we don't use SIGCHLD by default at the moment, since ThreadedChildWatcher is the default child watcher. Should we change the default to be the new PidfdChildWatcher for Linux kernels 5.3+ in Python 3.9, and fallback to ThreadedChildWatcher for systems without pidfd_open()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 13 18:36:39 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 13 Nov 2019 23:36:39 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573688199.22.0.246258634868.issue38692@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> > The child watchers API has to go. It's confusing, painful to use, it's not compatible with third-party event loops. It increases the API surface without providing us with enough benefits.

> +1

Also, adding to this, the child watchers are one of the least used components of asyncio's public API. So, I think the deprecation and removal cost will be fairly minimal. See the GitHub code usage (includes exact copies of Lib/asyncio/unix_events.py, so there's some redundancy):

MultiLoopChildWatcher: https://github.com/search?l=Python&q=MultiLoopChildWatcher&type=Code (20 results, just added in 3.8)
ThreadedChildWatcher: https://github.com/search?l=Python&q=ThreadedChildWatcher&type=Code (77 results, default unix child watcher, rarely used explicitly)
FastChildWatcher: https://github.com/search?l=Python&q=FastChildWatcher&type=Code (4,426 results)
SafeChildWatcher: https://github.com/search?l=Python&q=SafeChildWatcher&type=Code (7,007 results)
All of asyncio usage: https://github.com/search?l=Python&q=asyncio&type=Code (599,131 results)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 13 21:04:53 2019
From: report at bugs.python.org (Alexander Mohr)
Date: Thu, 14 Nov 2019 02:04:53 +0000
Subject: [issue38529] Python 3.8 improperly warns about closing properly
 closed streams
In-Reply-To: <1571510429.0.0.996597968813.issue38529@roundup.psfhosted.org>
Message-ID: <1573697093.3.0.759604148203.issue38529@roundup.psfhosted.org>


Change by Alexander Mohr <thehesiod at gmail.com>:


----------
nosy: +thehesiod

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38529>
_______________________________________

From report at bugs.python.org  Wed Nov 13 22:07:48 2019
From: report at bugs.python.org (ysnt27)
Date: Thu, 14 Nov 2019 03:07:48 +0000
Subject: [issue38609] Trashcan mechanism segfault during interpreter
 finalization in Python 3.7.5
In-Reply-To: <1572230692.1.0.462220822628.issue38609@roundup.psfhosted.org>
Message-ID: <1573700868.06.0.0407977339802.issue38609@roundup.psfhosted.org>


ysnt27 <yoshint2012 at gmail.com> added the comment:

Thanks for making the issue clear.

My understanding is that,
all C++ destructors have to check Python interpreter before Py_DECREF,
like this.

``` cplusplus
  ~something() {
    // PyThreadState *_tstate = PyThreadState_GET();
    PyThreadState *_tstate = _PyThreadState_UncheckedGet();
    if (_tstate) {
      Py_DECREF(somelist);
    }
  }
```

Is this right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38609>
_______________________________________

From report at bugs.python.org  Wed Nov 13 22:08:45 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 Nov 2019 03:08:45 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573700925.47.0.452936334684.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks everyone for the reviews. I will go ahead and merge the PR.

Shall we return to #38591 for planning the future of child watching?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 13 22:09:15 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 Nov 2019 03:09:15 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573700955.28.0.431282209861.issue38692@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 3ccdd9b180f9a3f29c8ddc8ad1b331fe8df26519 by Benjamin Peterson in branch 'master':
closes bpo-38692: Add a pidfd child process watcher to asyncio. (GH-17069)
https://github.com/python/cpython/commit/3ccdd9b180f9a3f29c8ddc8ad1b331fe8df26519


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 13 22:19:22 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 14 Nov 2019 03:19:22 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1573701562.46.0.241782603067.issue38630@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

To further elaborate on the creation time solution, the idea in pseudo-code is the following:

class Popen:

    def __init__(self, ...):
        self._execute_child(...)
        try:
            self._ctime = get_create_time(self.pid)
        except ProcessLookupError:
            self._ctime = None

    def send_signal(self, sig):
        if self._ctime is not None:
            if self._ctime != get_create_time(self.pid):
                raise ProecssLookupError("PID has been reused")
        os.kill(self.pid, sig)

Technically there is still a race condition between _execute_child() and get_create_time(), but:

1) the time between the two calls is supposed to be extremely short
2) an OS should not reuse a PID that fast, precisely in order to minimize the chances of such a race condition to occur
3) as a general rule, on most systems PIDs are supposed to be assigned sequentially and wrap around. E.g. on Linux:

~$ for i in $(seq 20); do ps; done | grep ps
3199 pts/0    00:00:00 ps
3200 pts/0    00:00:00 ps
3201 pts/0    00:00:00 ps
3202 pts/0    00:00:00 ps
3203 pts/0    00:00:00 ps
3204 pts/0    00:00:00 ps
3205 pts/0    00:00:00 ps
3207 pts/0    00:00:00 ps
3208 pts/0    00:00:00 ps
3209 pts/0    00:00:00 ps
3210 pts/0    00:00:00 ps
3213 pts/0    00:00:00 ps
3214 pts/0    00:00:00 ps
3215 pts/0    00:00:00 ps
3216 pts/0    00:00:00 ps
3217 pts/0    00:00:00 ps
3218 pts/0    00:00:00 ps
3219 pts/0    00:00:00 ps
3221 pts/0    00:00:00 ps
3223 pts/0    00:00:00 ps

As for Windows, the termination is based on the process handle instead of the PID, so I assume that means Windows is safe in this regard. There was a prior discussion about this actually:
https://bugs.python.org/issue36067#msg336243
Getting process creation time is relatively easy, even though platform-dependent (and should be done in C).
pidfd API would be nicer to use, but it seems it's not portable and relatively recent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Wed Nov 13 23:24:51 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Thu, 14 Nov 2019 04:24:51 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573705491.06.0.737012422431.issue38758@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

It seems to me that what you're missing is that "class declarations" are still perfectly normal executable statements (in most other superficially similar programming languages, they are not). So, when you say

class A:
    b = []

it is actually executed, a new empty list is made, and named A.b. If you then construct a = A(), then a.b is that same object. It must be, you never made any other list in the process. So if you really want a.b to be a _different_ empty list, you have to make it at some point. The most obvious way to do it is just to copy the A.b --- that's why people usually talk about copying.

Your approach is different: it seems to me that you say, if A.b is a list, then make a new empty list, if it is a set, then make a new empty set, and if it is a dict, then make a new empty dict. Not to mention that it feels very weird when having e.g.

class A:
    b = [4]

(-:, it doesn't take into account any other types. Which leads to another your problem, the one of perspective. Lists, sets and dicts are not that "common case" as you seem to think. Yes, they are in the beginners' code -- and that's why current dataclass implementation flags them as errors, since it's quite possible that people who write such things don't actually understand how Python is executed. But specialcasing them to actually do something useful would be the wrong thing to do, since it would incentivize people who should know better, back into using those simple types. I think it is shown in the discussion mentioned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Wed Nov 13 23:25:55 2019
From: report at bugs.python.org (Jonathan Conder)
Date: Thu, 14 Nov 2019 04:25:55 +0000
Subject: [issue38791] readline history file is hard-coded
Message-ID: <1573705555.33.0.800064361597.issue38791@roundup.psfhosted.org>


New submission from Jonathan Conder <jono.conder at gmail.com>:

Other tools such as bash and less allow their history file to be customised with an environment variable. Will add a patch for this in a bit.

This could also be customised using PYTHONSTARTUP, but then the user has to duplicate a bunch of code which is already part of the site module.

----------
components: Library (Lib)
messages: 356573
nosy: jconder
priority: normal
severity: normal
status: open
title: readline history file is hard-coded
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38791>
_______________________________________

From report at bugs.python.org  Wed Nov 13 23:31:35 2019
From: report at bugs.python.org (pmp-p)
Date: Thu, 14 Nov 2019 04:31:35 +0000
Subject: [issue38791] readline history file is hard-coded
In-Reply-To: <1573705555.33.0.800064361597.issue38791@roundup.psfhosted.org>
Message-ID: <1573705895.56.0.572409221152.issue38791@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38791>
_______________________________________

From report at bugs.python.org  Wed Nov 13 23:33:26 2019
From: report at bugs.python.org (pmp-p)
Date: Thu, 14 Nov 2019 04:33:26 +0000
Subject: [issue38791] readline history file is hard-coded
In-Reply-To: <1573705555.33.0.800064361597.issue38791@roundup.psfhosted.org>
Message-ID: <1573706006.3.0.147741572366.issue38791@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38791>
_______________________________________

From report at bugs.python.org  Wed Nov 13 23:44:45 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 14 Nov 2019 04:44:45 +0000
Subject: [issue26389] Expand traceback module API to accept just an exception
 as an argument
In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za>
Message-ID: <1573706685.86.0.975479694434.issue26389@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

> were you interested in continuing with Brett's (and your) suggestion for the API by making the first argument positional-only and the others optional?

Yes, but I currently do not have the time; if someone else want to take over; or if you need to close this issue or corresponding PR for now please feel free to do so. I'll come back to it at some point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26389>
_______________________________________

From report at bugs.python.org  Thu Nov 14 00:02:54 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Nov 2019 05:02:54 +0000
Subject: [issue26389] Expand traceback module API to accept just an exception
 as an argument
In-Reply-To: <1455836350.85.0.0162824201978.issue26389@psf.upfronthosting.co.za>
Message-ID: <1573707774.0.0.749225724853.issue26389@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It would be nice to see this one come to fruition.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26389>
_______________________________________

From report at bugs.python.org  Thu Nov 14 00:04:49 2019
From: report at bugs.python.org (Debi Mishra)
Date: Thu, 14 Nov 2019 05:04:49 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573707889.54.0.411708663362.issue38724@roundup.psfhosted.org>


Debi Mishra <mishradebi31 at gmail.com> added the comment:

Hi @Jason.Killen. I am new to cpython and would like to try this one out. Thank you.

----------
nosy: +mdebi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Thu Nov 14 00:07:00 2019
From: report at bugs.python.org (Jonathan Conder)
Date: Thu, 14 Nov 2019 05:07:00 +0000
Subject: [issue38791] readline history file is hard-coded
In-Reply-To: <1573705555.33.0.800064361597.issue38791@roundup.psfhosted.org>
Message-ID: <1573708020.28.0.442830385121.issue38791@roundup.psfhosted.org>


Change by Jonathan Conder <jono.conder at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38791>
_______________________________________

From report at bugs.python.org  Thu Nov 14 00:12:08 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Nov 2019 05:12:08 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573708328.51.0.204190476897.issue38758@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Vedran and recommend this proposal be rejected.

During training and code review, we spend a lot of time trying to get people to not write code like this.  By making dataclasses behave differently than the rest of language, we would would lose the clear, bright line we have now.  IOW, this would be bug bait.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Thu Nov 14 01:19:11 2019
From: report at bugs.python.org (Anthony)
Date: Thu, 14 Nov 2019 06:19:11 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573712351.52.0.937584121088.issue38758@roundup.psfhosted.org>


Anthony <anthonysarkis at gmail.com> added the comment:

Vedran thank you for the detailed comments.

I want to separate the idea side and implementation:
The idea is having defaults expressed in a way of least surprise and in the least amount of code.

Specifically that 
[1]
makes more sense then 
field(default_factory=lambda: [1])

or more generally that
default
makes more sense then 
field(default_factory=lambda: default)

I agree there's a lot lacking in my example starting point implementation.
Let's not let what's lacking in that implementation distract from the spirit of the idea.

The scope of that example is meat to illustrate creating a default that is of least surprising, specifically that a new instance of a class is isolated.
But I think the point of whether or not the default is isolated feels like a distraction. 

If a motivation for using type annotations is to restrict to reduce errors. To me, "prototyping" defaults by having them declared as soon as possible in the class is a further restriction. I believe that's a reasonable coding practice, and actually a good thing. 

To me this is the current situation, in order to setup a class using @dataclass a user must either:

a) Have a relatively in depth understanding of python. I think proofs of that include both PEP having to have a section justifying that. And that there was such discussion in the issue. 
A point of higher level languages is to nicely abstract lower level APIs, if I have to learn the lower level API in order to use the language it reduces the benefit, and that's really what the points made sound like.

b) Calling two "special" / additional functions and adding a (relatively) large amount of code. I can't think of anything else in python where the default method requires knowing two separate additional functions! Python is all about short, semantically meaningful expressions yet this feels like the total opposite!

If setting up defaults is a common point of error or "bad code" then why not setup the standard library in such a way that it does it right?
ie that a user can specify the default they want and the library sets up the default in the right way.
If that's as a separate object, or a mutable object, either way. The point being that setting up a default should be straightforward.

This is my first attempt at a contribution, even if all it is is highlighting a problem and the "solution" I'm suggesting may be the wrong one. But so far all of comments feel like they are defending a cascade of "not ideal" situations. Let's try actually looking at the root from the user's perspective and how can we improve this!

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Thu Nov 14 01:29:44 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 Nov 2019 06:29:44 +0000
Subject: [issue38758] @dataclass defaults
In-Reply-To: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>
Message-ID: <1573712984.74.0.161214254127.issue38758@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This should not have been an issue but a discussion on python-list or perhaps python-ideas.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________

From report at bugs.python.org  Thu Nov 14 01:37:53 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Nov 2019 06:37:53 +0000
Subject: [issue38789] difflib lacks a way to check if results are empty
In-Reply-To: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>
Message-ID: <1573713473.23.0.435317794652.issue38789@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> tim.peters
nosy: +tim.peters
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38789>
_______________________________________

From report at bugs.python.org  Thu Nov 14 01:47:31 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 14 Nov 2019 06:47:31 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
Message-ID: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

If a KeyboardInterrupt occurs while an IDLE calltip is being displayed,
the calltip will persist until a new calltip event. The calltip should
be removed immediately in this case.

----------
assignee: terry.reedy
components: IDLE
messages: 356580
nosy: ZackerySpytz, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE calltips may not properly close on KeyboardInterrupt
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Nov 14 01:53:19 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 14 Nov 2019 06:53:19 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1573714399.04.0.103520727358.issue38792@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Nov 14 01:56:23 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 14 Nov 2019 06:56:23 +0000
Subject: [issue38791] readline history file is hard-coded
In-Reply-To: <1573705555.33.0.800064361597.issue38791@roundup.psfhosted.org>
Message-ID: <1573714583.56.0.409323545855.issue38791@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

This issue seems like a duplicate of bpo-29779 (which has a pull request).

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38791>
_______________________________________

From report at bugs.python.org  Thu Nov 14 01:58:05 2019
From: report at bugs.python.org (Kafeel Ansari)
Date: Thu, 14 Nov 2019 06:58:05 +0000
Subject: [issue38775] Cloudpickle.py file is crashing due to data type
 incompatibility.
In-Reply-To: <1573552153.69.0.800822929594.issue38775@roundup.psfhosted.org>
Message-ID: <1573714685.81.0.841160507333.issue38775@roundup.psfhosted.org>


Kafeel Ansari <kafeelansari24 at gmail.com> added the comment:

Hi @xtreak ,
Thank you for the reply . Please find below detailed description. 

I was using python 3.8 and installed pyspark 2.4.4 . I encountered error related to cloudpickle file. Please find the attached snapshot. 

I tried to convert the value of co.co_code in cloudpickle.py file (line 132) from bytes to int to check if it is really a issue with cloudpickle file. 

Please let me know if you need more information .

----------
Added file: https://bugs.python.org/file48714/Spark_cloudpickle_error.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38775>
_______________________________________

From report at bugs.python.org  Thu Nov 14 02:35:51 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 14 Nov 2019 07:35:51 +0000
Subject: [issue26353] IDLE: Saving Shell should not add \n
In-Reply-To: <1455314892.8.0.4844402262.issue26353@psf.upfronthosting.co.za>
Message-ID: <1573716951.58.0.0228072595051.issue26353@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Thank you, Terry, for modifying the PR and merging it.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26353>
_______________________________________

From report at bugs.python.org  Thu Nov 14 02:38:01 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 14 Nov 2019 07:38:01 +0000
Subject: [issue17642] IDLE add font resizing hot keys and wheel
In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za>
Message-ID: <1573717081.89.0.037665387623.issue17642@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17642>
_______________________________________

From report at bugs.python.org  Thu Nov 14 02:51:12 2019
From: report at bugs.python.org (Jonathan Conder)
Date: Thu, 14 Nov 2019 07:51:12 +0000
Subject: [issue38791] readline history file is hard-coded
In-Reply-To: <1573705555.33.0.800064361597.issue38791@roundup.psfhosted.org>
Message-ID: <1573717872.93.0.617383955922.issue38791@roundup.psfhosted.org>


Jonathan Conder <jono.conder at gmail.com> added the comment:

I agree. Did a cursory search before posting but missed it somehow

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38791>
_______________________________________

From report at bugs.python.org  Thu Nov 14 02:55:33 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 14 Nov 2019 07:55:33 +0000
Subject: [issue38609] Trashcan mechanism segfault during interpreter
 finalization in Python 3.7.5
In-Reply-To: <1572230692.1.0.462220822628.issue38609@roundup.psfhosted.org>
Message-ID: <1573718133.7.0.56816603906.issue38609@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

You only have to check, using a public API, if you have no control over when C++ objects are destructed. I'd personally try to structure code to make sure that C++ objects owning references to Python objects get destructed before the interpreter is finalised (or release their references). 

The code you mention is not using a public API, Py_IsInitialized <https://docs.python.org/3/c-api/init.html#c.Py_IsInitialized> is a public API that can be used to check if the interpreter is initialised.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38609>
_______________________________________

From report at bugs.python.org  Thu Nov 14 03:30:02 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 14 Nov 2019 08:30:02 +0000
Subject: [issue38591] Deprecate Process Child Watchers
In-Reply-To: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>
Message-ID: <1573720202.88.0.990406187175.issue38591@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I understand that there's *some* overhead associated with spawning a new thread, but from my impression it's not substantial enough to make a significant impact in most cases.

Although I think this still stands to some degree, I will have to rescind the following:

> Each individual instance of threading.Thread is only 64 bytes.

The 64 bytes was measured by `sys.getsizeof(threading.Thread())`, which only provides a surface level assessment. I believe this only includes the size of the reference to the thread object.

In order to get a better estimate, I implemented a custom get_size() function, that recursively adds the size of the object and all unique objects from gc.get_referents()  (ignoring several redundant and/or unnecessary types). For more details, see https://gist.github.com/aeros/632bd035b6f95e89cdf4bb29df970a2a. Feel free to critique it if there are any apparent issues (for the purpose of measuring the size of threads). 

Then, I used this function on three different threads, to figure how much memory was needed for each one:

Python 3.8.0+ (heads/3.8:1d2862a323, Nov  4 2019, 06:59:53) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> from get_size import get_size
>>> a = threading.Thread()
>>> b = threading.Thread()
>>> c = threading.Thread()
>>> get_size(a)
3995
>>> get_size(b)
1469
>>> get_size(c)
1469

1469 bytes seems to be roughly the amount of additional memory required for each new thread, at least on Linux kernel 5.3.8 and Python 3.8. I don't know if this is 100% accurate, but it at least provides an improved estimate over sys.getsizeof().

> But it spawns a new Python thread per process which can be a blocker issue if a server memory is limited. What if you want to spawn 100 processes? Or 1000 processes? What is the memory usage?

>From my understanding, ~1.5KB/thread seems to be quite negligible for most modern equipment. The server's memory would have to be very limited for spawning an additional 1000 threads to be a bottleneck/blocker issue:

Python 3.8.0+ (heads/3.8:1d2862a323, Nov  4 2019, 06:59:53) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> from get_size import get_size
>>> threads = []
>>> for _ in range(1000):
...     th = threading.Thread()
...     threads.append(th)
... 
>>> get_size(threads)
1482435

(~1.5MB)

Victor (or anyone else), in your experience, would the additional ~1.5KB per process be an issue for 99% of production servers? If not, it seems to me like the additional maintenance cost of keeping SafeChildWatcher and FastChildWatcher in asyncio's API wouldn't be worthwhile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38591>
_______________________________________

From report at bugs.python.org  Thu Nov 14 04:16:09 2019
From: report at bugs.python.org (hai shi)
Date: Thu, 14 Nov 2019 09:16:09 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1573722969.79.0.333273871865.issue11354@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Could we close some bpo with a long history? If some user need this feature in future we could reopen it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Thu Nov 14 04:55:20 2019
From: report at bugs.python.org (Ayappan)
Date: Thu, 14 Nov 2019 09:55:20 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1573725320.54.0.87969294354.issue38628@roundup.psfhosted.org>


Ayappan <ayappanec at gmail.com> added the comment:

Any update on this ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Thu Nov 14 05:12:15 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 10:12:15 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1573726335.99.0.908499114669.issue38792@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Nov 14 05:16:42 2019
From: report at bugs.python.org (lutecki)
Date: Thu, 14 Nov 2019 10:16:42 +0000
Subject: [issue38793] pathlib.Path.resolve(strict=False) strips final path
 components
Message-ID: <1573726602.08.0.459408660928.issue38793@roundup.psfhosted.org>


New submission from lutecki <lukasz.matecki at gmail.com>:

When a directory doesn't exist, the resolve() method trims everything except the first component (a doesn't exist here):

import pathlib
p = pathlib.Path(".", "a", "b", "c")
p
WindowsPath('a/b/c')
p.resolve(strict=False)
WindowsPath('C:/Python36/Scripts/a')

I would expect C:/Python36/Scripts/a/b/c
Am I missing something?

----------
components: Windows
messages: 356589
nosy: lutecki, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib.Path.resolve(strict=False) strips final path components
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38793>
_______________________________________

From report at bugs.python.org  Thu Nov 14 05:17:00 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 10:17:00 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1573726620.82.0.928444133109.issue38792@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Hi Zack, thanks for this!

This doesn't go far enough, actually; we should make sure to close the calltip in other cases too, such as restarting the shell or hitting return to running a statement / block.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Nov 14 05:30:39 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Nov 2019 10:30:39 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573727439.51.0.227561528709.issue38724@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Thu Nov 14 05:33:57 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 10:33:57 +0000
Subject: [issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, 
 and \r
In-Reply-To: <1565592773.8.0.657523892243.issue37827@roundup.psfhosted.org>
Message-ID: <1573727637.14.0.311107067911.issue37827@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Note that most of the issues with special characters described in Terry latest comment have been addressed by the fix for issue13153.

Can we continue discussing just properly rendering \r and \b, e.g. as done in PR GH-15211? Let's just decide whether we want this or not.

My main point in favor is that we already have special support for two similar control characters, \n and \t. IMO we should expand this to the other very standardized ones, \r and \b, and perhaps \a ("bell") as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37827>
_______________________________________

From report at bugs.python.org  Thu Nov 14 05:48:55 2019
From: report at bugs.python.org (Harmon)
Date: Thu, 14 Nov 2019 10:48:55 +0000
Subject: [issue38525] Strange reversed dict behavior
In-Reply-To: <1571472052.75.0.136395293008.issue38525@roundup.psfhosted.org>
Message-ID: <1573728535.59.0.749006344425.issue38525@roundup.psfhosted.org>


Change by Harmon <Harmon758 at gmail.com>:


----------
nosy: +Harmon758

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38525>
_______________________________________

From report at bugs.python.org  Thu Nov 14 05:52:49 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 10:52:49 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1573728769.42.0.821230208318.issue38689@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
keywords: +patch
pull_requests: +16661
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/17152

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38689>
_______________________________________

From report at bugs.python.org  Thu Nov 14 05:52:49 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 10:52:49 +0000
Subject: [issue38695] IDLE should restart instead of hanging when subprocess
 exits
In-Reply-To: <1572939577.48.0.797512840286.issue38695@roundup.psfhosted.org>
Message-ID: <1573728769.56.0.920817232061.issue38695@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38695>
_______________________________________

From report at bugs.python.org  Thu Nov 14 06:00:49 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 11:00:49 +0000
Subject: [issue38689] IDLE crashes when KeyError is raised during calltip
 generation
In-Reply-To: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>
Message-ID: <1573729249.57.0.78948243201.issue38689@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

See PR GH-17152 with a fix for the uncaught exception in getargspec().

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38689>
_______________________________________

From report at bugs.python.org  Thu Nov 14 06:08:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 11:08:49 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1573729729.12.0.394332656354.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> To further elaborate on the creation time solution, the idea in pseudo-code is the following: (...)
> Technically there is still a race condition between _execute_child() and get_create_time(), but: (...)

Even if the approach seems to be different, PR 16984 seems to have the same advantages and drawbacks.

PR 16984 rely on the fact that the Linux kernel doesn't use a pid until its parent calls os.waitpid(). Even if the child process completed, the pid remains assigned (and the process status is "zombie").

PR 16984 has the advantage that it reuses existing code which has been battle tested: we are sure that the code is portable and works well.

Whereas get_create_time() will be likely platform specific and will add a little maintenance burden.

I know that PR 16984 is a partial solution (there is still a race condition if waitpid() is called directly, without using the Popen API), but I don't see a strong reason to prefer get_create_time().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Thu Nov 14 06:11:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 11:11:46 +0000
Subject: [issue38591] Deprecate Process Child Watchers
In-Reply-To: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>
Message-ID: <1573729906.34.0.129168248941.issue38591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The 64 bytes was measured by `sys.getsizeof(threading.Thread())`, which only provides a surface level assessment. I believe this only includes the size of the reference to the thread object.

You have to account also for the thread stack size. I suggest to look at RSS memory instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38591>
_______________________________________

From report at bugs.python.org  Thu Nov 14 06:14:24 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 14 Nov 2019 11:14:24 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573730064.51.0.742388500788.issue38692@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Sorry for the late review.

PidfdChildWatcher should be enumerated in unix_events.py:__all__ to make the class visible by asyncio import rules.

Kyle, would you make a post-fix PR?

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Thu Nov 14 06:17:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 11:17:35 +0000
Subject: [issue38591] Deprecate Process Child Watchers
In-Reply-To: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>
Message-ID: <1573730255.7.0.659244975111.issue38591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I measured the RSS memory per thread: it's around 13.2 kB/thread. Oh, that's way lower than what I expected.

Script:

# 10: 9636 kB => 9756 kB: +12 kB/thread
# 100: 9476 kB = 10796 kB: +13.2 kB/thread
# 1000: 9552 kB = 22776 kB: +13.2 kB/thread

import os
import threading

def display_rss():
    os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")

def wait(event):
    event.wait()

class Thread(threading.Thread):
    def __init__(self):
        super().__init__()
        self.stop_event = threading.Event()
        self.started_event = threading.Event()

    def run(self):
        self.started_event.set()
        self.stop_event.wait()

    def stop(self):
        self.stop_event.set()
        self.join()

def main():
    nthread = 1000
    display_rss()
    threads = [Thread() for i in range(nthread)]
    for thread in threads:
        thread.start()
    for thread in threads:
        thread.started_event.wait()
    display_rss()
    for thread in threads:
        thread.stop()

main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38591>
_______________________________________

From report at bugs.python.org  Thu Nov 14 06:20:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 11:20:51 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573730451.64.0.237656859014.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b9e681261cd5ce6db0a79461c58d7cc52cfa4902 by Victor Stinner in branch 'master':
bpo-38644: Add _PyEval_EvalFrame() with tstate (GH-17131)
https://github.com/python/cpython/commit/b9e681261cd5ce6db0a79461c58d7cc52cfa4902


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Thu Nov 14 06:22:38 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 11:22:38 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573730558.75.0.916181000631.issue38724@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

I agree with Raymond, the repr should include the args and return code.

IMO it should *not* include the pid, for two reasons:
1. The pid is stale information if the process has finished.
2. Popen nicely abstracts away the pid, so it is normally not as useful a detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Thu Nov 14 06:39:03 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 14 Nov 2019 11:39:03 +0000
Subject: [issue38591] Deprecate Process Child Watchers
In-Reply-To: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>
Message-ID: <1573731543.5.0.482622569703.issue38591@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

To be clear: I mean that FastChildWatcher is safe only if all process's code spaws subprocesses by FastChildWatcher.
If ProcessPoolExecutor or direct subprocess calls are used the watcher is unsafe.
If some C extension spawns new processes on its own (e.g. in a separate thread) -- the watcher is unsafe.

I just think that this particular watcher is too dangerous.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38591>
_______________________________________

From report at bugs.python.org  Thu Nov 14 07:17:39 2019
From: report at bugs.python.org (Celal)
Date: Thu, 14 Nov 2019 12:17:39 +0000
Subject: [issue32884] Adding the ability for getpass to print asterisks when
 password is typed
In-Reply-To: <1519122533.37.0.467229070634.issue32884@psf.upfronthosting.co.za>
Message-ID: <1573733859.86.0.39588307088.issue32884@roundup.psfhosted.org>


Change by Celal <celal.sahin at siemens.com>:


----------
nosy: +celal.sahin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32884>
_______________________________________

From report at bugs.python.org  Thu Nov 14 07:30:13 2019
From: report at bugs.python.org (Lukas Vacek)
Date: Thu, 14 Nov 2019 12:30:13 +0000
Subject: [issue38794] Setup: support linking openssl staticly
Message-ID: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>


New submission from Lukas Vacek <lucas.vacek at gmail.com>:

Since 3.7 python depends on OpenSSL>=1.0.2 - this makes it hard to compile Python with SSL on older (yet still vendor supported) linux distributions.

It's easy to compile CPython even on old distributions like RHEL5, RHEL6, Ubuntu14.04 etc. except for ssl module.

Let's add an option to compile SSL staticly (--with-openssl-static) to make it easy to compile Python with SSL on systems with OpenSSL<1.0.2 as you usually don't want to install newer openssl as system libary nor mess with rpath/set LD_LIBRARY_PATH every time you run python.

When --with-openssl-static is not passed to ./configure everything should behave like before.

Installing CPython including ssl on system as old as RHEL5 with this option would be as easy as (after installing required build dependencies from rhel5 repositories and libffi(-devel) libraries):

wget https://www.openssl.org/source/openssl-1.0.2t.tar.gz
tar xf openssl-1.0.2t.tar.gz
cd openssl-1.0.2t
./config --openssldir=/etc/pki/tls -fPIC
make

wget https://www.python.org/ftp/python/3.7.5/Python-3.7.5.tgz
tar xf Python-3.7.5.tgz
cd Python-3.7.5
./configure --with-openssl-static=path_to_just_compiled_ssl --prefix=prefix_path
make
make install

----------
assignee: christian.heimes
components: SSL
messages: 356600
nosy: Lukas.Vacek, christian.heimes
priority: normal
severity: normal
status: open
title: Setup: support linking openssl staticly
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Thu Nov 14 07:35:17 2019
From: report at bugs.python.org (Lukas Vacek)
Date: Thu, 14 Nov 2019 12:35:17 +0000
Subject: [issue38794] Setup: support linking openssl staticly
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573734917.5.0.609861247347.issue38794@roundup.psfhosted.org>


Change by Lukas Vacek <lucas.vacek at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Thu Nov 14 07:36:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 12:36:28 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573734988.87.0.166928720738.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4d231bcc77ac8ce7d11bda0804130dcdd678f710 by Victor Stinner in branch 'master':
bpo-38644: Add _PyObject_Call() (GH-17089)
https://github.com/python/cpython/commit/4d231bcc77ac8ce7d11bda0804130dcdd678f710


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Thu Nov 14 07:49:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 12:49:09 +0000
Subject: [issue38795] test_asyncio.test_subprocess.test_terminate() timed out
 on AMD64 RHEL8 LTO + PGO 3.x
Message-ID: <1573735749.11.0.571095756017.issue38795@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

test_asyncio.test_subprocess.test_terminate() timed out on AMD64 RHEL8 LTO + PGO 3.x, and then test_asyncio.test_subprocess.test_kill() timed out on the same worker.

AMD64 RHEL8 LTO + PGO 3.x:
https://buildbot.python.org/all/#/builders/284/builds/232

0:14:52 load avg: 0.00 running: test_asyncio (14 min 30 sec)
0:15:22 load avg: 0.00 running: test_asyncio (15 min)
0:15:22 load avg: 0.00 [419/419/2] test_asyncio crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x00007f3e8b8d9740 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/selectors.py", line 468 in select
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 1837 in _run_once
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 589 in run_forever
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 621 in run_until_complete
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/test/test_asyncio/test_subprocess.py", line 188 in test_terminate
...
0:15:22 load avg: 0.00 Re-running test_asyncio in verbose mode
...
test_devnull_error (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
test_devnull_input (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
test_devnull_output (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
test_empty_input (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
test_exec_loop_deprecated (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
Timeout (0:15:00)!
Thread 0x00007fc16479e740 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/selectors.py", line 468 in select
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 1837 in _run_once
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 589 in run_forever
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 621 in run_until_complete
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/test/test_asyncio/test_subprocess.py", line 175 in test_kill
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/unittest/case.py", line 616 in _callTestMethod

----------
components: Tests, asyncio
messages: 356602
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio.test_subprocess.test_terminate() timed out on AMD64 RHEL8 LTO + PGO 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38795>
_______________________________________

From report at bugs.python.org  Thu Nov 14 07:52:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 12:52:54 +0000
Subject: [issue38796] test_multiprocessing_forkserver:
 test_mymanager_context() failed on AMD64 FreeBSD Non-Debug 3.x
Message-ID: <1573735974.8.0.945088390844.issue38796@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

It looks like a race condition in the test. If I recall correctly, there is an hardcoded timeout somewhere (1 second?).

https://buildbot.python.org/all/#/builders/368/builds/72

======================================================================
FAIL: test_mymanager_context (test.test_multiprocessing_forkserver.WithManagerTestMyManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/test/_test_multiprocessing.py", line 2807, in test_mymanager_context
    self.assertIn(manager._process.exitcode, (0, -signal.SIGTERM))
AssertionError: None not found in (0, -15)

----------
components: Tests
messages: 356603
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_forkserver: test_mymanager_context() failed on AMD64 FreeBSD Non-Debug 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38796>
_______________________________________

From report at bugs.python.org  Thu Nov 14 07:54:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 12:54:27 +0000
Subject: [issue38796] test_multiprocessing_forkserver:
 test_mymanager_context() failed on AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1573735974.8.0.945088390844.issue38796@roundup.psfhosted.org>
Message-ID: <1573736067.09.0.211375377459.issue38796@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Build warnings:

Warning -- Dangling processes: {<SpawnProcess name='QueueManager-326' pid=60266 parent=59088 stopped exitcode=-SIGTERM>, <SpawnProcess name='QueueManager-327' pid=60315 parent=59088 started>}
Warning -- Dangling processes: {<SpawnProcess name='QueueManager-326' pid=60266 parent=59088 stopped exitcode=-SIGTERM>, <SpawnProcess name='QueueManager-327' pid=60315 parent=59088 stopped exitcode=-SIGTERM>}
FAIL: test_mymanager_context (test.test_multiprocessing_forkserver.WithManagerTestMyManager)
0:19:02 load avg: 1.07 Re-running failed tests in verbose mode
0:19:02 load avg: 1.07 Re-running test_multiprocessing_forkserver in verbose mode

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38796>
_______________________________________

From report at bugs.python.org  Thu Nov 14 07:58:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 12:58:05 +0000
Subject: [issue38797] x86-64 High Sierra 3.x buildbot worker fails to build
 Python: python.exe setup.py does crash with a bus error
Message-ID: <1573736285.84.0.0787194812002.issue38797@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Build 2680 was green, then the buildbot worker became offline, and build fails since build 2694 (when the worker came back).

x86-64 High Sierra 3.x:
https://buildbot.python.org/all/#/builders/145/builds/2694

...
gcc -c -Wno-unused-result -Wsign-compare -g -O0 -Wall -Qunused-arguments  -Qunused-arguments   -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include -I/usr/local/include -I/opt/X11/include -I/usr/local/opt/bison/include -I/usr/local/opt/bzip2/include -I/usr/local/opt/expat/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/libffi/include -I/usr/local/opt/ncurses/include -I/usr/local/opt/openssl/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/zlib/include  -I/usr/local/include -I/opt/X11/include -I/usr/local/opt/bison/include -I/usr/local/opt/bzip2/include -I/usr/local/opt/expat/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/libffi/include -I/usr/local/opt/ncurses/include -I/usr/local/opt/openssl/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/zlib/include  -DPy_BUILD_CORE -o Python/frozen.o Python/frozen.c
rm -f libpython3.9d.a
ar rcs libpython3.9d.a Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/token.o  Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/bltinmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/hamt.o Python/import.o Python/importdl.o Python/initconfig.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/peephole.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o    Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/_operator.o  Modules/_collectionsmodule.o  Modules/_abc.o  Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/signalmodule.o  Modules/_stat.o  Modules/timemodule.o  Modules/_threadmodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  Modules/symtablemodule.o  Modules/xxsubtype.o Python/frozen.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpython3.9d.a(dynamic_annotations.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpython3.9d.a(pymath.o) has no symbols
gcc -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib   -Wl,-stack_size,1000000  -framework CoreFoundation -o python.exe Programs/python.o libpython3.9d.a -ldl   -framework CoreFoundation    
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
./python.exe -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' LDSHARED='gcc -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  ' OPT='-g -O0 -Wall' 	_TCLTK_INCLUDES='' _TCLTK_LIBS='' 	./python.exe -E ./setup.py  build
/bin/sh: line 1: 16679 Bus error: 10           CC='gcc' LDSHARED='gcc -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  ' OPT='-g -O0 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python.exe -E ./setup.py $quiet build
make: *** [sharedmods] Error 138
program finished with exit code 2

----------
components: Build, macOS
messages: 356605
nosy: ned.deily, ronaldoussoren, vstinner
priority: normal
severity: normal
status: open
title: x86-64 High Sierra 3.x buildbot worker fails to build Python: python.exe setup.py does crash with a bus error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38797>
_______________________________________

From report at bugs.python.org  Thu Nov 14 08:18:49 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 13:18:49 +0000
Subject: [issue27465] IDLE:Make help source menu entries unique and sorted.
In-Reply-To: <1467943126.13.0.718896019337.issue27465@psf.upfronthosting.co.za>
Message-ID: <1573737529.13.0.545373215037.issue27465@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

> I'm wondering if it would be worthwhile to add Drag and Drop functionality to the Help listbox to allow users to move the items into any order they want?

I agree that allowing a user to set the order is preferable.

Rather than drag&drop, we could just add up/down buttons to allow re-ordering.

I suggest making ordering a separate issue, and accepting a simplified version of the PR which just ensures the names are unique.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27465>
_______________________________________

From report at bugs.python.org  Thu Nov 14 08:30:37 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 14 Nov 2019 13:30:37 +0000
Subject: [issue27465] IDLE:Make help source menu entries unique and sorted.
In-Reply-To: <1467943126.13.0.718896019337.issue27465@psf.upfronthosting.co.za>
Message-ID: <1573738237.2.0.557337036788.issue27465@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27465>
_______________________________________

From report at bugs.python.org  Thu Nov 14 09:00:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 14:00:21 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573740021.41.0.179721933866.issue22367@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Failure on x86-64 High Sierra 3.8:
https://buildbot.python.org/all/#/builders/226/builds/519

Please fix tests, or revert your change:
https://pythondev.readthedocs.io/ci.html#revert-on-fail

======================================================================
ERROR: test_lockf_exclusive (test.test_fcntl.TestFcntl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/test/test_fcntl.py", line 149, in test_lockf_exclusive
    p.start()
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/context.py", line 283, in _Popen
    return Popen(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'TestFcntl.test_lockf_exclusive.<locals>.try_lockf_on_other_process'

======================================================================
ERROR: test_lockf_share (test.test_fcntl.TestFcntl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/test/test_fcntl.py", line 163, in test_lockf_share
    p.start()
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/context.py", line 283, in _Popen
    return Popen(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/Users/buildbot/buildarea/3.8.billenstein-sierra/build/Lib/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'TestFcntl.test_lockf_share.<locals>.try_lockf_on_other_process'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Thu Nov 14 09:04:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 14:04:03 +0000
Subject: [issue38798]
 test_asyncio.test_sendfile.test_sendfile_ssl_pre_and_post_data(): Overlapped
 still has pending operation at deallocation error on AMD64 Windows8.1
 Non-Debug 3.x
Message-ID: <1573740243.81.0.265051465688.issue38798@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 Windows8.1 Non-Debug 3.x:
https://buildbot.python.org/all/#/builders/12/builds/3450

test_sendfile_ssl_pre_and_post_data (test.test_asyncio.test_sendfile.ProactorEventLoopTests) ...

Warning -- Unraisable exception
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\windows_events.py", line 430, in select
    self._poll(timeout)
RuntimeError: <_overlapped.Overlapped object at 0x000000106FDD7AE0> still has pending operation at deallocation, the process may crash

Error on reading from the event loop self pipe
loop: <ProactorEventLoop running=True closed=False debug=False>
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\windows_events.py", line 453, in finish_recv
    return ov.getresult()
OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\proactor_events.py", line 768, in _loop_self_reading
    f.result()  # may raise
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\windows_events.py", line 808, in _poll
    value = callback(transferred, key, ov)
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\windows_events.py", line 457, in finish_recv
    raise ConnectionResetError(*exc.args)
ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request

ok

----------
components: Tests, Windows, asyncio
messages: 356608
nosy: asvetlov, paul.moore, steve.dower, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: test_asyncio.test_sendfile.test_sendfile_ssl_pre_and_post_data(): Overlapped still has pending operation at deallocation error on AMD64 Windows8.1 Non-Debug 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38798>
_______________________________________

From report at bugs.python.org  Thu Nov 14 09:24:23 2019
From: report at bugs.python.org (Steve Lorimer)
Date: Thu, 14 Nov 2019 14:24:23 +0000
Subject: [issue38799] race condition in multiprocessing.Pool with
 maxtasksperchild=1
Message-ID: <1573741463.54.0.726386081745.issue38799@roundup.psfhosted.org>


New submission from Steve Lorimer <steve.lorimer at gmail.com>:

There is a race condition when closing/joining a pool with maxtasksperchild=1

Illustrative example:

```
#!/usr/bin/env python3
import os
import time
import logging
import multiprocessing.pool

def run_task(i):
    print(f'[{os.getpid()}] task({i}) complete')

if __name__ == '__main__':
    multiprocessing.log_to_stderr(logging.DEBUG)

    tasks = iter(range(10))
    processes = 4

    pool = multiprocessing.pool.Pool(processes=processes, maxtasksperchild=1)
    running = []
    while True:
        try:
            running = [ f for f in running if not f.ready() ]
            avail = processes - len(running)
            if avail:
                for _ in range(avail):
                    i = next(tasks)
                    print(f'[{os.getpid()}] add task({i})')
                    future = pool.apply_async(run_task, ( i, ))
                    running.append(future)
            else:
                time.sleep(0.1)
        except StopIteration:
            print(f'[{os.getpid()}] all tasks scheduled')
            break

    print(f'[{os.getpid()}] close and join pool')
    pool.close()
    pool.join()
    print(f'[{os.getpid()}] all done')
```


Example output:


```
[DEBUG/MainProcess] created semlock with handle 140042193375232
[DEBUG/MainProcess] created semlock with handle 140042193371136
[DEBUG/MainProcess] created semlock with handle 140042193367040
[DEBUG/MainProcess] created semlock with handle 140042193362944
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-1] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-2] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-3] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-4] child process calling self.run()
[7150] add task(0)
[7150] add task(1)
[7150] add task(2)
[7150] add task(3)
[7151] task(0) complete
[7152] task(1) complete
[7153] task(2) complete
[7154] task(3) complete
[DEBUG/ForkPoolWorker-1] worker exiting after 1 tasks
[INFO/ForkPoolWorker-1] process shutting down
[DEBUG/ForkPoolWorker-2] worker exiting after 1 tasks
[DEBUG/ForkPoolWorker-1] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-3] worker exiting after 1 tasks
[INFO/ForkPoolWorker-2] process shutting down
<snip>
[DEBUG/MainProcess] cleaning up worker 2
[DEBUG/MainProcess] cleaning up worker 1
[7150] add task(8)
[7150] add task(9)
[DEBUG/MainProcess] cleaning up worker 0
[7150] all tasks scheduled
[DEBUG/MainProcess] added worker
[7150] close and join pool
[DEBUG/MainProcess] closing pool
[DEBUG/MainProcess] joining pool
[INFO/ForkPoolWorker-9] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-10] child process calling self.run()
[DEBUG/MainProcess] added worker
[7164] task(9) complete
[DEBUG/ForkPoolWorker-10] worker exiting after 1 tasks
[INFO/ForkPoolWorker-10] process shutting down
[DEBUG/ForkPoolWorker-10] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-10] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-10] process exiting with exitcode 0
[INFO/ForkPoolWorker-11] child process calling self.run()
[DEBUG/MainProcess] cleaning up worker 2
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-12] child process calling self.run()
```


The process hangs forever.

Interrupting the process then produces the following output:


```
^CTraceback (most recent call last):
[INFO/ForkPoolWorker-11] process shutting down
  File "./test.py", line 36, in <module>
[INFO/ForkPoolWorker-12] process shutting down
[DEBUG/ForkPoolWorker-11] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-12] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-11] running the remaining "atexit" finalizers
Process ForkPoolWorker-11:
[DEBUG/ForkPoolWorker-12] running the remaining "atexit" finalizers
Process ForkPoolWorker-12:
    pool.join()
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 546, in join
    self._worker_handler.join()
  File "/usr/lib/python3.6/threading.py", line 1056, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.6/threading.py", line 1072, in _wait_for_tstate_lock
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 108, in worker
    task = get()
  File "/usr/lib/python3.6/multiprocessing/queues.py", line 334, in get
    with self._rlock:
  File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
KeyboardInterrupt
[INFO/ForkPoolWorker-12] process exiting with exitcode 1
    elif lock.acquire(block, timeout):
KeyboardInterrupt
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 108, in worker
    task = get()
  File "/usr/lib/python3.6/multiprocessing/queues.py", line 335, in get
    res = self._reader.recv_bytes()
  File "/usr/lib/python3.6/multiprocessing/connection.py", line 216, in recv_bytes
    buf = self._recv_bytes(maxlength)
  File "/usr/lib/python3.6/multiprocessing/connection.py", line 407, in _recv_bytes
    buf = self._recv(4)
  File "/usr/lib/python3.6/multiprocessing/connection.py", line 379, in _recv
    chunk = read(handle, remaining)
KeyboardInterrupt
[INFO/ForkPoolWorker-11] process exiting with exitcode 1
[INFO/MainProcess] process shutting down
[DEBUG/MainProcess] running all "atexit" finalizers with priority >= 0
[DEBUG/MainProcess] finalizing pool
[DEBUG/MainProcess] helping task handler/workers to finish
[DEBUG/MainProcess] removing tasks from inqueue until task handler finished
[DEBUG/MainProcess] joining worker handler
[DEBUG/MainProcess] result handler found thread._state=TERMINATE
[DEBUG/MainProcess] ensuring that outqueue is not full
[DEBUG/MainProcess] result handler exiting: len(cache)=2, thread._state=2
[DEBUG/MainProcess] worker handler exiting
[DEBUG/MainProcess] terminating workers
[DEBUG/MainProcess] task handler got sentinel
[DEBUG/MainProcess] task handler sending sentinel to result handler
[DEBUG/MainProcess] task handler sending sentinel to workers
[DEBUG/MainProcess] joining task handler
[DEBUG/MainProcess] task handler exiting
[DEBUG/MainProcess] joining result handler
[DEBUG/MainProcess] joining pool workers
[DEBUG/MainProcess] running the remaining "atexit" finalizers
```


Since this is a race condition, the example code may need to be run several times to cause it to hang.


```
$ for i in {1..100}; do ./test.py; done
```


Notably, removing maxtasksperchild stops the process from hanging.


Additionally, changing the sleep to a busy wait causes the issue to go away:


```
wait = time.time() + 0.1
while time.time() < wait:
    pass
```

----------
components: Library (Lib)
messages: 356609
nosy: steve.lorimer at gmail.com
priority: normal
severity: normal
status: open
title: race condition in multiprocessing.Pool with maxtasksperchild=1
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38799>
_______________________________________

From report at bugs.python.org  Thu Nov 14 09:30:25 2019
From: report at bugs.python.org (Pedro Gimeno)
Date: Thu, 14 Nov 2019 14:30:25 +0000
Subject: [issue38800] Resume position for UTF-8 codec error handler not working
Message-ID: <1573741824.98.0.130776319775.issue38800@roundup.psfhosted.org>


New submission from Pedro Gimeno <pgpyb-4414 at personal.formauri.es>:

When implementing an error handler, it must return a tuple consisting of a substitution string and a position where to resume decoding. In the case of the UTF-8 codec, the resume position is ignored, and it always resumes immediately after the character that caused the error.

To reproduce, use this code:

import codecs
codecs.register_error('err', lambda err: (b'x', err.end + 1))
assert repr(u'\uDD00yz'.encode('utf8', errors='err')) == b'xz'

The above code fails the assertion because the result is b'xyz'.

It works OK for some other codecs. I have not tried to make an exhaustive list of which ones work and which ones don't, therefore this problem might apply to others.

----------
messages: 356610
nosy: pgimeno
priority: normal
severity: normal
status: open
title: Resume position for UTF-8 codec error handler not working
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38800>
_______________________________________

From report at bugs.python.org  Thu Nov 14 09:32:42 2019
From: report at bugs.python.org (Pedro Gimeno)
Date: Thu, 14 Nov 2019 14:32:42 +0000
Subject: [issue38800] Resume position for UTF-8 codec error handler not working
In-Reply-To: <1573741824.98.0.130776319775.issue38800@roundup.psfhosted.org>
Message-ID: <1573741962.35.0.12172961754.issue38800@roundup.psfhosted.org>


Pedro Gimeno <pgpyb-4414 at personal.formauri.es> added the comment:

I forgot the quotes in the assertion, it should have been "b'xz'".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38800>
_______________________________________

From report at bugs.python.org  Thu Nov 14 10:37:55 2019
From: report at bugs.python.org (Jason Killen)
Date: Thu, 14 Nov 2019 15:37:55 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1573745875.72.0.0304930870447.issue38722@roundup.psfhosted.org>


Jason Killen <jsnklln at gmail.com> added the comment:

I made the change but the test suite is giving me fits and I don't know why.  

Running: ./python -m test
...
== Tests result: FAILURE ==

392 tests OK.

1 test failed:
    test_tools

26 tests skipped:
    test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_idle
    test_kqueue test_msilib test_ossaudiodev test_readline
    test_smtpnet test_socketserver test_startfile test_tcl
    test_timeout test_tix test_tk test_ttk_guionly test_ttk_textonly
    test_turtle test_urllib2net test_urllibnet test_winconsoleio
    test_winreg test_winsound test_xmlrpc_net test_zipfile64

Total duration: 17 min 38 sec
Tests result: FAILURE


But running: ./python -m test -v test_tools
...
Ran 223 tests in 2.503s

OK (skipped=2, expected failures=14)

== Tests result: SUCCESS ==

1 test OK.

Total duration: 2.6 sec
Tests result: SUCCESS


Any tips for a newbe?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Thu Nov 14 11:04:17 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Nov 2019 16:04:17 +0000
Subject: [issue38797] x86-64 High Sierra 3.x buildbot worker fails to build
 Python: python.exe setup.py does crash with a bus error
In-Reply-To: <1573736285.84.0.0787194812002.issue38797@roundup.psfhosted.org>
Message-ID: <1573747457.95.0.483271558303.issue38797@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Note that subsequent builds compiled successfully, see https://buildbot.python.org/all/#/builders/145/builds/2699 for the latest.  It has been failing a test since build 2695, though.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38797>
_______________________________________

From report at bugs.python.org  Thu Nov 14 11:18:27 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 14 Nov 2019 16:18:27 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573748307.47.0.42183258764.issue22367@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +16664
pull_request: https://github.com/python/cpython/pull/17154

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Thu Nov 14 11:22:27 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 14 Nov 2019 16:22:27 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573748547.4.0.762699024751.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@vstinner

Victor, Thanks for letting me know.
It was reproduced on my mac machine so I fix the test.
Please take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Thu Nov 14 11:44:47 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Nov 2019 16:44:47 +0000
Subject: [issue38793] pathlib.Path.resolve(strict=False) strips final path
 components
In-Reply-To: <1573726602.08.0.459408660928.issue38793@roundup.psfhosted.org>
Message-ID: <1573749887.29.0.940388820885.issue38793@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I'm not sure - I try the same thing (on 3.6, 3.7 and 3.8) and get different results:

>>> import pathlib
>>> p = pathlib.Path(".", "a", "b", "c")
>>> p.resolve(strict=False)
WindowsPath('a/b/c')

Are you sure that it's not successfully resolving a link of some kind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38793>
_______________________________________

From report at bugs.python.org  Thu Nov 14 11:47:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Nov 2019 16:47:57 +0000
Subject: [issue38793] pathlib.Path.resolve(strict=False) strips final path
 components
In-Reply-To: <1573726602.08.0.459408660928.issue38793@roundup.psfhosted.org>
Message-ID: <1573750077.95.0.178620317279.issue38793@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

If "a" exists in the current directory, I get this (correct) result:

>>> import pathlib
>>> p = pathlib.Path(".", "a", "b", "c")
>>> p.resolve(strict=False)
WindowsPath('<my CWD>/a/b/c')

So there's an existence check of some kind that's not being handled properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38793>
_______________________________________

From report at bugs.python.org  Thu Nov 14 11:58:31 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Nov 2019 16:58:31 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1573750711.9.0.268916992823.issue33125@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Thu Nov 14 12:05:50 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Nov 2019 17:05:50 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1573751150.24.0.678120821821.issue33125@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I just added a PR that will produce ARM64 releases (as embeddable, nuget and Microsoft Store packages).

The only missing feature is tkinter (and everything that depends on it). For users who require that, I'd suggest grabbing the x86 installer from python.org which works fine (apart from some minor arithmetic and process management bugs in the Windows emulation layer).

This is not saying we're going to release it just yet. Really it shouldn't be released until 3.9, as it's a new platform and we need to allow the 3rd party package ecosystem to catch up, but at least having the ability to build packages easily will enable those who are already trying to do it themselves.

Allegedly there's a lot of demand for Python on ARM64, but I haven't actually seen it other than this bug. And if that demand immediately extends to numpy or pywin32 on ARM64 then we're still a very long way from actually satisfying it.

I'll likely tweak the PR a bit more to prevent releasing ARM64 packages by default, but then I don't see any issue having it in the 3.8 and master branches for those who would be helped. Any thoughts/comments?

----------
assignee:  -> steve.dower
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Thu Nov 14 12:08:39 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Nov 2019 17:08:39 +0000
Subject: [issue38793] pathlib.Path.resolve(strict=False) strips final path
 components
In-Reply-To: <1573726602.08.0.459408660928.issue38793@roundup.psfhosted.org>
Message-ID: <1573751319.05.0.496580753566.issue38793@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38793>
_______________________________________

From report at bugs.python.org  Thu Nov 14 12:31:42 2019
From: report at bugs.python.org (Yaroslav Nikitenko)
Date: Thu, 14 Nov 2019 17:31:42 +0000
Subject: [issue38801] Scientific notation doesn't work with itertools.islice
Message-ID: <1573752702.13.0.205324703256.issue38801@roundup.psfhosted.org>


New submission from Yaroslav Nikitenko <metst13 at gmail.com>:

Numbers written in scientific notation don't work with itertools.islice.

Check this script: 

# a usual function works
## def works as well
f = lambda x : x 
f(1e+6)
# 1000000.0
import itertools
# islice without scientific notation works
itertools.islice([], 1000000)
# <itertools.islice object at 0x7fc7ce55be90>
itertools.islice([], 1e+6)
# Traceback (most recent call last):
#   File "<stdin>", line 1, in <module>
# ValueError: Stop argument for islice() must be None or an integer: 0 <= x <= sys.maxsize.

All this works well in Python 2.7.17, but scientific notation fails in Python 3.7.5. I use Fedora Core 29.

----------
components: Library (Lib)
messages: 356618
nosy: ynikitenko
priority: normal
severity: normal
status: open
title: Scientific notation doesn't work with itertools.islice
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38801>
_______________________________________

From report at bugs.python.org  Thu Nov 14 13:00:24 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Nov 2019 18:00:24 +0000
Subject: [issue38801] Scientific notation doesn't work with itertools.islice
In-Reply-To: <1573752702.13.0.205324703256.issue38801@roundup.psfhosted.org>
Message-ID: <1573754424.26.0.128990146775.issue38801@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Hello Yaroslav.  What you've observed was a intentional change to make islice() behave more like regular slices.  Neither of those accept floats which are precarious to use for indexing.

A workaround is to replace 1e+6 with 10**6.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38801>
_______________________________________

From report at bugs.python.org  Thu Nov 14 13:13:23 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Nov 2019 18:13:23 +0000
Subject: [issue38800] Resume position for UTF-8 codec error handler not working
In-Reply-To: <1573741824.98.0.130776319775.issue38800@roundup.psfhosted.org>
Message-ID: <1573755203.09.0.626340545964.issue38800@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It works to me (after fixing the assertion).

What Python version do you use? In Python 2 u'\uDD00' is encodable to UTF-8, so the error handler is not called. u'\uDD00yz'.encode('utf8') gives '\xed\xb4\x80yz'.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38800>
_______________________________________

From report at bugs.python.org  Thu Nov 14 13:27:48 2019
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 14 Nov 2019 18:27:48 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573756068.04.0.81096742624.issue22367@roundup.psfhosted.org>


Change by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
nosy:  -neologix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Thu Nov 14 13:28:15 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Nov 2019 18:28:15 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1573756095.83.0.348135289709.issue38622@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks! Would you like to create a PR on GitHub for this? Or are you happy for me to do it.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Thu Nov 14 13:35:18 2019
From: report at bugs.python.org (Yaroslav Nikitenko)
Date: Thu, 14 Nov 2019 18:35:18 +0000
Subject: [issue38801] Scientific notation doesn't work with itertools.islice
In-Reply-To: <1573752702.13.0.205324703256.issue38801@roundup.psfhosted.org>
Message-ID: <1573756518.0.0.329041362925.issue38801@roundup.psfhosted.org>


Yaroslav Nikitenko <metst13 at gmail.com> added the comment:

Hello Raymond. Many thanks for your explanation.

In this case I suggest any of the following:

1) distinguish between integer and floating numbers in scientific notation. Definitely, 1e+6 is an integer. I can't see where else numbers in scientific notation are defined as only floats.

2) to write explicitly in the documentation that scientific notation is always float. I searched documentation of 'scientific notation', but didn't found that (https://docs.python.org/3/search.html?q=scientific+notation&check_keywords=yes&area=default)

3) to provide a better exception message in islice if this is a known issue. 

Should I change parameters of my report or create a new one? I'm afraid this message may get lost if closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38801>
_______________________________________

From report at bugs.python.org  Thu Nov 14 13:35:34 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Nov 2019 18:35:34 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1573756534.8.0.558567793615.issue38622@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Actually, it looks like we need to add events for many of the _ctypes functions, so I'll go through and do them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Thu Nov 14 13:39:58 2019
From: report at bugs.python.org (Tim Peters)
Date: Thu, 14 Nov 2019 18:39:58 +0000
Subject: [issue38789] difflib lacks a way to check if results are empty
In-Reply-To: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>
Message-ID: <1573756798.33.0.551373131214.issue38789@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Please be explicit:  exactly which functions are you talking about, and exactly what do you want them to do instead.  Since, best I can tell, this is the first complaint of its kind, it's a pretty safe bet people can't guess what you want ;-)

Note that, e.g., Differ(...).compare(...) returns a generator-iterator.  There is no general way in Python to know whether a generator will yield a non-empty sequence of results without running the generator.  This is common to all generators, not unique to those difflib returns.

So, of course, the same kinds of idioms can be used as for any other generator.  For example:

foundone = False
for line in difflib.Differ(...).compare(...):
    if not foundone:
        # there is at least one result, and this is the first
        # maybe print a header line here, or whatever
        foundone = True
    process(line)
if not foundone:
    # the generator produced nothing

Simpler to code is to force the results into a list instead, but then you lose the possible memory-saving advantages of iterating over a generator:

    result = list(difflib.Differ(...).compare(...))
    if result:
        # there are results to deal with
    else:
        # the generator produced nothing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38789>
_______________________________________

From report at bugs.python.org  Thu Nov 14 14:23:45 2019
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 14 Nov 2019 19:23:45 +0000
Subject: [issue38801] Scientific notation doesn't work with itertools.islice
In-Reply-To: <1573752702.13.0.205324703256.issue38801@roundup.psfhosted.org>
Message-ID: <1573759425.68.0.773037448102.issue38801@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

The behavior is documented here: https://docs.python.org/3.9/library/stdtypes.html#numeric-types-int-float-complex

> Numeric literals containing a decimal point or an exponent sign yield floating point numbers.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38801>
_______________________________________

From report at bugs.python.org  Thu Nov 14 15:45:21 2019
From: report at bugs.python.org (Pedro Gimeno)
Date: Thu, 14 Nov 2019 20:45:21 +0000
Subject: [issue38800] Resume position for UTF-8 codec error handler not working
In-Reply-To: <1573741824.98.0.130776319775.issue38800@roundup.psfhosted.org>
Message-ID: <1573764321.41.0.253996635169.issue38800@roundup.psfhosted.org>


Pedro Gimeno <pgpyb-4414 at personal.formauri.es> added the comment:

Python 3.5 from Debian stretch (oldstable). You're right, I can't reproduce it in 3.7 from Buster. Sorry for the bogus report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38800>
_______________________________________

From report at bugs.python.org  Thu Nov 14 16:17:02 2019
From: report at bugs.python.org (Lukas Vacek)
Date: Thu, 14 Nov 2019 21:17:02 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573766222.13.0.0581246103695.issue38794@roundup.psfhosted.org>


Change by Lukas Vacek <lucas.vacek at gmail.com>:


----------
title: Setup: support linking openssl staticly -> Setup: support linking openssl statically

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Thu Nov 14 16:18:09 2019
From: report at bugs.python.org (Ben Boeckel)
Date: Thu, 14 Nov 2019 21:18:09 +0000
Subject: [issue38728] Update PC/pyconfig.h to support disabling auto linking
In-Reply-To: <1573080091.42.0.697826916573.issue38728@roundup.psfhosted.org>
Message-ID: <1573766289.98.0.656654503101.issue38728@roundup.psfhosted.org>


Change by Ben Boeckel <mathstuf+bpo at gmail.com>:


----------
nosy: +mathstuf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38728>
_______________________________________

From report at bugs.python.org  Thu Nov 14 16:52:21 2019
From: report at bugs.python.org (Michael Yagliyan)
Date: Thu, 14 Nov 2019 21:52:21 +0000
Subject: [issue38802] Clearer wording of os.WNOHANG documentation to avoid
 misinterpretation
Message-ID: <1573768341.13.0.576203356509.issue38802@roundup.psfhosted.org>


New submission from Michael Yagliyan <myagliyan1 at bloomberg.net>:

For versions 2.7 through 3.9 of https://docs.python.org/3/library/os.html, os.WNOHANG is described as returning (0, 0) when no child process status is immediately available.

However, both os.wait3() and os.wait4() return 3-element tuples and are described as being similar to os.waitpid().  This, combined with the os.WNOHANG documentation being somewhat open to interpretation, makes it very easy to conclude (incorrectly) that wait3(WNOHANG) and wait4(WNOHANG) would return (0, 0) when no child process status is immediately available.  In fact, they would return a 3-element tuple with the first 2 elements being 0.

I suggest rephrasing the os.WNOHANG documentation to the following (or something similar):

"The option for waitpid() to return immediately if no child process status is available immediately, in which case the function returns (0, 0).  Correspondingly, wait3() and wait4() would return 3-element tuples with the first 2 elements being 0 and the last being a default-constructed resource usage information object."

Unfortunately that last part about the default-constructed resource usage information object is only true after this recent bug fix:
https://github.com/python/cpython/pull/15111/files

So I'll leave it to y'all to decide how to update the documentation since my proposed phrasing is dependent on that bug fix.

----------
assignee: docs at python
components: Documentation
messages: 356627
nosy: bbmmy, docs at python
priority: normal
severity: normal
status: open
title: Clearer wording of os.WNOHANG documentation to avoid misinterpretation
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38802>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:04:48 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Nov 2019 22:04:48 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1573769088.16.0.0811123151648.issue38622@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:08:37 2019
From: report at bugs.python.org (Michael Yagliyan)
Date: Thu, 14 Nov 2019 22:08:37 +0000
Subject: [issue38802] Clearer wording of os.WNOHANG documentation to avoid
 misinterpretation
In-Reply-To: <1573768341.13.0.576203356509.issue38802@roundup.psfhosted.org>
Message-ID: <1573769317.24.0.248232707858.issue38802@roundup.psfhosted.org>


Michael Yagliyan <myagliyan1 at bloomberg.net> added the comment:

If this documentation fix will not be backported (i.e. it will only apply to versions *after* the aforementioned bug fix) then a more precise way to phrase that last part would be:

"...with the first 2 elements being 0 and the last being an all-zero resource usage information object."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38802>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:15:12 2019
From: report at bugs.python.org (Julien Palard)
Date: Thu, 14 Nov 2019 22:15:12 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573769712.38.0.592398476731.issue38351@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

So, for newcomers finding this via "easy issues", go for it, you can fix this one :)

On the different subjects discussed:

# Mass-edit the stdlib

We all agree that we should not mass-edit stdlib, (yet upgrading %-formatting to a newer syntax when modifying the same line may sometimes be a good idea).


# Mass-edit the doc

Having an f-string only doc is not possible, as Raymond mentionned (i18n, logging, templating), and not desirable: we need to document all existing formatting syntax. But the question is less "should we move everything to f-strings" than "should we move most examples out of %-formatting".


# Let's not encourage %-formatting

As we introduced str.format to fix issues from %-formatting [1] and allow extending formatting [2], we should not encourage newcomers to %-format strings.

Good news: in the tutorial there's a *single* occurence of %-formatting in a paragraph named "Old string formatting"!

There's probably a bunch of other places where upgrading the syntax in the doc would be a good idea, let's do it as we see them, when we feel it should obviously be upgraded, it also make nice easy issues, exactly as Mariatta did with this one (thanks Mariatta!).


[1]: %-formatting a single value that may or may not be a tuple.
[2]: allowing to format everything thrue __format__, not just the hardcoded list of type recognized by %-formatting.

----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:25:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 22:25:01 +0000
Subject: [issue38447] test_multiprocessing_spawn: Dangling processes:
 {<SpawnProcess(QueueManager-1576, stopped)>} on AMD64 RHEL7 Refleaks 3.7
In-Reply-To: <1570798904.01.0.669672054648.issue38447@roundup.psfhosted.org>
Message-ID: <1573770301.56.0.0380526229259.issue38447@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 RHEL7 LTO + PGO 3.x:
https://buildbot.python.org/all/#/builders/258/builds/227

...
test_bounded_semaphore (test.test_multiprocessing_spawn.WithProcessesTestSemaphore) ... ok
test_semaphore (test.test_multiprocessing_spawn.WithProcessesTestSemaphore) ... ok
test_timeout (test.test_multiprocessing_spawn.WithProcessesTestSemaphore) ... ok
test_copy (test.test_multiprocessing_spawn.WithProcessesTestSharedCTypes) ... ok
test_sharedctypes (test.test_multiprocessing_spawn.WithProcessesTestSharedCTypes) ... ok
test_synchronize (test.test_multiprocessing_spawn.WithProcessesTestSharedCTypes) ... ok
test_shared_memory_ShareableList_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ok
test_shared_memory_ShareableList_pickling (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ok
test_shared_memory_SharedMemoryManager_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ok
test_shared_memory_SharedMemoryManager_reuses_resource_tracker (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ok
test_shared_memory_SharedMemoryServer_ignores_sigint (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ok
test_shared_memory_across_processes (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ok
test_shared_memory_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ok
test_shared_memory_cleaned_after_process_termination (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory) ... ok
Warning -- Dangling processes: {<SpawnProcess name='SharedMemoryManager-314' pid=29989 parent=17707 started>}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38447>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:27:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 22:27:18 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1573770438.98.0.132046455342.issue37224@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Windows8.1 Refleaks 3.8:
https://buildbot.python.org/all/#/builders/224/builds/151

0:54:23 load avg: 5.62 [306/423/3] test__xxsubinterpreters failed -- running: test_asyncio (4 min 26 sec), test_zipfile (6 min 6 sec), test_compileall (6 min 21 sec)
beginning 6 repetitions
123456
..Exception in thread Thread-27:
Traceback (most recent call last):
? File "D:\buildarea\3.8.ware-win81-release.refleak\build\lib\threading.py", line 932, in _bootstrap_inner
? ? self.run()
? File "D:\buildarea\3.8.ware-win81-release.refleak\build\lib\threading.py", line 870, in run
? ? self._target(*self._args, **self._kwargs)
? File "D:\buildarea\3.8.ware-win81-release.refleak\build\lib\test\test__xxsubinterpreters.py", line 51, in run
? ? interpreters.run_string(interp, dedent(f"""
RuntimeError: unrecognized interpreter ID 175
test test__xxsubinterpreters failed -- Traceback (most recent call last):
? File "D:\buildarea\3.8.ware-win81-release.refleak\build\lib\test\test__xxsubinterpreters.py", line 763, in test_still_running
? ? interpreters.destroy(interp)
AssertionError: RuntimeError not raised

FAIL: test_subinterpreter (test.test__xxsubinterpreters.IsRunningTests)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:35:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 22:35:03 +0000
Subject: [issue38447] test_multiprocessing_spawn: Dangling processes:
 {<SpawnProcess(QueueManager-1576, stopped)>} on AMD64 RHEL7 Refleaks 3.7
In-Reply-To: <1570798904.01.0.669672054648.issue38447@roundup.psfhosted.org>
Message-ID: <1573770903.68.0.480624194301.issue38447@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

x86 Windows7 3.x:
https://buildbot.python.org/all/#/builders/58/builds/3223

...
test_dict_proxy_nested (test.test_multiprocessing_spawn.WithManagerTestContainers) ... ok
test_list (test.test_multiprocessing_spawn.WithManagerTestContainers) ... ok
test_list_iter (test.test_multiprocessing_spawn.WithManagerTestContainers) ... ok
test_list_proxy_in_list (test.test_multiprocessing_spawn.WithManagerTestContainers) ... ok
test_namespace (test.test_multiprocessing_spawn.WithManagerTestContainers) ... ok
test_event (test.test_multiprocessing_spawn.WithManagerTestEvent) ... ok
test_lock (test.test_multiprocessing_spawn.WithManagerTestLock) ... ok
test_lock_context (test.test_multiprocessing_spawn.WithManagerTestLock) ... ok
test_rlock (test.test_multiprocessing_spawn.WithManagerTestLock) ... ok
test_rapid_restart (test.test_multiprocessing_spawn.WithManagerTestManagerRestart) ... ok
Warning -- multiprocessing.Manager still has [<SpawnProcess name='SyncManager-116' pid=2420 parent=3512 started>] active children after 5.256999999983236 seconds

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38447>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:46:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 22:46:32 +0000
Subject: [issue38803] test_wait3 and test_wait4 leaked references on x86
 Gentoo Refleaks 3.x
Message-ID: <1573771592.29.0.825228162147.issue38803@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

x86 Gentoo Refleaks 3.x, first failure:
https://buildbot.python.org/all/#/builders/1/builds/769

test_wait3 leaked [23, 23, 23] references, sum=69
test_wait4 leaked [22, 21, 22] references, sum=65


The leak was introduced by:

commit b3966639d28313809774ca3859a347b9007be8d2
Author: Eddie Elizondo <eelizondo at fb.com>
Date:   Tue Nov 5 07:16:14 2019 -0800

    bpo-35381 Remove all static state from posixmodule (GH-15892)
    
    
    
    After #9665, this moves the remaining types in posixmodule to be heap-allocated to make it compatible with PEP384 as well as modifying all the type accessors to fully make the type opaque.
    
    The original PR that got messed up a rebase: https://github.com/python/cpython/pull/10854. All the issues in that commit have now been addressed since https://github.com/python/cpython/pull/11661 got committed.
    
    This change also removes any state from the data segment and onto the module state itself.
    
    
    https://bugs.python.org/issue35381
    
    
    
    Automerge-Triggered-By: @encukou

----------
components: Tests
messages: 356633
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_wait3 and test_wait4 leaked references on x86 Gentoo Refleaks 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38803>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:46:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 22:46:56 +0000
Subject: [issue35381] posixmodule: convert statically allocated types
 (DirEntryType & ScandirIteratorType) to heap-allocated types
In-Reply-To: <1543818839.39.0.788709270274.issue35381@psf.upfronthosting.co.za>
Message-ID: <1573771616.28.0.216521182883.issue35381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This change introduced a reference leak: bpo-38803 "test_wait3 and test_wait4 leaked references on x86 Gentoo Refleaks 3.x".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35381>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:50:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 22:50:42 +0000
Subject: [issue38803] test_wait3 and test_wait4 leaked references on x86
 Gentoo Refleaks 3.x
In-Reply-To: <1573771592.29.0.825228162147.issue38803@roundup.psfhosted.org>
Message-ID: <1573771842.27.0.0850879526248.issue38803@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Similar failure on other buildbot workers.

AMD64 RHEL7 Refleaks 3.x:
https://buildbot.python.org/all/#/builders/264/builds/49

AMD64 Fedora Stable Refleaks 3.x:
https://buildbot.python.org/all/#/builders/317/builds/42

AMD64 Fedora Rawhide Refleaks 3.x:
https://buildbot.python.org/all/#/builders/189/builds/197

AMD64 RHEL8 Refleaks 3.x:
https://buildbot.python.org/all/#/builders/272/builds/50

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38803>
_______________________________________

From report at bugs.python.org  Thu Nov 14 18:00:20 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 14 Nov 2019 23:00:20 +0000
Subject: [issue38670] can we accept os.PathLike objects within the subprocess
 args= list?
In-Reply-To: <1572768792.96.0.63320860714.issue38670@roundup.psfhosted.org>
Message-ID: <1573772420.13.0.310409726753.issue38670@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38670>
_______________________________________

From report at bugs.python.org  Thu Nov 14 18:38:00 2019
From: report at bugs.python.org (Ben Caller)
Date: Thu, 14 Nov 2019 23:38:00 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
Message-ID: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>


New submission from Ben Caller <bcaller at gmail.com>:

The regex http.cookiejar.LOOSE_HTTP_DATE_RE iss vulnerable to regular
expression denial of service (REDoS). LOOSE_HTTP_DATE_RE.match is called when using http.cookiejar.CookieJar to parse Set-Cookie headers returned by a server. Processing a response from a malicious HTTP server can lead to extreme CPU usage and execution will be blocked for a long time.

The regex http.cookiejar.LOOSE_HTTP_DATE_RE contains multiple overlapping \s* capture groups.
Ignoring the ?-optional capture groups the regex can be simplified to

    \d+-\w+-\d+(\s*\s*\s*)$

Therefore, a long sequence of spaces can trigger bad performance.
LOOSE_HTTP_DATE_RE backtracks if last character doesn't match \s or (?![APap][Mm]\b)[A-Za-z]+

Matching a malicious string such as

    LOOSE_HTTP_DATE_RE.match("1-1-1" + (" " * 2000) + "!")

will cause catastrophic backtracking.

Timing test:


    import http.cookiejar
    import timeit

    def run(n_spaces):
        assert n_spaces <= 65506, "Set-Cookie header line must be <= 65536"
        spaces = " " * n_spaces
        expires = f"1-1-1{spaces}!"
        http2time = http.cookiejar.http2time
        t = timeit.Timer(
            'http2time(expires)',
            globals=locals(),
        )
        print(n_spaces, "{:.3g}".format(t.autorange()[1]))

    i = 512
    while True:
        run(i)
        i <<= 1


Timeit output (seconds) on my computer when doubling the number of spaces:


    512     0.383
    1024    3.02
    2048   23.4
    4096  184
    8192 1700

As expected it's approx O(n^3). The maximum n_spaces to fit in a Set-Cookie header is 65506 which will take days.

You can create a malicious server which responds with Set-Cookie headers to attack all python programs which access it e.g.


    from http.server import BaseHTTPRequestHandler, HTTPServer

    def make_set_cookie_value(n_spaces):
        spaces = " " * n_spaces
        expiry = f"1-1-1{spaces}!"
        return f"x;Expires={expiry}"

    class Handler(BaseHTTPRequestHandler):
        def do_GET(self):
            self.log_request(204)
            self.send_response_only(204)  # Don't bother sending Server and Date
            n_spaces = (
                int(self.path[1:])  # Can GET e.g. /100 to test shorter sequences
                if len(self.path) > 1 else
                65506  # Max header line length 65536
            )
            value = make_set_cookie_value(n_spaces)
            for i in range(99):  # Not necessary, but we can have up to 100 header lines
                self.send_header("Set-Cookie", value)
            self.end_headers()

    if __name__ == "__main__":
        HTTPServer(("", 44020), Handler).serve_forever()


This server returns 99 Set-Cookie headers. Each has 65506 spaces.
Extracting the cookies will pretty much never complete.

Vulnerable client using the example at the bottom of https://docs.python.org/3/library/http.cookiejar.html :


    import http.cookiejar, urllib.request
    cj = http.cookiejar.CookieJar()
    opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
    r = opener.open("http://localhost:44020/")


The popular requests library is also vulnerable without any additional options (as it uses http.cookiejar by default):


    import requests
    requests.get("http://localhost:44020/")


As such, python applications need to be careful not to visit malicious servers.

I have a patch. Will make a PR soon.
This was originally submitted to the security list, but posted here 'since this is "merely" a DoS attack and not a privilege escalation'.

- Ben

----------
components: Library (Lib)
messages: 356636
nosy: bc
priority: normal
severity: normal
status: open
title: Regular Expression Denial of Service in http.cookiejar
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Thu Nov 14 18:45:29 2019
From: report at bugs.python.org (Mark Grandi)
Date: Thu, 14 Nov 2019 23:45:29 +0000
Subject: [issue38805] locale.getlocale() returns a non RFC1766 language code
Message-ID: <1573775129.28.0.0290867966019.issue38805@roundup.psfhosted.org>


New submission from Mark Grandi <markgrandi at gmail.com>:

It seems that something with windows 10, python 3.8, or both changed where `locale.getlocale()` is now returning strange results

According to the documentation: https://docs.python.org/3/library/locale.html?highlight=locale%20getlocale#locale.getlocale  , the language code should be in RFC1766 format:

Language-Tag = Primary-tag *( "-" Subtag )
Primary-tag = 1*8ALPHA
Subtag = 1*8ALPHA
Whitespace is not allowed within the tag.

but in python 3.8, I am getting a language code that doesn't meet RFC1766 specs:


PS C:\Users\auror> py -3
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform; platform.platform()
'Windows-10-10.0.18362-SP0'
>>> import locale; locale.getlocale(); locale.getdefaultlocale()
('English_United States', '1252')
('en_US', 'cp1252')
>>>


on the same machine, with python 3.7.4:

PS C:\Python37> .\python.exe
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform; platform.platform()
'Windows-10-10.0.18362-SP0'
>>> import locale; locale.getlocale(); locale.getdefaultlocale()
(None, None)
('en_US', 'cp1252')
>>>


also interesting that the encoding is different in py3.8 between `locale.getlocale()` and `locale.getdefaultlocale()`, being '1252' and 'cp1252', this might not be related though as it was present in python 3.7.4

these issues might be related, but stuff found hwen searching for 'locale' bugs:

https://bugs.python.org/issue26024
https://bugs.python.org/issue37945

----------
components: Library (Lib)
messages: 356637
nosy: markgrandi
priority: normal
severity: normal
status: open
title: locale.getlocale() returns a non RFC1766 language code
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38805>
_______________________________________

From report at bugs.python.org  Thu Nov 14 18:46:09 2019
From: report at bugs.python.org (Ben Caller)
Date: Thu, 14 Nov 2019 23:46:09 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1573775169.01.0.911716404491.issue38804@roundup.psfhosted.org>


Change by Ben Caller <bcaller at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Thu Nov 14 19:12:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Nov 2019 00:12:57 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1573776777.26.0.643378086958.issue38622@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +16667
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17158

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Thu Nov 14 19:26:53 2019
From: report at bugs.python.org (daniel hahler)
Date: Fri, 15 Nov 2019 00:26:53 +0000
Subject: =?utf-8?b?W2lzc3VlMzg4MDZdICJwZGIuUGRiKHNraXA94oCmKS5zZXRfdHJhY2UoKSIg?=
 =?utf-8?q?should_always_stop_on_calling_frame?=
Message-ID: <1573777613.93.0.994248394798.issue38806@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

The following will not stop for debugging:

    python3.8 -c 'import pdb; pdb.Pdb(skip=["__main__"]).set_trace()'

The example is contrived, the real case would be to have some "noisy" module being excluded in general, but when you add an explicit "set_trace()" in there it should still stop there, and not on some upper frame.

This was changed a long time already in https://github.com/python/cpython/commit/313a7513b0c5771042d850d70782a2448d1cdcb7 (Python 2.3), but it is not really clear.

I will create a PR reverting that part and see how it goes.

----------
components: Library (Lib)
messages: 356638
nosy: blueyed
priority: normal
severity: normal
status: open
title: "pdb.Pdb(skip=?).set_trace()" should always stop on calling frame
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38806>
_______________________________________

From report at bugs.python.org  Thu Nov 14 19:29:14 2019
From: report at bugs.python.org (daniel hahler)
Date: Fri, 15 Nov 2019 00:29:14 +0000
Subject: =?utf-8?b?W2lzc3VlMzg4MDZdICJwZGIuUGRiKHNraXA94oCmKS5zZXRfdHJhY2UoKSIg?=
 =?utf-8?q?should_always_stop_on_calling_frame?=
In-Reply-To: <1573777613.93.0.994248394798.issue38806@roundup.psfhosted.org>
Message-ID: <1573777754.4.0.934234554066.issue38806@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38806>
_______________________________________

From report at bugs.python.org  Thu Nov 14 19:41:11 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 15 Nov 2019 00:41:11 +0000
Subject: [issue38591] Deprecate Process Child Watchers
In-Reply-To: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>
Message-ID: <1573778471.04.0.421523294016.issue38591@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> You have to account also for the thread stack size. I suggest to look at RSS memory instead.

Ah, good point. I believe get_size() only accounts for the memory usage of the thread object, not the amount allocated in physical memory from the thread stack. Thanks for the clarification. 

> I measured the RSS memory per thread: it's around 13.2 kB/thread. Oh, that's way lower than what I expected.

On Python 3.8 and Linux kernel 5.3.8, I received the following result:

# Starting mem
VmRSS:      8408 kB
# After initializing and starting 1k threads:
VmRSS:     21632 kB

~13224kB for 1k threads, which reflects the ~13.2kB/thread estimate. 

Also, as a sidenote, I think you could remove the "for thread in threads: thread.started_event.wait()" portion for our purposes. IIUC, waiting on the threading.Event objects wouldn't affect memory usage.

> To be clear: I mean that FastChildWatcher is safe only if all process's code spaws subprocesses by FastChildWatcher.
> If ProcessPoolExecutor or direct subprocess calls are used the watcher is unsafe.
> If some C extension spawns new processes on its own (e.g. in a separate thread) -- the watcher is unsafe.

> I just think that this particular watcher is too dangerous.

So are we at least in agreement for starting with deprecating FastChildWatcher? If a server is incredibly tight on memory and it can't spare ~13.2kB/thread, SafeChildWatcher would be an alternative to ThreadedChildWatcher.

Personally, I still think this amount is negligible for most production servers, and that we can reasonably deprecate SafeChildWatcher as well. But I can start with FastChildWatcher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38591>
_______________________________________

From report at bugs.python.org  Thu Nov 14 20:02:30 2019
From: report at bugs.python.org (=?utf-8?b?VG9tw6FzIEZhcsOtYXM=?=)
Date: Fri, 15 Nov 2019 01:02:30 +0000
Subject: [issue38807] Better exception message in os.path.join
Message-ID: <1573779750.02.0.708670809394.issue38807@roundup.psfhosted.org>


New submission from Tom?s Far?as <tomasfariassantana at gmail.com>:

Passing an object with an invalid type, like None, to os.path.join after the first argument results in the following exception: 

TypeError: join() argument must be str or bytes, not 'NoneType'

Exception message can be updated to show that os.PathLike objects can be used:

TypeError: join() argument must be str, bytes or os.PathLike object, not 'NoneType'

This is also more consistent with the TypeError raised by os.fspath.

----------
components: Library (Lib)
messages: 356640
nosy: tomasfarias
priority: normal
severity: normal
status: open
title: Better exception message in os.path.join
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38807>
_______________________________________

From report at bugs.python.org  Thu Nov 14 20:08:37 2019
From: report at bugs.python.org (=?utf-8?b?VG9tw6FzIEZhcsOtYXM=?=)
Date: Fri, 15 Nov 2019 01:08:37 +0000
Subject: [issue38807] Better exception message in os.path.join
In-Reply-To: <1573779750.02.0.708670809394.issue38807@roundup.psfhosted.org>
Message-ID: <1573780117.93.0.10538181534.issue38807@roundup.psfhosted.org>


Change by Tom?s Far?as <tomasfariassantana at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38807>
_______________________________________

From report at bugs.python.org  Thu Nov 14 21:04:25 2019
From: report at bugs.python.org (Guenther Starnberger)
Date: Fri, 15 Nov 2019 02:04:25 +0000
Subject: [issue34572] C unpickling bypasses import thread safety
In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za>
Message-ID: <1573783465.47.0.18535272726.issue34572@roundup.psfhosted.org>


Guenther Starnberger <gst at gst.name> added the comment:

For this issue only 3.7 and 3.8 are listed as affected versions, but it appears to be also reproducible on the latest 3.5 and 3.6 releases. I've attached a script that can be used to reproduce the issue on those earlier releases (it consistently fails for me with values of 50 or higher as command line argument).

----------
nosy: +gst
Added file: https://bugs.python.org/file48715/reproduce_34572.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34572>
_______________________________________

From report at bugs.python.org  Thu Nov 14 21:06:45 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 15 Nov 2019 02:06:45 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573783605.44.0.342523370596.issue38692@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> PidfdChildWatcher should be enumerated in unix_events.py:__all__ to make the class visible by asyncio import rules.

> Kyle, would you make a post-fix PR?

I actually just noticed that myself and was coming back to the bpo issue to mention that it was missing from __all__. I'll take of that, no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Thu Nov 14 21:27:08 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 15 Nov 2019 02:27:08 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573784828.3.0.169142233675.issue38692@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +16671
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17161

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Thu Nov 14 21:48:08 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 02:48:08 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573786088.55.0.0154347406296.issue38692@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3f8cebd32c1e6f20a1a1440e51c308a5f70ca959 by Miss Islington (bot) (Kyle Stanley) in branch 'master':
bpo-38692: Add asyncio.PidfdChildWatcher to __all__ (GH-17161)
https://github.com/python/cpython/commit/3f8cebd32c1e6f20a1a1440e51c308a5f70ca959


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Thu Nov 14 21:58:01 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 15 Nov 2019 02:58:01 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1573786681.87.0.406738482619.issue38692@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Thu Nov 14 22:38:10 2019
From: report at bugs.python.org (daniel hahler)
Date: Fri, 15 Nov 2019 03:38:10 +0000
Subject: [issue36130] Pdb(skip=[...]) + module without __name__ => TypeError
In-Reply-To: <1551239212.19.0.177135344366.issue36130@roundup.psfhosted.org>
Message-ID: <1573789090.63.0.329703837714.issue36130@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

This was fixed / can be closed (https://github.com/python/cpython/pull/12064).

----------
nosy: +blueyed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36130>
_______________________________________

From report at bugs.python.org  Thu Nov 14 23:58:09 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Nov 2019 04:58:09 +0000
Subject: [issue36130] Pdb(skip=[...]) + module without __name__ => TypeError
In-Reply-To: <1551239212.19.0.177135344366.issue36130@roundup.psfhosted.org>
Message-ID: <1573793889.88.0.930269897716.issue36130@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36130>
_______________________________________

From report at bugs.python.org  Fri Nov 15 00:02:18 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 15 Nov 2019 05:02:18 +0000
Subject: [issue36130] Pdb(skip=[...]) + module without __name__ => TypeError
In-Reply-To: <1551239212.19.0.177135344366.issue36130@roundup.psfhosted.org>
Message-ID: <1573794138.46.0.878224516846.issue36130@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks @blueyed, I guess the backport was not made by the bot though the label was applied for 3.7 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36130>
_______________________________________

From report at bugs.python.org  Fri Nov 15 00:06:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 15 Nov 2019 05:06:09 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1573794369.22.0.151941052061.issue38804@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 15 00:06:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 15 Nov 2019 05:06:47 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1573794407.8.0.889370334531.issue38804@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 15 00:10:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 15 Nov 2019 05:10:11 +0000
Subject: [issue38775] Cloudpickle.py file is crashing due to data type
 incompatibility.
In-Reply-To: <1573552153.69.0.800822929594.issue38775@roundup.psfhosted.org>
Message-ID: <1573794611.72.0.539788623636.issue38775@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I guess this was fixed upstream with https://github.com/apache/spark/commit/811d563fbf60203377e8462e4fad271c1140b4fa . Please try the latest version as per the commit details. I am closing this as third party since it's not a CPython issue. In future reports please attach the text of the traceback since it's more accessible. Thanks.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38775>
_______________________________________

From report at bugs.python.org  Fri Nov 15 00:21:45 2019
From: report at bugs.python.org (Fred Drake)
Date: Fri, 15 Nov 2019 05:21:45 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573795305.68.0.914227582029.issue38351@roundup.psfhosted.org>


Fred Drake <fdrake at gmail.com> added the comment:

Thanks, Julien!

Sounds good to me; no reason for a PR addressing this specific issue to be held up once one becomes available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Fri Nov 15 01:21:26 2019
From: report at bugs.python.org (Andrei Daraschenka)
Date: Fri, 15 Nov 2019 06:21:26 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573798886.52.0.766156148122.issue38351@roundup.psfhosted.org>


Change by Andrei Daraschenka <dorosch.github.io at yandex.ru>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Fri Nov 15 01:42:51 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 15 Nov 2019 06:42:51 +0000
Subject: [issue23544] IDLE hangs when selecting Stack View with debug active
In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za>
Message-ID: <1573800171.9.0.414560345925.issue23544@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23544>
_______________________________________

From report at bugs.python.org  Fri Nov 15 01:52:34 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 15 Nov 2019 06:52:34 +0000
Subject: [issue23544] IDLE hangs when selecting Stack View with debug active
In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za>
Message-ID: <1573800754.36.0.303635712687.issue23544@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23544>
_______________________________________

From report at bugs.python.org  Fri Nov 15 02:06:57 2019
From: report at bugs.python.org (Zach kuunka)
Date: Fri, 15 Nov 2019 07:06:57 +0000
Subject: [issue38808] weird bug while using a for loop and array
Message-ID: <1573801617.55.0.5716631107.issue38808@roundup.psfhosted.org>


New submission from Zach kuunka <zach.kunka at gmail.com>:

I haven't used this bug reporting thing before so sorry if I mess something up.

Anyway i'm not sure exactly what is causing the issue but the issue appears when you have a for loop looping through an array and you make a variable and set it to that array and append something to it. If you do the same thing with numbers it works as expected but if you do it with an array it for some reason doesn't get reset every iteration. Run this and you'll see what i'm talking about.

Arr = [1,2,3,4,5]
for num in Arr:
    Arr2 = Arr
    Arr2.append(1) #the 1 can be anything
    print(Arr2)

Also i'm interested to know why this happens, Thank You

----------
components: Library (Lib)
files: brokentest.py
messages: 356648
nosy: Zach kuunka
priority: normal
severity: normal
status: open
title: weird bug while using a for loop and array
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48716/brokentest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38808>
_______________________________________

From report at bugs.python.org  Fri Nov 15 02:23:47 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 07:23:47 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
Message-ID: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>


New submission from Tal Einat <taleinat at gmail.com>:

On windows several .bat scripts call find_python.bat to find an appropriate python.exe. find_python.bat has no specific support for virtual envs, and usually ends up calling py.exe to find python.exe. Due to virtual envs not including a py.exe, this effectively ignores having an activated virtual env.

It is currently possible to build with the specific python that one wants by setting the PYTHON env var. However, this is a simplistic and non-standard solution compared to virtual envs.

IMO when there is an active virtual env, these scripts should certainly use python.exe from it!

----------
assignee: docs at python
components: Documentation
messages: 356649
nosy: docs at python, taleinat
priority: normal
severity: normal
status: open
title: On Windows, build scripts should prefer using python.exe from an active virtual env
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Fri Nov 15 02:23:55 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 07:23:55 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1573802635.58.0.132012056072.issue38809@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
components: +Build -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Fri Nov 15 02:29:15 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 07:29:15 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1573802955.79.0.768950259338.issue38809@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Fri Nov 15 02:36:36 2019
From: report at bugs.python.org (Zach kuunka)
Date: Fri, 15 Nov 2019 07:36:36 +0000
Subject: [issue38808] weird bug while using a for loop and array
In-Reply-To: <1573801617.55.0.5716631107.issue38808@roundup.psfhosted.org>
Message-ID: <1573803396.44.0.0124945775199.issue38808@roundup.psfhosted.org>


Zach kuunka <zach.kunka at gmail.com> added the comment:

I found out it just happens when you set an array to an array they behave as the same thing, which if its not a bug it sure is counter-intuitive. 

if you do
x = 1
then 
y = x
then add one to y you have y = 2 and x = 1
if you do it for an array
arr1 = [1]
then set something equal to that
arr2 = arr1
you essentially have 1 var that act on each other which is odd
so arr2.append(2) or arr1.append(2) make both arr1 and arr2 equal to the same thing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38808>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:25:52 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Nov 2019 08:25:52 +0000
Subject: [issue38808] weird bug while using a for loop and array
In-Reply-To: <1573801617.55.0.5716631107.issue38808@roundup.psfhosted.org>
Message-ID: <1573806352.89.0.904100447097.issue38808@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This isn't a bug: it's the way that Python's assignment model works.

This is explained in various places (including the official Python documentation), but you may find this excellent presentation by Ned Batchelder useful: https://nedbatchelder.com/text/names1.html

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38808>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:27:18 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 08:27:18 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1573806438.51.0.267181002932.issue38809@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
assignee: docs at python -> 
nosy:  -docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:27:26 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 08:27:26 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1573806446.76.0.224626313768.issue38809@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:30:33 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 08:30:33 +0000
Subject: [issue23544] IDLE hangs when selecting Stack View with debug active
In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za>
Message-ID: <1573806633.26.0.843193774983.issue23544@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Taking this in a different direction, perhaps we can make the stack viewer always work, regardless of whether it is immediately after an exception? Visually inspecting the stack can be useful not just for understanding error cases.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23544>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:32:13 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 08:32:13 +0000
Subject: [issue23544] IDLE hangs when selecting Stack View with debug active
In-Reply-To: <1425072335.83.0.576854566256.issue23544@psf.upfronthosting.co.za>
Message-ID: <1573806733.81.0.970945356629.issue23544@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

> perhaps we can make the stack viewer always work

Well, perhaps not "always", e.g. probably not while user code is running.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23544>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:33:40 2019
From: report at bugs.python.org (Andy Maier)
Date: Fri, 15 Nov 2019 08:33:40 +0000
Subject: [issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Message-ID: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>


New submission from Andy Maier <andreas.r.maier at gmx.de>:

A user of our pywbem package gets an SSLError with message "[SSL] EC lib (_ssl.c:728)" when invoking the connect() method on an SSL wrapped socket. See https://github.com/pywbem/pywbem/issues/1950.

The issue is that with this error message, it is not possible for us to figure out what the problem is and how to correct it.

This happens with CPython 3.5.

I have tried to find the place in _ssl.c (https://github.com/python/cpython/blob/3.5/Modules/_ssl.c) where a string "EC lib" or " lib" is created but did not find it there.

I have two requests:

1. Please explain what the reason is for this exception and what to change in the environment to make it work.

2. Please improve the message in this exception so that it is self-explanatory.

----------
assignee: christian.heimes
components: SSL
messages: 356654
nosy: andymaier, christian.heimes
priority: normal
severity: normal
status: open
title: SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38810>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:43:34 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2019 08:43:34 +0000
Subject: [issue38677] Arraymodule initialization error handling improvements
In-Reply-To: <1572823622.93.0.752200478354.issue38677@roundup.psfhosted.org>
Message-ID: <1573807414.82.0.369676372546.issue38677@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b44ffc8b409fd539c5fb2b79385498e9fe168880 by Serhiy Storchaka (Marco Paolini) in branch 'master':
bpo-38677: Fix arraymodule error handling in module initialization. (GH-17039)
https://github.com/python/cpython/commit/b44ffc8b409fd539c5fb2b79385498e9fe168880


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38677>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:43:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2019 08:43:39 +0000
Subject: [issue38800] Resume position for UTF-8 codec error handler not working
In-Reply-To: <1573741824.98.0.130776319775.issue38800@roundup.psfhosted.org>
Message-ID: <1573807419.62.0.96125970548.issue38800@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38800>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:44:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2019 08:44:37 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
In-Reply-To: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>
Message-ID: <1573807477.31.0.11694648811.issue38749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was confirmed that it is an SQLite bug, and it will be fixed in the next SQLite bugfix release.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:44:46 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2019 08:44:46 +0000
Subject: [issue38749] sqlite3 driver fails on four byte unicode strings coming
 from JSON_EXTRACT
In-Reply-To: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>
Message-ID: <1573807486.79.0.202120003825.issue38749@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38749>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:52:55 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Nov 2019 08:52:55 +0000
Subject: [issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
In-Reply-To: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>
Message-ID: <1573807975.17.0.738102794993.issue38810@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The error message is coming from OpenSSL, not from Python. It looks like the handshake is failing with a problem in OpenSSL's internal elliptic curve crypto. It usually means that the server is sending handshake parameters or certs that the client cannot process. It could be a problem with key agreement with ECDHE or cert validation with an EC cert.

It's impossible to say what exactly is going wrong. I suggest that you start by debugging the issue with openssl s_client, Wireshark and gdb on the system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38810>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:55:45 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 08:55:45 +0000
Subject: [issue38677] Arraymodule initialization error handling improvements
In-Reply-To: <1572823622.93.0.752200478354.issue38677@roundup.psfhosted.org>
Message-ID: <1573808145.31.0.804218381447.issue38677@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16675
pull_request: https://github.com/python/cpython/pull/17166

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38677>
_______________________________________

From report at bugs.python.org  Fri Nov 15 03:59:04 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Nov 2019 08:59:04 +0000
Subject: [issue38651] Add WolfSSL support
In-Reply-To: <1572467995.9.0.965883938595.issue38651@roundup.psfhosted.org>
Message-ID: <1573808344.6.0.668884595649.issue38651@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Brett is correct.

We don't have the capacity to develop, maintain, and test with another TLS library. I'm basically the only person that maintains the ssl module at the moment.

I might be inclined to accept patches that improves compatibility with WolfSSL's OpenSSL compatibility layer -- if and only if the patches are minimal and don't make the code harder to read or maintain.

----------
assignee: christian.heimes -> 
type:  -> enhancement
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38651>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:02:34 2019
From: report at bugs.python.org (Andy Maier)
Date: Fri, 15 Nov 2019 09:02:34 +0000
Subject: [issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
In-Reply-To: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>
Message-ID: <1573808554.91.0.969369334322.issue38810@roundup.psfhosted.org>


Andy Maier <andreas.r.maier at gmx.de> added the comment:

More details about the environment this happens on:

Python 3.5.7 (default, Aug 16 2019, 10:17:32)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38810>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:03:50 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 09:03:50 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573808630.44.0.0403959411972.issue38351@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset e8acc865a3f112b98417f676c897ca6ec2dac2c7 by Tal Einat (Andrey Doroschenko) in branch 'master':
bpo-38351: Modernize email examples from %-formatting to f-strings (GH-17162)
https://github.com/python/cpython/commit/e8acc865a3f112b98417f676c897ca6ec2dac2c7


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:03:59 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 09:03:59 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573808639.48.0.360505260671.issue38351@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16676
pull_request: https://github.com/python/cpython/pull/17167

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:04:06 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 09:04:06 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573808646.44.0.457784521855.issue38351@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16677
pull_request: https://github.com/python/cpython/pull/17168

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:11:51 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 09:11:51 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573809111.64.0.515168166848.issue38351@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dae27cc8e72106c2eceeff9af83d1e58b2bb68d5 by Miss Islington (bot) in branch '3.8':
bpo-38351: Modernize email examples from %-formatting to f-strings (GH-17162)
https://github.com/python/cpython/commit/dae27cc8e72106c2eceeff9af83d1e58b2bb68d5


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:13:21 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Nov 2019 09:13:21 +0000
Subject: [issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
In-Reply-To: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>
Message-ID: <1573809201.73.0.915023776127.issue38810@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

This looks like a self-compiled Python 3.5 on an ancient, unsupported RHEL 4 box. What's the OpenSSL version of the machine and the server?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38810>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:14:47 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 09:14:47 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573809287.71.0.46702030283.issue38351@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fe67a5354010f33128c4f461da8ffb925e0f4de8 by Miss Islington (bot) in branch '3.7':
bpo-38351: Modernize email examples from %-formatting to f-strings (GH-17162)
https://github.com/python/cpython/commit/fe67a5354010f33128c4f461da8ffb925e0f4de8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:16:14 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 09:16:14 +0000
Subject: [issue38351] Modernize email example from %-formatting to f-string
In-Reply-To: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>
Message-ID: <1573809374.4.0.538021865703.issue38351@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for the PR, Andrey!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:26:27 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Nov 2019 09:26:27 +0000
Subject: [issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
In-Reply-To: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>
Message-ID: <1573809987.82.0.669142805728.issue38810@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Sorry, Kernel version 4.4.7 is RHEL 6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38810>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:33:51 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Nov 2019 09:33:51 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573810431.77.0.961441864378.issue38794@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Since this is a request for a new feature, I'm bumping versions to 3.9 and newer.

There is no need to add more configure flags to build Python with a custom OpenSSL installation. It's sufficient to build OpenSSL as a shared library and run Python's configure with --with-openssl=/path/to/installed/openssl. Then it's just a matter to configure libdl to load the correct libraries, e.g. with a custom rpath. I like to use LD_RUN_PATH to add an rpath to the ELF header of the _ssl and _hashlib module's shared library. Or you can use Tools/ssl/multissl.py to automate this.

This approach works fine on RHEL 6:

wget https://www.openssl.org/source/openssl-1.0.2t.tar.gz
tar -xzf openssl-1.0.2t.tar.gz
pushd openssl-1.0.2t
./config --openssldir=/etc/pki/tls --prefix=/tmp/102t shared
make
make install
popd

wget https://www.python.org/ftp/python/3.7.5/Python-3.7.5.tgz
tar -xzf Python-3.7.5.tgz
pushd Python-3.7.5
export LD_RUN_PATH=/tmp/102t/lib
./configure --with-openssl=/tmp/102t/ -C
unset LD_RUN_PATH

ldd build/lib.linux-x86_64-3.7/_ssl.cpython-37m-x86_64-linux-gnu.so 
        linux-vdso.so.1 =>  (0x00007ffcefbb7000)
        libssl.so.1.0.0 => /tmp/102t/lib/libssl.so.1.0.0 (0x00007f4c586a7000)
        libcrypto.so.1.0.0 => /tmp/102t/lib/libcrypto.so.1.0.0 (0x00007f4c5826a000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4c58047000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4c57cb3000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f4c57aae000)
        /lib64/ld-linux-x86-64.so.2 (0x00005639623f7000)

./python 
Python 3.7.5 (default, Nov 15 2019, 04:19:28) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-23)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2t  10 Sep 2019'


I'm opposing this PR because it's an unnecessary extension that increases our testing, documentation and support burden. We would have to maintain the feature for at least 5 to 10 years and ensure that it keeps working on all operating systems (also BSD, macOS, AIX, ...) and future versions of OpenSSL.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:37:32 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 09:37:32 +0000
Subject: [issue38677] Arraymodule initialization error handling improvements
In-Reply-To: <1572823622.93.0.752200478354.issue38677@roundup.psfhosted.org>
Message-ID: <1573810652.04.0.123767818751.issue38677@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 25ce77dd2455abbb6e2c9e055bbc98954642fa7c by Miss Islington (bot) in branch '3.8':
bpo-38677: Fix arraymodule error handling in module initialization. (GH-17039)
https://github.com/python/cpython/commit/25ce77dd2455abbb6e2c9e055bbc98954642fa7c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38677>
_______________________________________

From report at bugs.python.org  Fri Nov 15 04:43:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2019 09:43:06 +0000
Subject: [issue38677] Arraymodule initialization error handling improvements
In-Reply-To: <1572823622.93.0.752200478354.issue38677@roundup.psfhosted.org>
Message-ID: <1573810986.01.0.498151971366.issue38677@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38677>
_______________________________________

From report at bugs.python.org  Fri Nov 15 05:04:06 2019
From: report at bugs.python.org (Lukas Vacek)
Date: Fri, 15 Nov 2019 10:04:06 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573812246.19.0.565485188774.issue38794@roundup.psfhosted.org>


Lukas Vacek <lucas.vacek at gmail.com> added the comment:

Fair enough.

Btw. I picked versions 3.7 and up to show this feature should eventually be backported to older CPython versions that depend on OpenSSL >= 1.0.2. 

This feature is to avoid relying on rpath and relying on a seperate installation to be installed in specific location in your target system. Also there is no Tools/ssl/multissl.py in current cpython master.

I believe it's much preferably for administrators to use static linking in this case, but if you think it's not worth it, that's fine. Please close the related PR in the github with your explanation. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Fri Nov 15 05:26:16 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 15 Nov 2019 10:26:16 +0000
Subject: [issue38591] Deprecate Process Child Watchers
In-Reply-To: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>
Message-ID: <1573813576.9.0.944251882789.issue38591@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

> So are we at least in agreement for starting with deprecating FastChildWatcher?

I think so. It will take a long before we remove it though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38591>
_______________________________________

From report at bugs.python.org  Fri Nov 15 07:04:34 2019
From: report at bugs.python.org (=?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Fri, 15 Nov 2019 12:04:34 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
Message-ID: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>


New submission from Toke H?iland-J?rgensen <toke at toke.dk>:

Commit 6b5b013bcc22 ("bpo-26978: Implement pathlib.Path.link_to (Using os.link) (GH-12990)") introduced a new link_to method in pathlib. However, this makes pathlib crash when the 'os' module is missing a 'link' method, as can be seen in the report in this CI test:

https://travis-ci.org/tohojo/flent/jobs/611950252

----------
components: Library (Lib)
messages: 356670
nosy: tohojo
priority: normal
severity: normal
status: open
title: Pathlib crashes when os module is missing 'link' method
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Fri Nov 15 07:10:12 2019
From: report at bugs.python.org (=?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Fri, 15 Nov 2019 12:10:12 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1573819812.99.0.422319873624.issue38811@roundup.psfhosted.org>


Change by Toke H?iland-J?rgensen <toke at toke.dk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Fri Nov 15 07:10:13 2019
From: report at bugs.python.org (=?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Fri, 15 Nov 2019 12:10:13 +0000
Subject: [issue26978] Implement pathlib.Path.link (Using os.link)
In-Reply-To: <1556420459.86.0.258434208738.issue26978@roundup.psfhosted.org>
Message-ID: <1573819813.09.0.970261109374.issue26978@roundup.psfhosted.org>


Change by Toke H?iland-J?rgensen <toke at toke.dk>:


----------
pull_requests: +16679
pull_request: https://github.com/python/cpython/pull/17170

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26978>
_______________________________________

From report at bugs.python.org  Fri Nov 15 08:03:48 2019
From: report at bugs.python.org (Arthit Suriyawongkul)
Date: Fri, 15 Nov 2019 13:03:48 +0000
Subject: [issue29620] unittest.TestCase.assertWarns raises RuntimeEror if
 sys.modules changes size
In-Reply-To: <1487780571.93.0.503711972358.issue29620@psf.upfronthosting.co.za>
Message-ID: <1573823028.91.0.900224541775.issue29620@roundup.psfhosted.org>


Arthit Suriyawongkul <arthit at gmail.com> added the comment:

Confirmed this behavior on
- Python 3.6.8 64-bit on Windows Server 2016 (AppVeyor "Visual Studio 2017" build environment)
- Python 3.6.7 64-bit on Linux

----------
nosy: +Arthit Suriyawongkul

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29620>
_______________________________________

From report at bugs.python.org  Fri Nov 15 08:21:36 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 15 Nov 2019 13:21:36 +0000
Subject: [issue38591] Deprecate Process Child Watchers
In-Reply-To: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>
Message-ID: <1573824096.79.0.730638797713.issue38591@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I think so. It will take a long before we remove it though.

In that case, it could be a long term deprecation notice, where we start the deprecation process without having a definitive removal version. This will at least encourage users to look towards using the other watchers instead of FastChildWatcher. I can start working on a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38591>
_______________________________________

From report at bugs.python.org  Fri Nov 15 08:30:11 2019
From: report at bugs.python.org (Mike)
Date: Fri, 15 Nov 2019 13:30:11 +0000
Subject: [issue38812] Comparing datetime.time objects incorrect for TZ aware
 and unaware
Message-ID: <1573824611.55.0.420390589696.issue38812@roundup.psfhosted.org>


New submission from Mike <mikesutton at gmail.com>:

import pytz
import datetime

tzaware_time1 = datetime.time(7,30,tzinfo=pytz.timezone("America/Denver"))
tzaware_time2 = datetime.time(7,30,tzinfo=pytz.utc)

tzunaware_time = datetime.time(7, 30)

# This fails with exception: TypeError: can't compare offset-naive and offset-aware times
# even though both ARE tz aware.
tzaware_time1 < tzaware_time2

# This does NOT raise an exception and should since one is aware and one isn't.
tzunaware_time < tzaware_time1

----------
messages: 356673
nosy: epicadv
priority: normal
severity: normal
status: open
title: Comparing datetime.time objects incorrect for TZ aware and unaware
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38812>
_______________________________________

From report at bugs.python.org  Fri Nov 15 08:47:52 2019
From: report at bugs.python.org (Zach kuunka)
Date: Fri, 15 Nov 2019 13:47:52 +0000
Subject: [issue38808] weird bug while using a for loop and array
In-Reply-To: <1573801617.55.0.5716631107.issue38808@roundup.psfhosted.org>
Message-ID: <1573825672.05.0.257853198014.issue38808@roundup.psfhosted.org>


Zach kuunka <zach.kunka at gmail.com> added the comment:

I will check that out, Thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38808>
_______________________________________

From report at bugs.python.org  Fri Nov 15 09:10:28 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 15 Nov 2019 14:10:28 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573827028.37.0.609987394256.issue22367@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

@corona10

The AIX bot's are also in the red zone with PR17010.

This was examined earlier See: https://bugs.python.org/issue35633#msg333662

In short, the recommendation by Victor was to skip the test: quote:
> On AIX the test for flock() passes, but the test for lockf() fails: (...)

I would prefer to simply skip the lockf() test rather than ignoring PermissionError for flock() and lockf() on all platforms. 

And so,  Lib/test/eintrdata/eintr_tester.py now has:

    @unittest.skipIf(platform.system() == "AIX", "AIX returns PermissionError")
    def test_lockf(self):
        self._lock(fcntl.lockf, "lockf")


Thanks for your understanding.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 15 09:19:30 2019
From: report at bugs.python.org (Lukas Vacek)
Date: Fri, 15 Nov 2019 14:19:30 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573827570.44.0.907215833633.issue38794@roundup.psfhosted.org>


Lukas Vacek <lucas.vacek at gmail.com> added the comment:

However, I'm still convinced many would appreciate adding this ./configure option:

https://github.com/pyenv/pyenv/issues/1184#issuecomment-403149437
https://joshspicer.com/python37-ssl-issue
https://superuser.com/questions/1428109/install-python-3-7-3-from-source-with-ssl-failed
https://raspberrypi.stackexchange.com/questions/88150/how-to-install-python-3-7-with-ssl
https://stackoverflow.com/questions/53543477/building-python-3-7-1-ssl-module-failed
https://help.dreamhost.com/hc/en-us/articles/115000702772-Installing-a-custom-version-of-Python-3#3.7.1
https://stackoverflow.com/questions/55928393/compile-python-3-6-statically-with-openssl
https://readthisblog.net/2018/08/13/til-how-to-build-python-3-7-with-statically-linked-libssl-and-libcrypto/
https://gist.github.com/eddy-geek/9604982

If you look at the associated PR you will see it should work fine, and be useful, on other POSIX systems as well. I can test on *BSD if necessary.

Only extra depedency of --with-openssl-static compared to --with-openssl is an assumption of existing files libssl.a libcrypto.a and OpenSSL has provided these files (when compiled static) since the very beginning despite somewhat frequent ABI changes. Option --with-openssl-static works with current libressl as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Fri Nov 15 09:33:24 2019
From: report at bugs.python.org (Jim Carroll)
Date: Fri, 15 Nov 2019 14:33:24 +0000
Subject: [issue23407] os.walk always follows Windows junctions
In-Reply-To: <1423342763.81.0.179122512075.issue23407@psf.upfronthosting.co.za>
Message-ID: <1573828404.67.0.146430779219.issue23407@roundup.psfhosted.org>


Jim Carroll <jim at carroll.com> added the comment:

I can confirm the os.walk() behavior still exists on 3.8. Just curious on the status of the patch?

----------
nosy: +jamercee

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23407>
_______________________________________

From report at bugs.python.org  Fri Nov 15 09:34:47 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 15 Nov 2019 14:34:47 +0000
Subject: [issue21767] singledispatch docs should explicitly mention support
 for abstract base classes
In-Reply-To: <1402804826.39.0.801339966603.issue21767@psf.upfronthosting.co.za>
Message-ID: <1573828487.82.0.127214559584.issue21767@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21767>
_______________________________________

From report at bugs.python.org  Fri Nov 15 09:39:50 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 15 Nov 2019 14:39:50 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573828790.94.0.46435708185.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@Michael.Felt

Thanks for the suggestion.
I 've updated the PR to skip the test on AIX.

cc @vstinner

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 15 09:58:26 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Nov 2019 14:58:26 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573829906.35.0.115701165047.issue38794@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I'm drawing a different conclusion from these posts. It sounds to me like people want a simple way to install a new version of Python on old distros and have a working ssl module. Static linking is one possible way to archive the goal. I argue that it is not necessarily the best way, especially in the light of OpenSSL 3.0.0, dynamic engines and the new crypto providers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Fri Nov 15 09:59:10 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 15 Nov 2019 14:59:10 +0000
Subject: [issue7687] Bluetooth support untested
In-Reply-To: <1263367703.76.0.187821272753.issue7687@psf.upfronthosting.co.za>
Message-ID: <1573829950.51.0.846157023117.issue7687@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7687>
_______________________________________

From report at bugs.python.org  Fri Nov 15 10:02:01 2019
From: report at bugs.python.org (aikimark1955)
Date: Fri, 15 Nov 2019 15:02:01 +0000
Subject: [issue38813] math.modf() change integer returned part as integer
 instead of float
Message-ID: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>


New submission from aikimark1955 <aikimark1955 at gmail.com>:

The description for this function reads:
"Return the fractional and integer parts of x. Both results carry the sign of x and are floats."

Since the second returned value is "integer parts", I submit that the value should be integer.

----------
components: Library (Lib)
messages: 356680
nosy: aikimark1955
priority: normal
severity: normal
status: open
title: math.modf() change integer returned part as integer instead of float
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________

From report at bugs.python.org  Fri Nov 15 10:03:00 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 15 Nov 2019 15:03:00 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1573830180.35.0.792900379961.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Dear Core developers

Although I updated the unit test for this issue if the reverting is a better way. Please let me know.
I am happy to follow the decision. :)

Thanks always

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 15 10:14:43 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 15 Nov 2019 15:14:43 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1573830883.56.0.13433016324.issue3530@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Fri Nov 15 10:20:49 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 15 Nov 2019 15:20:49 +0000
Subject: [issue35453] pathlib.Path: glob and rglob should accept PathLike
 patterns
In-Reply-To: <1544439282.17.0.788709270274.issue35453@psf.upfronthosting.co.za>
Message-ID: <1573831249.34.0.201981307678.issue35453@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@nanjekyejoannah, are you still interested in adding tests or can i add tests?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 10:41:48 2019
From: report at bugs.python.org (Lukas Vacek)
Date: Fri, 15 Nov 2019 15:41:48 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573832508.14.0.96970637269.issue38794@roundup.psfhosted.org>


Lukas Vacek <lucas.vacek at gmail.com> added the comment:

In ideal world OpenSSL would provide stable ABI just like the other libraries Python depends on. That would be, unarguably, the best way to achieve that goal. Agreed.

Aferall frequent OpenSSL ABI breakages are the reason why apple switched to their own cryptography ABI (https://developer.apple.com/library/archive/documentation/Security/Conceptual/cryptoservices/SecureNetworkCommunicationAPIs/SecureNetworkCommunicationAPIs.html):

"""
Although OpenSSL is commonly used in the open source community, it doesn?t provide a stable API from version to version. For this reason, the programmatic interface to OpenSSL is deprecated in macOS and is not provided in iOS. Use of the Apple-provided OpenSSL libraries by apps is strongly discouraged.

To ensure compatibility, if your app depends on OpenSSL, you should compile it yourself and statically link a known version of OpenSSL into your app. Such use works on both iOS and macOS.
"""

However, OpenSSL does not provide stable ABI and Python should deal with that as nicely as possible. If you can think of a better real world solution than static linking OpenSSL please share and let's do it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Fri Nov 15 10:56:23 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 15 Nov 2019 15:56:23 +0000
Subject: [issue35453] pathlib.Path: glob and rglob should accept PathLike
 patterns
In-Reply-To: <1544439282.17.0.788709270274.issue35453@psf.upfronthosting.co.za>
Message-ID: <1573833383.73.0.884498194362.issue35453@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

@BTaskaya From what I see, there is no consensus yet.If you are interested in exploring, go on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:16:10 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Nov 2019 16:16:10 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573834570.39.0.666938702174.issue38794@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

> In ideal world OpenSSL would provide stable ABI just like the other libraries Python depends on. That would be, unarguably, the best way to achieve that goal. Agreed.

OpenSSL provides a stable API and stable ABI already. The fact is well documented at https://www.openssl.org/policies/releasestrat.html. Python is not compatible with ancient, unsupported OpenSSL versions 1.0.1 and earlier because Python requires features that were introduced in OpenSSL 1.0.2.

> However, OpenSSL does not provide stable ABI and Python should deal with that as nicely as possible. If you can think of a better real world solution than static linking OpenSSL please share and let's do it!

That's a) incorrect, b) not related to this issue.

You are trying to solve a problem by dictating the solution at the same time. Could you please start with a high level explanation of the problem and let us figure out a viable solution?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:31:52 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Nov 2019 16:31:52 +0000
Subject: [issue38813] math.modf() change integer returned part as integer
 instead of float
In-Reply-To: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>
Message-ID: <1573835512.29.0.453063659388.issue38813@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This is odd.  The underlying C library modf() returns an integer for the second part.  Likewise the Python math.frexp() function returns an integer for the second part.  So, I'm not sure why Python's math.modf() returns a float for the second field.

----------
nosy: +mark.dickinson, rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:34:20 2019
From: report at bugs.python.org (Alex)
Date: Fri, 15 Nov 2019 16:34:20 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1573835660.92.0.214954678994.issue11354@roundup.psfhosted.org>


Alex <alexpclarkson at gmail.com> added the comment:

Weighing up how little demand there seems to be for this, and how easy it is to achieve the same effect with post-processing within a hypothetical script that happens to need it - I agree with closing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:36:10 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Nov 2019 16:36:10 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1573835770.98.0.590690764888.issue25866@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Can you please turn this into a regular PR?

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:47:28 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=)
Date: Fri, 15 Nov 2019 16:47:28 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
Message-ID: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>


New submission from L?szl? K?rolyi <laszlo at karolyi.hu>:

Hey,

I have a huge Django project that starts up fine with the dev server on Linux and in production that is also Linux. Whenever I try to start it on my OSX, the python process crashes with a SIGABRT and I get a crash window from OSX.

I use homebrew with the latest packages and python3.7.5 is now compiled from source, to avoid dependency problems.

Here's the log:
Process:               Python [85125]
Path:                  /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.7.5 (3.7.5)
Code Type:             X86-64 (Native)
Parent Process:        fish [1857]
Responsible:           Terminal [1732]
User ID:               501

Date/Time:             2019-11-15 17:39:46.178 +0100
OS Version:            Mac OS X 10.15.1 (19B88)
Report Version:        12
Anonymous UUID:        CC50B63E-FBC1-6461-576B-EE6AF1E52EFE

Sleep/Wake UUID:       A2774262-4258-4B95-8AAF-642CDEF9014E

Time Awake Since Boot: 280000 seconds
Time Since Wake:       710 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Abort trap: 6
Termination Reason:    Namespace SIGNAL, Code 0x6
Terminating Process:   Python [85125]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff67936e1a __kill + 10
1   org.python.python             	0x0000000100ab0614 os_kill + 57
2   org.python.python             	0x00000001009d910c _PyMethodDef_RawFastCallKeywords + 488
3   org.python.python             	0x00000001009d8698 _PyCFunction_FastCallKeywords + 41
4   org.python.python             	0x0000000100a6cfd0 call_function + 628
5   org.python.python             	0x0000000100a65fab _PyEval_EvalFrameDefault + 6767
6   org.python.python             	0x00000001009d8a6c function_code_fastcall + 106
7   org.python.python             	0x0000000100a6d03d call_function + 737
8   org.python.python             	0x0000000100a66046 _PyEval_EvalFrameDefault + 6922
9   org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
10  org.python.python             	0x00000001009d8660 _PyFunction_FastCallKeywords + 212
11  org.python.python             	0x0000000100a6d03d call_function + 737
12  org.python.python             	0x0000000100a65fab _PyEval_EvalFrameDefault + 6767
13  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
14  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
15  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
16  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
17  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
18  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
19  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
20  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
21  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
22  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
23  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
24  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
25  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
26  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
27  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
28  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
29  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
30  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
31  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
32  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
33  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
34  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
35  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
36  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
37  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
38  org.python.python             	0x00000001009d8a6c function_code_fastcall + 106
39  org.python.python             	0x0000000100a6d03d call_function + 737
40  org.python.python             	0x0000000100a65f92 _PyEval_EvalFrameDefault + 6742
41  org.python.python             	0x00000001009d8a6c function_code_fastcall + 106
42  org.python.python             	0x0000000100a6d03d call_function + 737
43  org.python.python             	0x0000000100a65f92 _PyEval_EvalFrameDefault + 6742
44  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
45  org.python.python             	0x00000001009d8660 _PyFunction_FastCallKeywords + 212
46  org.python.python             	0x0000000100a6d03d call_function + 737
47  org.python.python             	0x0000000100a66046 _PyEval_EvalFrameDefault + 6922
48  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
49  org.python.python             	0x0000000100a64499 PyEval_EvalCode + 51
50  org.python.python             	0x0000000100a928ac run_mod + 54
51  org.python.python             	0x0000000100a918df PyRun_FileExFlags + 160
52  org.python.python             	0x0000000100a90f96 PyRun_SimpleFileExFlags + 270
53  org.python.python             	0x0000000100aa97a6 pymain_main + 5445
54  org.python.python             	0x0000000100aa9e14 _Py_UnixMain + 56
55  libdyld.dylib                 	0x00007fff677e72e5 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000000  rcx: 0x00007ffeef243cc8  rdx: 0x0000000000000000
  rdi: 0x0000000000014c85  rsi: 0x0000000000000006  rbp: 0x00007ffeef243cf0  rsp: 0x00007ffeef243cc8
   r8: 0x00007ffeef243ca0   r9: 0x00007ffeef243ab0  r10: 0xdc0cf600294c00e7  r11: 0x0000000000000202
  r12: 0x0000000000000002  r13: 0x0000000100b7dcd0  r14: 0x00000001059807b8  r15: 0x0000000000000002
  rip: 0x00007fff67936e1a  rfl: 0x0000000000000202  cr2: 0x0000000100d10cd0
  
Logical CPU:     0
Error Code:      0x02000025
Trap Number:     133


Binary Images:
       0x1009b9000 -        0x1009bafff +org.python.python (3.7.5 - 3.7.5) <B5F1E051-7FCA-3D74-951A-BE7A9F61FC71> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
       0x1009be000 -        0x100b41ff7 +org.python.python (3.7.5, [c] 2001-2019 Python Software Foundation. - 3.7.5) <8F5D3863-C59D-3482-9562-E638BBE51C7B> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Python
       0x100c25000 -        0x100c2dffb +libintl.8.dylib (0) <CD236902-DB50-39BB-86BB-E9F0D22E5649> /usr/local/opt/gettext/lib/libintl.8.dylib
       0x100f3f000 -        0x100f40fff +_heapq.cpython-37m-darwin.so (0) <D9ED900B-8F58-39EA-9B28-6F5B4F9B8A4C> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so
       0x100f91000 -        0x100f95ff3 +math.cpython-37m-darwin.so (0) <F10DD1FB-1020-3E26-99BE-481CCE0E591E> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so
       0x100f9c000 -        0x100fa7ffb +_datetime.cpython-37m-darwin.so (0) <0141A985-844A-358F-8F09-12AB8D1F1028> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_datetime.cpython-37m-darwin.so
       0x100ff0000 -        0x100ff1fff +_posixsubprocess.cpython-37m-darwin.so (0) <FB0FC9AD-8D80-31A2-B979-41723DBBA055> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so
       0x100ff5000 -        0x100ff7fff +select.cpython-37m-darwin.so (0) <579B856F-9A34-3A9B-9EAA-D64140E5FE72> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so
       0x1010bd000 -        0x1010c0fff +_struct.cpython-37m-darwin.so (0) <A12A931E-0887-30C0-9870-7A549EC9C228> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_struct.cpython-37m-darwin.so
       0x101110000 -        0x10113dff7 +_decimal.cpython-37m-darwin.so (0) <63A6ED2C-C2C5-30C9-B163-7F5A7F0026F7> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_decimal.cpython-37m-darwin.so
       0x1011d0000 -        0x1011d0fff +_opcode.cpython-37m-darwin.so (0) <4204DF40-4EBD-3629-8F28-4794F08FDA1D> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so
       0x101214000 -        0x101217fff +zlib.cpython-37m-darwin.so (0) <E522AD8C-8917-3960-B8CF-DD5CA336D3C3> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/zlib.cpython-37m-darwin.so
       0x10121d000 -        0x10121efff +_bz2.cpython-37m-darwin.so (0) <8B9606FA-4E0E-36E5-9A85-249AE34FF8B5> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bz2.cpython-37m-darwin.so
       0x101223000 -        0x101226ff7 +_lzma.cpython-37m-darwin.so (0) <94313799-237B-3D45-9F65-797A8AC7BD80> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_lzma.cpython-37m-darwin.so
       0x10122c000 -        0x101247ff7 +liblzma.5.dylib (0) <423B98CF-7AF0-325D-AB6A-3F44B56B90C2> /usr/local/opt/xz/lib/liblzma.5.dylib
       0x10124d000 -        0x10124efff +grp.cpython-37m-darwin.so (0) <68DC3970-83D1-3E67-84DD-9129D32657C9> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/grp.cpython-37m-darwin.so
       0x101292000 -        0x101295fff +_hashlib.cpython-37m-darwin.so (0) <00BE40D9-3084-3E6A-8639-DC06F12B3E67> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so
       0x10129a000 -        0x1012e8fff +libssl.1.1.dylib (0) <6E8C5906-2EB3-3F95-9B6D-2C509049EF4C> /usr/local/opt/openssl at 1.1/lib/libssl.1.1.dylib
       0x101311000 -        0x1014ac917 +libcrypto.1.1.dylib (0) <67579E42-401A-3775-B5C6-518E58CC8032> /usr/local/opt/openssl at 1.1/lib/libcrypto.1.1.dylib
       0x10153e000 -        0x101543ffb +_blake2.cpython-37m-darwin.so (0) <768F6BA7-0CAF-3488-9A22-4F185C5EFA7C> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so
       0x101548000 -        0x101558fff +_sha3.cpython-37m-darwin.so (0) <2E31BBA1-CADF-34C9-9863-8A630611FD24> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so
       0x10155e000 -        0x10155efff +_bisect.cpython-37m-darwin.so (0) <387632CC-41B1-3ED6-866D-3C3E44145A82> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bisect.cpython-37m-darwin.so
       0x101562000 -        0x101563ffb +_random.cpython-37m-darwin.so (0) <E8386EAF-C75D-3EAD-92CD-B7EFC9C172A8> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_random.cpython-37m-darwin.so
       0x101727000 -        0x101727fff +_uuid.cpython-37m-darwin.so (0) <8FBE1B4E-252D-321B-A570-D67BEB1C177A> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_uuid.cpython-37m-darwin.so
       0x10172b000 -        0x10172eff7 +binascii.cpython-37m-darwin.so (0) <7A5E1952-82A8-3DB3-9666-7CF04FC52505> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/binascii.cpython-37m-darwin.so
       0x101733000 -        0x101738fff +_json.cpython-37m-darwin.so (0) <284E3EB4-B1A6-3B6A-BD92-7959C77FA60B> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_json.cpython-37m-darwin.so
       0x10177d000 -        0x10187bfff +unicodedata.cpython-37m-darwin.so (0) <4B82ABA9-EFEC-34F0-B899-8958FAB73427> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/unicodedata.cpython-37m-darwin.so
       0x1018c1000 -        0x1018c9ffb +_socket.cpython-37m-darwin.so (0) <AEF9A41E-A27B-3F21-AEE8-3B49603975A4> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_socket.cpython-37m-darwin.so
       0x101b26000 -        0x101b32ffb +_pickle.cpython-37m-darwin.so (0) <D1B91A34-82E4-3534-B358-6166655CB593> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_pickle.cpython-37m-darwin.so
       0x101b3d000 -        0x101b3efff +_speedups.cpython-37m-darwin.so (???) <E9B73517-643A-3FD1-8B18-600595CA2B65> /Users/USER/*/_speedups.cpython-37m-darwin.so
       0x101c73000 -        0x101c80fff +_ssl.cpython-37m-darwin.so (0) <903F2FB6-CCE1-316C-8EA1-15EDF0BF629F> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ssl.cpython-37m-darwin.so
       0x101d0f000 -        0x101d0ffff +_contextvars.cpython-37m-darwin.so (0) <46E84186-1CB7-3F54-901C-66BA82573EC9> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_contextvars.cpython-37m-darwin.so
       0x101d13000 -        0x101d18fff +_asyncio.cpython-37m-darwin.so (0) <1E7DA7FE-894B-3934-B049-6FCBBEF7900C> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_asyncio.cpython-37m-darwin.so
       0x101e62000 -        0x101eb4ff7 +_imaging.cpython-37m-darwin.so (0) <4085C13E-239C-3175-B82E-F5CFE26E4116> /Users/USER/*/_imaging.cpython-37m-darwin.so
       0x101edb000 -        0x101f12fff +libjpeg.9.dylib (0) <5031EBB1-CCBE-37BC-B348-9A899B06AFDB> /Users/USER/*/libjpeg.9.dylib
       0x101f22000 -        0x101f98ffb +libopenjp2.2.3.1.dylib (0) <070B3635-9516-3171-8E04-6F645281C96B> /Users/USER/*/libopenjp2.2.3.1.dylib
       0x101fa3000 -        0x101fbeff7 +libz.1.2.11.dylib (0) <8F57D771-E0DD-3DA4-8241-A90A4B0AE451> /Users/USER/*/libz.1.2.11.dylib
       0x101fc2000 -        0x10204eff3 +libtiff.5.dylib (0) <5A576A29-DE0D-3A70-9D24-F9FFDCA7E14D> /Users/USER/*/libtiff.5.dylib
       0x102060000 -        0x102090fff +liblzma.5.dylib (0) <4E0649AF-77F8-3889-B300-B37ED7E6F40F> /Users/USER/*/liblzma.5.dylib
       0x102118000 -        0x10211dffb +array.cpython-37m-darwin.so (0) <F802200C-DE02-364B-B629-2B1EF8F5B6D4> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/array.cpython-37m-darwin.so
       0x1021e5000 -        0x1021e7fff +mmap.cpython-37m-darwin.so (0) <897B39B2-4A4B-3951-85DE-B7ACBA9CCAEF> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/mmap.cpython-37m-darwin.so
       0x10222c000 -        0x10222dfff +_webp.cpython-37m-darwin.so (0) <47BDF1B7-C4AE-3797-9ABC-60E498C316C5> /Users/USER/*/_webp.cpython-37m-darwin.so
       0x102232000 -        0x1022d5fff +libwebp.7.dylib (0) <D4ECF019-B9CF-3292-AFCB-601122DDC89E> /Users/USER/*/libwebp.7.dylib
       0x1022eb000 -        0x1022f4fff +libwebpmux.3.dylib (0) <A11340E3-D08E-3C8A-B6F1-38C1A57E3926> /Users/USER/*/libwebpmux.3.dylib
       0x1022f9000 -        0x1022fdff3 +libwebpdemux.2.dylib (0) <9A6F6420-BF33-3C19-91D1-E44FA8A60016> /Users/USER/*/libwebpdemux.2.dylib
       0x102400000 -        0x102401fff +fcntl.cpython-37m-darwin.so (0) <B08A0084-F70D-32E5-8F3D-973519CB8564> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/fcntl.cpython-37m-darwin.so
       0x102506000 -        0x102507fff +termios.cpython-37m-darwin.so (0) <1C441858-CD7C-3511-B39E-EED449AF91D1> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/termios.cpython-37m-darwin.so
       0x10268b000 -        0x10268cfff +_queue.cpython-37m-darwin.so (0) <13D55382-1B48-3A23-BECE-AA0F2D58EC85> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_queue.cpython-37m-darwin.so
       0x102a51000 -        0x102a54ffb +_zope_interface_coptimizations.cpython-37m-darwin.so (0) <FE1BC506-E2CF-3985-BB6D-7AA3BB508AD0> /Users/USER/*/_zope_interface_coptimizations.cpython-37m-darwin.so
       0x102b2c000 -        0x102b2dfff +_scproxy.cpython-37m-darwin.so (0) <51EE48B8-345C-36E6-BBC5-61D81C314FF7> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_scproxy.cpython-37m-darwin.so
       0x102c71000 -        0x102c80fff +_ctypes.cpython-37m-darwin.so (0) <E4627CC2-6724-3E16-8671-FC1D19DBFFAD> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ctypes.cpython-37m-darwin.so
       0x10310d000 -        0x10310eff3 +_constant_time.abi3.so (0) <96047CA2-343F-3C1A-A7FC-D5E1A0B3EB93> /Users/USER/*/_constant_time.abi3.so
       0x103111000 -        0x10312bff7 +_cffi_backend.cpython-37m-darwin.so (0) <34A2EC26-072B-399C-9841-6AE90C845EA6> /Users/USER/*/_cffi_backend.cpython-37m-darwin.so
       0x103202000 -        0x103221ffb +pyexpat.cpython-37m-darwin.so (0) <59BC1282-62AE-3A64-BE62-F1A49D627801> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/pyexpat.cpython-37m-darwin.so
       0x10353e000 -        0x103549fff +_curses.cpython-37m-darwin.so (0) <9BDFF609-073B-3058-8CFF-BF03681057D4> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_curses.cpython-37m-darwin.so
       0x10381b000 -        0x10381ffff +_rl_accel.cpython-37m-darwin.so (???) <0946EBBB-1EA5-31E1-8BDF-80FB2562F609> /Users/USER/*/_rl_accel.cpython-37m-darwin.so
       0x103d9d000 -        0x103ea7ffb +_xapian.cpython-37m-darwin.so (0) <563380C8-F629-36E3-90F4-AF5F019D98B2> /Users/USER/*/_xapian.cpython-37m-darwin.so
       0x103f1b000 -        0x1040c3ffb +libxapian.30.dylib (0) <0CAAC96B-A84A-3B91-B33B-7FD8B4619C52> /Users/USER/*/libxapian.30.dylib
       0x1042aa000 -        0x1042aeff3 +_mysql.cpython-37m-darwin.so (0) <E2FE87E2-12E6-3180-B796-42F8624CB13B> /Users/USER/*/_mysql.cpython-37m-darwin.so
       0x1042ba000 -        0x1042dfff7 +libmariadb.3.dylib (0) <FDD5A5C4-184D-3E24-AF99-828EB6B05F8B> /usr/local/opt/mariadb/lib/libmariadb.3.dylib
       0x1042f6000 -        0x104334fff +libssl.1.0.0.dylib (0) <72760F74-3638-3B29-BE57-203A9FFC2665> /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
       0x104351000 -        0x1044a3f77 +libcrypto.1.0.0.dylib (0) <05A68FDC-631D-3FB6-BB02-507CF6E68F43> /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib
       0x1049be000 -        0x1049c3ff7 +hiredis.cpython-37m-darwin.so (???) <05C8B52F-6DE8-3742-942E-4DAA00EF40CE> /Users/USER/*/hiredis.cpython-37m-darwin.so
       0x104b48000 -        0x104fadfff +etree.cpython-37m-darwin.so (???) <3886C02D-DC32-3A51-93EE-1C2E3C6B0347> /Users/USER/*/etree.cpython-37m-darwin.so
       0x1051cd000 -        0x1051edfff +_elementpath.cpython-37m-darwin.so (???) <429F29F9-50B3-33CC-9E45-AEDA036695FB> /Users/USER/*/_elementpath.cpython-37m-darwin.so
       0x105208000 -        0x105209fff +_rjsmin.cpython-37m-darwin.so (0) <3F5A1F2F-1640-3709-8AB3-8FC933B5A009> /Users/USER/*/_rjsmin.cpython-37m-darwin.so
       0x10564e000 -        0x105655ff7 +_speedups.cpython-37m-darwin.so (0) <05FB9B57-657C-3F07-BC3C-790E85B8E84F> /Users/USER/*/_speedups.cpython-37m-darwin.so
       0x10883c000 -        0x1088ccb5f  dyld (733.6) <DAFEA246-2F9A-3DCB-A37C-4246D4F92770> /usr/lib/dyld
    0x7fff2bed6000 -     0x7fff2bed6fff  com.apple.Accelerate (1.11 - Accelerate 1.11) <71987428-FB54-3F6E-8699-DCC8BADC7D01> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff2beee000 -     0x7fff2c795ff7  com.apple.vImage (8.1 - 524.2) <6857F772-73E8-348B-9976-3BA0E5570FAA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff2c796000 -     0x7fff2c92ffef  libBLAS.dylib (1303) <5DDE58FD-747B-34CA-81A2-7BCDFF3DD291> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff2c930000 -     0x7fff2cb36fff  libBNNS.dylib (144.40.3) <8FBAAA82-90E2-3EDD-A96B-8D2139DCA619> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
    0x7fff2cb38000 -     0x7fff2ceecfff  libLAPACK.dylib (1303) <7E61073B-DB96-3AE8-B188-5FBB20479A8C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff2ceed000 -     0x7fff2cf02ff8  libLinearAlgebra.dylib (1303) <A5695D91-D87C-3E66-A470-16A166D8B43B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
    0x7fff2cf03000 -     0x7fff2cf08ff3  libQuadrature.dylib (7) <7EE59014-8FC5-3369-868B-8A87E590BF78> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
    0x7fff2cf09000 -     0x7fff2cf79fff  libSparse.dylib (103) <093F97A4-47DE-38DF-BB7A-FF5A3FB0BB3B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
    0x7fff2cf7a000 -     0x7fff2cf8cff7  libSparseBLAS.dylib (1303) <D092E493-0159-3F5E-860B-536B14B6E05C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
    0x7fff2cf8d000 -     0x7fff2d11ffc7  libvDSP.dylib (735) <1D607D95-D349-39C4-B97A-EFD73AC176A2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff2d120000 -     0x7fff2d29aff7  libvMisc.dylib (735) <C204E090-98AE-35E8-822A-EAB943739616> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff2d29b000 -     0x7fff2d29bfff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <4E0286A3-D4ED-3A93-A760-77533501A59C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff2e9d2000 -     0x7fff2ed49ffb  com.apple.CFNetwork (1120 - 1120) <5EA797F3-2F7A-3E0C-8DBC-DBE145004EC5> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff30220000 -     0x7fff3069fff7  com.apple.CoreFoundation (6.9 - 1673.126) <09EB9DD0-25BC-3730-9716-FE231CAF2C70> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff31632000 -     0x7fff31632fff  com.apple.CoreServices (1069.11 - 1069.11) <C8F86BE7-AAED-30A6-BBC2-550446137E7C> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff31633000 -     0x7fff316b8ff7  com.apple.AE (838 - 838) <3301AF1B-D178-306A-9641-B57AA03FB1BE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff316b9000 -     0x7fff3199afff  com.apple.CoreServices.CarbonCore (1217 - 1217) <FAA1467B-6D39-3EBE-9810-A4DF49478F10> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff3199b000 -     0x7fff319e8ffd  com.apple.DictionaryServices (1.2 - 323) <C1798F09-36D3-3C8E-AF72-A3DE63962AF1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff319e9000 -     0x7fff319f1fff  com.apple.CoreServices.FSEvents (1268.40.5 - 1268.40.5) <9BB76885-7CD7-3369-B759-33F7E5DA5392> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
    0x7fff319f2000 -     0x7fff31c2bff0  com.apple.LaunchServices (1069.11 - 1069.11) <88F59BD5-412A-35EE-AD45-E6BF80B24891> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff31c2c000 -     0x7fff31cc4ff9  com.apple.Metadata (10.7.0 - 2074.4) <028AC15A-35B7-3E1F-BCDC-470C8EA0CA09> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff31cc5000 -     0x7fff31cf2ff7  com.apple.CoreServices.OSServices (1069.11 - 1069.11) <A667F007-A599-3869-99F7-1F8460011015> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff31cf3000 -     0x7fff31d5afff  com.apple.SearchKit (1.4.1 - 1.4.1) <F0A931E4-0C31-36BA-8DD7-01FDF9813FB7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff31d5b000 -     0x7fff31d7fffd  com.apple.coreservices.SharedFileList (131 - 131) <62C3066A-3991-313F-AE2D-75B2B5934D52> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
    0x7fff325d0000 -     0x7fff325d6ff7  com.apple.DiskArbitration (2.7 - 2.7) <A3D2B0A0-3C72-3893-87BF-D45FE398A905> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff32908000 -     0x7fff32ccfff4  com.apple.Foundation (6.9 - 1673.126) <470C2315-3047-39BB-BB6B-2C620087091C> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff33045000 -     0x7fff330e8ffb  com.apple.framework.IOKit (2.0.2 - 1726.41.1) <FBB4A97B-D7CF-3B8C-932D-672343D63260> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff36951000 -     0x7fff3695dffe  com.apple.NetFS (6.0 - 4.0) <5C3C3672-2549-316E-9AC6-A1CFDCD16E9C> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff39523000 -     0x7fff3953ffff  com.apple.CFOpenDirectory (10.15 - 220.40.1) <AA81FC34-A7F6-3DA2-A275-B34F75099C7B> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff39540000 -     0x7fff3954bfff  com.apple.OpenDirectory (10.15 - 220.40.1) <ECFA2FFB-D5B6-3916-96F7-9F3A1EB1E534> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff3c891000 -     0x7fff3cbd7ff6  com.apple.security (7.0 - 59306.41.2) <FB3774D5-C940-35FB-960A-86253A01BDAE> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff3cbd8000 -     0x7fff3cc60ff7  com.apple.securityfoundation (6.0 - 55236) <6482C994-4DB4-320D-8FD4-50C998EA8856> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff3ccba000 -     0x7fff3ccbeff8  com.apple.xpc.ServiceManagement (1.0 - 1) <2B80E13A-AFFC-355A-AA82-CCDEF4718E66> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff3da4b000 -     0x7fff3dab5ff7  com.apple.SystemConfiguration (1.19 - 1.19) <A52A533D-DA25-3607-A18E-CA7C539E1C52> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff41811000 -     0x7fff418d5fef  com.apple.APFS (1412.41.1 - 1412.41.1) <0319F563-43AE-3F80-9107-7F0056E726DB> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
    0x7fff43523000 -     0x7fff43532fdf  com.apple.AppleFSCompression (119 - 1.0) <7EEDBF8A-8812-33D6-A5B0-F7D36825EE73> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff44cd5000 -     0x7fff44cdeff3  com.apple.coreservices.BackgroundTaskManagement (1.0 - 104) <5E2B9000-49D6-3BFA-97F1-3B47A8A7418D> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
    0x7fff47a56000 -     0x7fff47a66ff3  com.apple.CoreEmoji (1.0 - 107) <8D1CA277-C4F7-3F3B-919E-73B68D39535E> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
    0x7fff480b7000 -     0x7fff48121ff8  com.apple.CoreNLP (1.0 - 213) <329A9840-CBD8-33A2-A584-2805042284A9> /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP
    0x7fff48d3c000 -     0x7fff48d6aff7  com.apple.CSStore (1069.11 - 1069.11) <792520D2-5D81-3867-8DC7-75F8205D5A5B> /System/Library/PrivateFrameworks/CoreServicesStore.framework/Versions/A/CoreServicesStore
    0x7fff54e56000 -     0x7fff54f24ff5  com.apple.LanguageModeling (1.0 - 215) <D3478ED9-A757-355F-A4A0-464E133182D6> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
    0x7fff54f25000 -     0x7fff54f6dff7  com.apple.Lexicon-framework (1.0 - 72) <94910CCB-C386-3912-84A2-1A730BB6EF62> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
    0x7fff54f74000 -     0x7fff54f78ff6  com.apple.LinguisticData (1.0 - 353) <23AF4473-4FDB-39D9-8862-7D23276606A9> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
    0x7fff562c9000 -     0x7fff56315ff7  com.apple.spotlight.metadata.utilities (1.0 - 2074.4) <8957F147-9371-3728-896E-FC517AC7E86E> /System/Library/PrivateFrameworks/MetadataUtilities.framework/Versions/A/MetadataUtilities
    0x7fff56d3c000 -     0x7fff56d46fff  com.apple.NetAuth (6.2 - 6.2) <BA114B8C-BE33-3DBB-BDC8-25423DBBD3A3> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff5fa30000 -     0x7fff5fa40ff3  com.apple.TCC (1.0 - 1) <87BE8D5C-5D35-3434-8BDF-1615349C7A21> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff63c9d000 -     0x7fff63c9fff3  com.apple.loginsupport (1.0 - 1) <FFE90A0A-BEBC-3032-9368-94C016BE0795> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
    0x7fff6400e000 -     0x7fff64043ff7  libCRFSuite.dylib (48) <CDEA70A4-318B-3990-9AAE-1D7B18132760> /usr/lib/libCRFSuite.dylib
    0x7fff64046000 -     0x7fff64050ff3  libChineseTokenizer.dylib (34) <4D68248B-BD40-32E3-ABCA-CE23BCA0A6A4> /usr/lib/libChineseTokenizer.dylib
    0x7fff640dd000 -     0x7fff640dffff  libDiagnosticMessagesClient.dylib (112) <83F42398-DB41-3BB2-B8A1-10D78C4B5778> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff645a5000 -     0x7fff645a6ff3  libSystem.B.dylib (1281) <1DD1BCD2-2C85-3B81-8CAF-224FB042F441> /usr/lib/libSystem.B.dylib
    0x7fff64636000 -     0x7fff64637fff  libThaiTokenizer.dylib (3) <22582C9C-3D32-3832-8925-813E4F2BA8DA> /usr/lib/libThaiTokenizer.dylib
    0x7fff6464f000 -     0x7fff64665fff  libapple_nghttp2.dylib (1.39.2) <9B990E6A-D9EB-3F2C-B7CA-085A47D4BC62> /usr/lib/libapple_nghttp2.dylib
    0x7fff6469a000 -     0x7fff6470cff7  libarchive.2.dylib (72.40.2) <25C00824-621A-3FF1-9B6C-52999B6DDF4E> /usr/lib/libarchive.2.dylib
    0x7fff6483e000 -     0x7fff6483eff3  libauto.dylib (187) <F4B3519A-A4FC-30E0-805C-70C99BA3FDDA> /usr/lib/libauto.dylib
    0x7fff648fc000 -     0x7fff6490cfff  libbsm.0.dylib (60) <E57A0CC6-226D-3529-A23A-D5DD6674DB3E> /usr/lib/libbsm.0.dylib
    0x7fff6490d000 -     0x7fff64919fff  libbz2.1.0.dylib (44) <F3D26C17-BC6E-3A83-A3BB-137343C87303> /usr/lib/libbz2.1.0.dylib
    0x7fff6491a000 -     0x7fff6496dfff  libc++.1.dylib (800.7) <1D42387D-206A-3F06-9B5F-705B83EAC295> /usr/lib/libc++.1.dylib
    0x7fff6496e000 -     0x7fff64982fff  libc++abi.dylib (800.7) <D89ABFBF-3754-35AB-BAEE-FBF14857F79B> /usr/lib/libc++abi.dylib
    0x7fff64983000 -     0x7fff64983ffb  libcharset.1.dylib (59) <EC5B95D9-388B-3351-9192-CD6CDB8C3E0F> /usr/lib/libcharset.1.dylib
    0x7fff64984000 -     0x7fff64995ffb  libcmph.dylib (8) <49C8E101-945E-369B-91D3-2129000DFF35> /usr/lib/libcmph.dylib
    0x7fff64996000 -     0x7fff649aefcf  libcompression.dylib (87) <51724F54-908E-3616-9B64-EAEA2FA813D0> /usr/lib/libcompression.dylib
    0x7fff64c7b000 -     0x7fff64c91fff  libcoretls.dylib (167) <4F054E37-783A-3FCD-B90B-23A0A83621D9> /usr/lib/libcoretls.dylib
    0x7fff64c92000 -     0x7fff64c93ffb  libcoretls_cfhelpers.dylib (167) <62E31BC8-A823-3816-B130-2BB550433203> /usr/lib/libcoretls_cfhelpers.dylib
    0x7fff653bc000 -     0x7fff653bcff3  libenergytrace.dylib (21) <1CE2BD78-F68E-36A3-BCE9-E9EAB78D9FF3> /usr/lib/libenergytrace.dylib
    0x7fff653e4000 -     0x7fff653e6ff7  libfakelink.dylib (149) <528A0ABE-B583-3DA1-8E5B-9CA7E89303DE> /usr/lib/libfakelink.dylib
    0x7fff653e7000 -     0x7fff653ecf4f  libffi.dylib (25) <639F392F-A930-3DB5-A3E5-BB367ED22339> /usr/lib/libffi.dylib
    0x7fff653f5000 -     0x7fff653fafff  libgermantok.dylib (24) <5E297121-22A7-3A2F-92B9-DD3E5C829CC7> /usr/lib/libgermantok.dylib
    0x7fff65405000 -     0x7fff654f5ff7  libiconv.2.dylib (59) <EB71AC8F-EA44-3BEE-A210-2D92251CA51D> /usr/lib/libiconv.2.dylib
    0x7fff654f6000 -     0x7fff6574eff7  libicucore.A.dylib (64243.0.1) <4CBF52D7-7235-34C8-9FF1-8657076B604F> /usr/lib/libicucore.A.dylib
    0x7fff65768000 -     0x7fff65769fff  liblangid.dylib (133) <DCC4FA36-0563-3BD2-AE35-9BAF52F5BD98> /usr/lib/liblangid.dylib
    0x7fff6576a000 -     0x7fff65782ffb  liblzma.5.dylib (16) <7D2522C8-8CBE-32C9-8743-A8F598602F4C> /usr/lib/liblzma.5.dylib
    0x7fff6579a000 -     0x7fff65841fff  libmecab.dylib (883) <FDA0E623-F6F2-3402-B72C-0C60A32C2CC1> /usr/lib/libmecab.dylib
    0x7fff65842000 -     0x7fff65aa2ff9  libmecabra.dylib (883) <2E84458F-5748-3A9B-94F3-CAF3C79E6383> /usr/lib/libmecabra.dylib
    0x7fff65e0e000 -     0x7fff65e3dff7  libncurses.5.4.dylib (57) <7115BD9E-9A53-3538-BA7C-6D71E8C0F9F1> /usr/lib/libncurses.5.4.dylib
    0x7fff65f6c000 -     0x7fff663deff4  libnetwork.dylib (1880.40.26) <D8C5B7F0-04D5-3470-A9C4-EF8B2FF96986> /usr/lib/libnetwork.dylib
    0x7fff6647d000 -     0x7fff664afff6  libobjc.A.dylib (781) <427A292C-9B1A-3E91-951D-739F1F85D9F5> /usr/lib/libobjc.A.dylib
    0x7fff664c2000 -     0x7fff664c6fff  libpam.2.dylib (25) <02ABA04D-5843-3850-82A3-EBECA6FC2CDF> /usr/lib/libpam.2.dylib
    0x7fff664c9000 -     0x7fff664fcff7  libpcap.A.dylib (89.40.2) <C4F9F5BD-BA21-3038-9665-4D298FB7511C> /usr/lib/libpcap.A.dylib
    0x7fff665f2000 -     0x7fff667d3ff7  libsqlite3.dylib (308.4) <9C850BC8-8E63-3534-9268-75830AEA1940> /usr/lib/libsqlite3.dylib
    0x7fff66a24000 -     0x7fff66a27ffb  libutil.dylib (57) <B88D4C21-DAEF-3566-8EAE-5973C51A16FD> /usr/lib/libutil.dylib
    0x7fff66a28000 -     0x7fff66a35fff  libxar.1.dylib (420) <46AAA43E-6FC6-38A8-B696-62143706D33B> /usr/lib/libxar.1.dylib
    0x7fff66a3b000 -     0x7fff66b1dff7  libxml2.2.dylib (32.12) <0DB777D9-F9A1-3921-BFCE-05A000293915> /usr/lib/libxml2.2.dylib
    0x7fff66b21000 -     0x7fff66b49fff  libxslt.1.dylib (16.7) <C30A840F-E7E7-39D5-A633-9C256650B552> /usr/lib/libxslt.1.dylib
    0x7fff66b4a000 -     0x7fff66b5cfff  libz.1.dylib (76) <3EC7A143-AF2D-35EE-9C08-542B2907E3D2> /usr/lib/libz.1.dylib
    0x7fff675c2000 -     0x7fff675c7ff7  libcache.dylib (83) <74F6459D-3606-3ADB-9808-F6B0FE70062D> /usr/lib/system/libcache.dylib
    0x7fff675c8000 -     0x7fff675d3ff7  libcommonCrypto.dylib (60165) <1333752F-5117-3E86-803A-06E166D80C8C> /usr/lib/system/libcommonCrypto.dylib
    0x7fff675d4000 -     0x7fff675dbfff  libcompiler_rt.dylib (101.2) <0437EBEF-8191-3912-A365-D6BB75C7A810> /usr/lib/system/libcompiler_rt.dylib
    0x7fff675dc000 -     0x7fff675e5fff  libcopyfile.dylib (166.40.1) <7FAF372E-BAD5-30E6-A8F2-A3D06B91DC80> /usr/lib/system/libcopyfile.dylib
    0x7fff675e6000 -     0x7fff6767dfef  libcorecrypto.dylib (866.40.8) <AE25C9EE-5D63-3E49-B3AA-D482D35C085A> /usr/lib/system/libcorecrypto.dylib
    0x7fff67794000 -     0x7fff677d5ff0  libdispatch.dylib (1173.40.5) <1FF421B6-4BF0-3B5F-8F56-5ED3B3EFE06F> /usr/lib/system/libdispatch.dylib
    0x7fff677d6000 -     0x7fff6780bfff  libdyld.dylib (733.6) <2FA4B359-624B-337C-9207-CDCF841C2E52> /usr/lib/system/libdyld.dylib
    0x7fff6780c000 -     0x7fff6780cffb  libkeymgr.dylib (30) <7EEF9246-30B4-34DD-8AD6-79679D1A7784> /usr/lib/system/libkeymgr.dylib
    0x7fff6780d000 -     0x7fff67819ff7  libkxld.dylib (6153.41.3) <F9FF90CE-DCB0-3918-882F-6E475A6E244A> /usr/lib/system/libkxld.dylib
    0x7fff6781a000 -     0x7fff6781aff7  liblaunch.dylib (1738.40.10) <CC02D5B3-A95D-3B16-8EE5-D62521CFE899> /usr/lib/system/liblaunch.dylib
    0x7fff6781b000 -     0x7fff67820ff7  libmacho.dylib (949.0.1) <6C3E49B2-594D-3B9D-82DB-C4ABEB9788AB> /usr/lib/system/libmacho.dylib
    0x7fff67821000 -     0x7fff67823ff3  libquarantine.dylib (110.40.3) <A1BCAA32-A194-3DBE-9930-8F49A4AEF284> /usr/lib/system/libquarantine.dylib
    0x7fff67824000 -     0x7fff67825ff7  libremovefile.dylib (48) <DD7AE862-F179-3C07-A4FC-5775DDD4D3E6> /usr/lib/system/libremovefile.dylib
    0x7fff67826000 -     0x7fff6783dfff  libsystem_asl.dylib (377.40.1) <ECE44856-D279-3B5D-A0AA-8BE421D200C4> /usr/lib/system/libsystem_asl.dylib
    0x7fff6783e000 -     0x7fff6783efff  libsystem_blocks.dylib (74) <DC521115-905A-3A0D-9337-C55FACCEA85F> /usr/lib/system/libsystem_blocks.dylib
    0x7fff6783f000 -     0x7fff678c6ff7  libsystem_c.dylib (1353.41.1) <5AD50779-955E-3F56-BCB9-1E14833B3455> /usr/lib/system/libsystem_c.dylib
    0x7fff678c7000 -     0x7fff678cafff  libsystem_configuration.dylib (1061.40.2) <7A2329E0-3C84-3DB7-BC32-E7796C50D621> /usr/lib/system/libsystem_configuration.dylib
    0x7fff678cb000 -     0x7fff678ceff7  libsystem_coreservices.dylib (114) <DF341577-A307-3722-BB24-D4AACEAB19B3> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff678cf000 -     0x7fff678d6fff  libsystem_darwin.dylib (1353.41.1) <E862B5B1-A367-39CA-8319-B2F9DFADF606> /usr/lib/system/libsystem_darwin.dylib
    0x7fff678d7000 -     0x7fff678deffb  libsystem_dnssd.dylib (1096.40.7) <2A9C6F3E-427B-332E-BDD3-D4651306F3DE> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff678df000 -     0x7fff678e0ffb  libsystem_featureflags.dylib (17) <B94C0052-B75A-3169-80AA-5F480588AF6E> /usr/lib/system/libsystem_featureflags.dylib
    0x7fff678e1000 -     0x7fff6792eff7  libsystem_info.dylib (538) <18CC56C5-5325-3375-BF99-FAE7F4F19DDD> /usr/lib/system/libsystem_info.dylib
    0x7fff6792f000 -     0x7fff6795bff7  libsystem_kernel.dylib (6153.41.3) <18918E9C-45BC-3D5A-A6B6-3DBC60EEE2E1> /usr/lib/system/libsystem_kernel.dylib
    0x7fff6795c000 -     0x7fff679a7fe7  libsystem_m.dylib (3178) <895CC10E-5385-37F6-B813-060AD6E6E01C> /usr/lib/system/libsystem_m.dylib
    0x7fff679a8000 -     0x7fff679cfff7  libsystem_malloc.dylib (283.40.1) <F82A587B-44A2-3699-A218-9D3ECEE23D5A> /usr/lib/system/libsystem_malloc.dylib
    0x7fff679d0000 -     0x7fff679ddff3  libsystem_networkextension.dylib (1095.40.22) <7F206A43-A941-3BAB-AE3A-16169F2FE6AB> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff679de000 -     0x7fff679e7fff  libsystem_notify.dylib (241) <C95CC58E-35E7-3828-AA2A-6EED73C12DE5> /usr/lib/system/libsystem_notify.dylib
    0x7fff679e8000 -     0x7fff679f1fe7  libsystem_platform.dylib (220) <0CCDD81F-0891-3400-8A97-6CAC3BBBE2F9> /usr/lib/system/libsystem_platform.dylib
    0x7fff679f2000 -     0x7fff679fcff7  libsystem_pthread.dylib (416.40.3) <53C65598-9E9E-36FF-BDC2-74F228E58C5C> /usr/lib/system/libsystem_pthread.dylib
    0x7fff679fd000 -     0x7fff67a01ffb  libsystem_sandbox.dylib (1217.41.1) <2183D15E-2CFD-3160-80CE-A948F0529005> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff67a02000 -     0x7fff67a04fff  libsystem_secinit.dylib (62.40.2) <D2782294-ACDC-30FF-A794-B4C1B324526B> /usr/lib/system/libsystem_secinit.dylib
    0x7fff67a05000 -     0x7fff67a0cffb  libsystem_symptoms.dylib (1238.40.4) <A44E4405-E22E-32E9-83DE-8C7A82401DA0> /usr/lib/system/libsystem_symptoms.dylib
    0x7fff67a0d000 -     0x7fff67a23ff2  libsystem_trace.dylib (1147.40.13) <376CC435-E656-37D9-A5FF-C49B6E4525E2> /usr/lib/system/libsystem_trace.dylib
    0x7fff67a25000 -     0x7fff67a2affb  libunwind.dylib (35.4) <44448F1F-08E5-3425-ADBA-C38A9E8F90C7> /usr/lib/system/libunwind.dylib
    0x7fff67a2b000 -     0x7fff67a5fff6  libxpc.dylib (1738.40.10) <99CC9436-D653-3762-ADBB-9054EBD1BA2B> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 1
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 29888591
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=442.7M resident=0K(0%) swapped_out_or_unallocated=442.7M(100%)
Writable regions: Total=140.9M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=140.9M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Activity Tracing                   256K        1 
Kernel Alloc Once                    8K        1 
MALLOC                            75.6M       54 
MALLOC guard page                   16K        3 
MALLOC_LARGE (reserved)            640K        2         reserved VM address space (unallocated)
STACK GUARD                          4K        1 
Stack                             16.0M        1 
VM_ALLOCATE                       48.0M      193 
__DATA                            7801K      198 
__DATA_CONST                       256K       41 
__LINKEDIT                       358.1M       69 
__OBJC_RO                         32.0M        1 
__OBJC_RW                         1780K        2 
__TEXT                            84.6M      188 
__UNICODE                          564K        1 
shared memory                       12K        3 
===========                     =======  ======= 
TOTAL                            625.3M      759 
TOTAL, minus reserved VM space   624.7M      759 

Any help is appreciated.

----------
components: macOS
messages: 356689
nosy: karolyi, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python3.7.5 crashes on OSX with my django project
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:48:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2019 16:48:48 +0000
Subject: [issue38276] test_asyncio:
 test_cancel_make_subprocess_transport_exec() failed on RHEL7 LTO + PGO 3.x
In-Reply-To: <1569416953.01.0.173802643321.issue38276@roundup.psfhosted.org>
Message-ID: <1573836528.18.0.349305867542.issue38276@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Fedora Stable Refleaks 3.8:
https://buildbot.python.org/all/#/builders/260/builds/50

...
test_devnull_input (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_devnull_output (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_empty_input (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_exec_loop_deprecated (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_kill (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_pause_reading (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_popen_error (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_popen_error_with_stdin_pipe (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_read_stdout_after_process_exit (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_send_signal (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_shell (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_shell_loop_deprecated (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_start_new_session (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_stdin_broken_pipe (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_stdin_not_inheritable (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_stdin_stdout (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_terminate (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
Timeout (3:15:00)!
Thread 0x00007f59c7bf0740 (most recent call first):
  File "/home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/selectors.py", line 468 in select
  File "/home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/asyncio/base_events.py", line 1808 in _run_once
  File "/home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/asyncio/base_events.py", line 563 in run_forever
  File "/home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/asyncio/base_events.py", line 595 in run_until_complete
  File "/home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/test_asyncio/test_subprocess.py", line 440 in test_cancel_make_subprocess_transport_exec
  (...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38276>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:54:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2019 16:54:20 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on AMD64 FreeBSD
 Shared 3.x
Message-ID: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Fail with OpenSSL 1.1.1d  10 Sep 2019 on AMD64 FreeBSD Shared 3.x:
https://buildbot.python.org/all/#/builders/371/builds/78

======================================================================
FAIL: test_min_max_version (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 1238, in test_min_max_version
    self.assertIn(
AssertionError: <TLSVersion.TLSv1_2: 771> not found in {<TLSVersion.SSLv3: 768>, <TLSVersion.TLSv1: 769>}

======================================================================
FAIL: test_min_max_version_mismatch (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 220, in wrapper
    return func(*args, **kw)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 3840, in test_min_max_version_mismatch
    self.assertIn("alert", str(e.exception))
AssertionError: 'alert' not found in '[SSL: NO_PROTOCOLS_AVAILABLE] no protocols available (_ssl.c:1108)'


SSL infos from pythoninfo:

ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1d  10 Sep 2019
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 4, 15)
ssl.OP_ALL: 0x80000054
ssl.OP_NO_TLSv1_1: 0x10000000

ssl.SSLContext.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.SSLContext.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.SSLContext.protocol: _SSLMethod.PROTOCOL_TLS
ssl.SSLContext.verify_mode: VerifyMode.CERT_NONE

ssl.default_https_context.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.default_https_context.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.default_https_context.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.default_https_context.protocol: _SSLMethod.PROTOCOL_TLS
ssl.default_https_context.verify_mode: VerifyMode.CERT_REQUIRED

ssl.stdlib_context.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.stdlib_context.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.stdlib_context.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.stdlib_context.protocol: _SSLMethod.PROTOCOL_TLS
ssl.stdlib_context.verify_mode: VerifyMode.CERT_NONE

----------
assignee: christian.heimes
components: SSL, Tests
messages: 356691
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_ssl: test_min_max_version() fails on AMD64 FreeBSD Shared 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38815>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:55:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2019 16:55:11 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1573836911.7.0.00979313520198.issue38815@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Same failure on AMD64 FreeBSD Shared 3.8:
https://buildbot.python.org/all/#/builders/374/builds/32

FAIL: test_min_max_version (test.test_ssl.ContextTests)
FAIL: test_min_max_version_mismatch (test.test_ssl.ThreadedTests)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38815>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:56:12 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 16:56:12 +0000
Subject: [issue38778] Document that os.fork is not allowed in subinterpreters
In-Reply-To: <1573569500.54.0.207485115661.issue38778@roundup.psfhosted.org>
Message-ID: <1573836972.84.0.0785274796452.issue38778@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b22030073b9327a3aeccb69507694bce078192aa by Miss Islington (bot) (Phil Connell) in branch 'master':
bpo-38778: Document that os.fork is not allowed in subinterpreters (GH-17123)
https://github.com/python/cpython/commit/b22030073b9327a3aeccb69507694bce078192aa


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38778>
_______________________________________

From report at bugs.python.org  Fri Nov 15 11:56:13 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 16:56:13 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>
Message-ID: <1573836972.99.0.312565936922.issue34651@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b22030073b9327a3aeccb69507694bce078192aa by Miss Islington (bot) (Phil Connell) in branch 'master':
bpo-38778: Document that os.fork is not allowed in subinterpreters (GH-17123)
https://github.com/python/cpython/commit/b22030073b9327a3aeccb69507694bce078192aa


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:10:57 2019
From: report at bugs.python.org (Lukas Vacek)
Date: Fri, 15 Nov 2019 17:10:57 +0000
Subject: [issue38794] Setup: support linking openssl statically
In-Reply-To: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>
Message-ID: <1573837857.59.0.0391326604596.issue38794@roundup.psfhosted.org>


Lukas Vacek <lucas.vacek at gmail.com> added the comment:

Christian, I don't want to argue.

Feel free to close both this bug and the PR as "enhancement rejected". Adding one ./configure option is not really worth arguing over, I can always compile python as I need. I just tried to solve the same problem for others because other people also want a simple way to install a new version of Python on old distros and have a working ssl module. 

If my contribution is not welcome it's fine.

However, I have a feeling the reason for the rejection is not technical because after I stated I am happy to help solve the problem in other ways ("If you can think of a better real world solution than static linking OpenSSL please share and let's do it!") you literally twisted my words 180 degrees ("You are trying to solve a problem by dictating the solution at the same time."). This is very inappropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38794>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:20:18 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Nov 2019 17:20:18 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1573838418.03.0.356516301558.issue11354@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:24:33 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Nov 2019 17:24:33 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1573838673.41.0.23028387644.issue38811@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Just an FYI a raised exception isn't considered a crash. For us a crash is a C-level crash like a segfault.

----------
nosy: +brett.cannon
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:26:51 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Nov 2019 17:26:51 +0000
Subject: [issue34572] C unpickling bypasses import thread safety
In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za>
Message-ID: <1573838811.55.0.861567493373.issue34572@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

3.6 and 3.5 are in security mode, so unless there's a security risk due to this bug the fix will not be backported to those older versions (https://devguide.python.org/#status-of-python-branches).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34572>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:41:44 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 15 Nov 2019 17:41:44 +0000
Subject: [issue38742] ElementTree won't parse comments before root element
In-Reply-To: <1573200653.57.0.472898795822.issue38742@roundup.psfhosted.org>
Message-ID: <1573839704.94.0.960846897225.issue38742@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Duplicate of issue 9521 (and issue 24287).

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> xml.etree.ElementTree skips processing instructions when parsing

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38742>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:45:40 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Fri, 15 Nov 2019 17:45:40 +0000
Subject: [issue38803] test_wait3 and test_wait4 leaked references on x86
 Gentoo Refleaks 3.x
In-Reply-To: <1573771592.29.0.825228162147.issue38803@roundup.psfhosted.org>
Message-ID: <1573839940.44.0.606851581154.issue38803@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

Woops! I'll get to it before the end of the weekend!

----------
nosy: +eelizondo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38803>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:45:58 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Fri, 15 Nov 2019 17:45:58 +0000
Subject: [issue35381] posixmodule: convert statically allocated types
 (DirEntryType & ScandirIteratorType) to heap-allocated types
In-Reply-To: <1543818839.39.0.788709270274.issue35381@psf.upfronthosting.co.za>
Message-ID: <1573839958.58.0.753409451098.issue35381@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

Woops! I'll get to it before the end of the weekend!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35381>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:49:27 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Nov 2019 17:49:27 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573840167.55.0.99100329687.issue38453@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset abde52cd8e31830bfc06c5803221faae6172104a by Steve Dower in branch 'master':
bpo-38453: Ensure ntpath.realpath correctly resolves relative paths (GH-16967)
https://github.com/python/cpython/commit/abde52cd8e31830bfc06c5803221faae6172104a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:49:52 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Nov 2019 17:49:52 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573840192.08.0.817749525693.issue38453@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I think the PR as it stands is a net improvement over where we currently are, so I'll merge it. We can make more tweaks as necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:53:27 2019
From: report at bugs.python.org (=?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Fri, 15 Nov 2019 17:53:27 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1573840407.06.0.0821436157662.issue38811@roundup.psfhosted.org>


Toke H?iland-J?rgensen <toke at toke.dk> added the comment:

Right, sure, that makes sense; thanks for clarifying :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Fri Nov 15 12:54:41 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Nov 2019 17:54:41 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573840481.36.0.477855913847.issue38453@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +16682
pull_request: https://github.com/python/cpython/pull/17174

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 13:20:57 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Nov 2019 18:20:57 +0000
Subject: [issue38778] Document that os.fork is not allowed in subinterpreters
In-Reply-To: <1573569500.54.0.207485115661.issue38778@roundup.psfhosted.org>
Message-ID: <1573842057.15.0.281802551319.issue38778@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Nice work, Phil.  We need a backport to 3.8, but the miss-islington bot is having trouble with it. [1]  Either we can try flipping the "needs backport to 3.8" label again or you could create a backport PR yourself (like miss-islington suggested).  If you do that then be sure to request a review from me. :)


[1] https://github.com/python/cpython/pull/17123#issuecomment-554469177

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38778>
_______________________________________

From report at bugs.python.org  Fri Nov 15 13:27:38 2019
From: report at bugs.python.org (Andrei Daraschenka)
Date: Fri, 15 Nov 2019 18:27:38 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1573842458.8.0.763907519891.issue25866@roundup.psfhosted.org>


Change by Andrei Daraschenka <dorosch.github.io at yandex.ru>:


----------
pull_requests: +16683
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17175

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Fri Nov 15 13:35:46 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Nov 2019 18:35:46 +0000
Subject: [issue38816] Clarify about fork() and the CPython runtime in the
 C-API docs.
Message-ID: <1573842946.86.0.905050259402.issue38816@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The C-API docs are a bit sparse on the interplay between C fork() and the CPython runtime.

----------
assignee: eric.snow
components: Documentation
messages: 356705
nosy: eric.snow, gregory.p.smith, pconnell
priority: normal
pull_requests: 16684
severity: normal
stage: patch review
status: open
title: Clarify about fork() and the CPython runtime in the C-API docs.
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38816>
_______________________________________

From report at bugs.python.org  Fri Nov 15 13:49:27 2019
From: report at bugs.python.org (Jason Killen)
Date: Fri, 15 Nov 2019 18:49:27 +0000
Subject: [issue38812] Comparing datetime.time objects incorrect for TZ aware
 and unaware
In-Reply-To: <1573824611.55.0.420390589696.issue38812@roundup.psfhosted.org>
Message-ID: <1573843767.31.0.56490664351.issue38812@roundup.psfhosted.org>


Jason Killen <jsnklln at gmail.com> added the comment:

This appears to be a bug in pytz which as far as I can tell is not part of the "standard" lib, at least it's not in Lib.

Running this example which does not use pytz:
from datetime import timedelta, datetime, tzinfo, timezone, time

# stole this from the docs, and beat it up a bit
class KabulTz(tzinfo):
    def utcoffset(self, dt):
        return timedelta(hours=4, minutes=30)

    def fromutc(self, dt):
        # Follow same validations as in datetime.tzinfo
        if not isinstance(dt, datetime):
            raise TypeError("fromutc() requires a datetime argument")
        if dt.tzinfo is not self:
            raise ValueError("dt.tzinfo is not self")

        return dt + timedelta(hours=4)

    def dst(self, dt):
        # Kabul does not observe daylight saving time.
        return timedelta(0)

    def tzname(self, dt):
        return "+04"

tzaware_time2 = time(7,30,tzinfo=timezone.utc)
tzaware_time1 = time(7,30,tzinfo=KabulTz())

tzunaware_time = time(7, 30)

tzaware_time1 < tzaware_time2

I get no error.

When I use your example I notice that utcoffset in pytz/tzinfo.py returns None for the Denver example but for the UTC object returns ZERO which happens to be timedelta(0) which seems correct.  It's weird to me that pytz is returning None in the Denver case because I think what it should return is right there in self._utcoffset.

More info: It looks like pytz isn't handling the fact that it's a time only type.  `dt` appears to be a datetime when utcoffset is called from a datetime.

----------
nosy: +Jason.Killen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38812>
_______________________________________

From report at bugs.python.org  Fri Nov 15 14:02:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Nov 2019 19:02:13 +0000
Subject: [issue38750] Solve IPv4 categorisation issues with the ipaddress
 module
In-Reply-To: <1573247171.82.0.693534364371.issue38750@roundup.psfhosted.org>
Message-ID: <1573844533.26.0.275081424383.issue38750@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38750>
_______________________________________

From report at bugs.python.org  Fri Nov 15 14:14:36 2019
From: report at bugs.python.org (Tim Peters)
Date: Fri, 15 Nov 2019 19:14:36 +0000
Subject: [issue38813] math.modf() change integer returned part as integer
 instead of float
In-Reply-To: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>
Message-ID: <1573845276.65.0.880450368714.issue38813@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Raymond, I think you've tricked yourself ;-)  The prototype for C's duoble modf is

double modf(double x, double *intptr);

Yes, after the call *intptr is an exact integer, but in the double format.

>>> math.modf(1e300)
(0.0, 1e+300)

I don't think it would be doing anyone a real favor by returning

1000000000000000052504760255204420248704468581108159154915854115511802457988908195786371375080447864043704443832883878176942523235360430575644792184786706982848387200926575803737830233794788090059368953234970799945081119038967640880074652742780142494579258788820056842838115669472196386865459400540160

instead of 1e300 for "the integer part".

`frexp()` is very different, in that the second part is a (small!) integer exponent - a float would work for that too, but would be surprising.

>>> math.frexp(1e300)
(0.7466108948025751, 997)

A better analogy would be to math.floor(), which does return an int, even for cases like floor(1e300).  In Python 2 it did not (it returned an integer but in float format), and I believe it was a mistake to change it to return an int.  Building giant ints is not what C does, so is surprising on that count alone, and is far more expensive than returning (as C does) a float.

That is, we didn't improve on C's floor, we introduced a surprising difference that sometimes hurts and rarely helps (if anyone really wanted an int, they could apply int() to the float result).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________

From report at bugs.python.org  Fri Nov 15 14:34:10 2019
From: report at bugs.python.org (Alex)
Date: Fri, 15 Nov 2019 19:34:10 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1573846450.29.0.775889407217.issue25866@roundup.psfhosted.org>


Alex <alexpclarkson at gmail.com> added the comment:

dorosch, please note section 3.9 from the developers guide:

"When a patch exists in the issue tracker that should be converted into a GitHub pull request, please first ask the original patch author to prepare their own pull request. If the author does not respond after a week, it is acceptable for another contributor to prepare the pull request based on the existing patch."

It's been two hours, not a week, and I would've liked to raise a pull request for this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Fri Nov 15 14:45:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Nov 2019 19:45:45 +0000
Subject: [issue38755] Long unicode string causes SyntaxError: Non-UTF-8 code
 starting with '\xe2' in file ..., but no encoding declared;
 see http://python.org/dev/peps/pep-0263/ for details
In-Reply-To: <1573302408.95.0.156655994529.issue38755@roundup.psfhosted.org>
Message-ID: <1573847145.35.0.95511813232.issue38755@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think that this should be closed as a duplicate of #34979 and this example posted there, with the OS and python version included.

On Windows, with 3.7, 3.8.0, and master, neither the posted comment, the one in the file, not the initial statement in #34979 give the SyntaxError.

----------
nosy: +terry.reedy
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38755>
_______________________________________

From report at bugs.python.org  Fri Nov 15 14:56:48 2019
From: report at bugs.python.org (=?utf-8?b?0JDQvdGC0L7QvSDQkdGA0YvQt9Cz0LDQu9C+0LI=?=)
Date: Fri, 15 Nov 2019 19:56:48 +0000
Subject: [issue38817] Immutable types inplace operations work incorrect in
 async
Message-ID: <1573847808.01.0.483185624752.issue38817@roundup.psfhosted.org>


New submission from ????? ????????? <tony.bryzgaloff at gmail.com>:

Example code (also is attached to the issue):


import asyncio

async def count_smth(seconds: int) -> int:
    await asyncio.sleep(seconds)
    return seconds * 3

async def small_job(d: dict, key: str, seconds: int) -> None:
    d[key] += await count_smth(seconds)  # <-- strange happens here

async def main() -> None:
     d = dict(key=0)
     await asyncio.gather(
           small_job(d, 'key', 1),
           small_job(d, 'key', 2),
     )
     print(d['key'])  # expected: 0 + 1 * 3 + 2 * 3 = 9, actual: 6

if __name__ == '__main__':
    asyncio.run(main())


Expected output: 0 + 1 * 3 + 2 * 3 = 9. Actual: 6. Seems to be a race condition.

Same happens for other immutable types: str, tuple (when used as values of dict instead of int). But works correctly with list and custom class with __iadd__ method.

----------
components: Interpreter Core, asyncio
files: scratch_1.py
messages: 356710
nosy: asvetlov, yselivanov, ????? ?????????
priority: normal
severity: normal
status: open
title: Immutable types inplace operations work incorrect in async
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48717/scratch_1.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38817>
_______________________________________

From report at bugs.python.org  Fri Nov 15 14:57:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Nov 2019 19:57:17 +0000
Subject: =?utf-8?q?=5Bissue34979=5D_Python_throws_=E2=80=9CSyntaxError=3A_Non-UTF-?=
 =?utf-8?q?8_code_start_with_=5Cxe8=2E=2E=2E=E2=80=9D_when_parse_source_fi?=
 =?utf-8?q?le?=
In-Reply-To: <1539482499.11.0.788709270274.issue34979@psf.upfronthosting.co.za>
Message-ID: <1573847837.25.0.870999637657.issue34979@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Windows, with 3.7, 3.8.0, and master, none of the demo.py statement here and the examples in #38755 raise an error.  I tried 'python -m module', running from IDLE editor, and interactive IDLE and REPL.  Even the following worked.

>>> s = (b'\xe2\x96\x91'*1111111).decode()
>>> s[-10:]
'??????????'

susaki, what OS, and do you have the same problem with current Python (at least 3.8)?

Also, susuki, when replying by email, please delete the quoted message.  When your message is added to the web page, the quoted message is redundant and distracting noise.

If this issue effectively duplicates (part of) #14811 and/or #25643, it should be closed as a duplicate of one of them.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34979>
_______________________________________

From report at bugs.python.org  Fri Nov 15 14:59:59 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Nov 2019 19:59:59 +0000
Subject: =?utf-8?q?=5Bissue34979=5D_Python_throws_=E2=80=9CSyntaxError=3A_Non-UTF-?=
 =?utf-8?q?8_code_start_with_=5Cxe8=2E=2E=2E=E2=80=9D_when_parse_source_fi?=
 =?utf-8?q?le?=
In-Reply-To: <1539482499.11.0.788709270274.issue34979@psf.upfronthosting.co.za>
Message-ID: <1573847999.74.0.902733846445.issue34979@roundup.psfhosted.org>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34979>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:02:44 2019
From: report at bugs.python.org (Alex)
Date: Fri, 15 Nov 2019 20:02:44 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1573848164.38.0.465164311281.issue25866@roundup.psfhosted.org>


Change by Alex <alexpclarkson at gmail.com>:


----------
pull_requests: +16685
pull_request: https://github.com/python/cpython/pull/17177

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:04:17 2019
From: report at bugs.python.org (Alex)
Date: Fri, 15 Nov 2019 20:04:17 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1573848257.13.0.447274396885.issue25866@roundup.psfhosted.org>


Alex <alexpclarkson at gmail.com> added the comment:

I've decided to raise a pull request for the patch, considering it's only been a few hours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:05:39 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Nov 2019 20:05:39 +0000
Subject: [issue38765] `ast.AST._attributes` is used by `ast.dump()` but not
 documented
In-Reply-To: <1573482663.72.0.733055997415.issue38765@roundup.psfhosted.org>
Message-ID: <1573848339.64.0.728045329617.issue38765@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A leading underscore usually means that the name is private and should not be relied on.  We of course use private names to implement public objects, else they should not exist.  '_fields' is an exception, and I leave it to the ast experts to decide if '_attributes' should be also.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38765>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:11:08 2019
From: report at bugs.python.org (Anton Bryzgalov)
Date: Fri, 15 Nov 2019 20:11:08 +0000
Subject: [issue38817] Immutable types inplace operations work incorrect in
 async
In-Reply-To: <1573847808.01.0.483185624752.issue38817@roundup.psfhosted.org>
Message-ID: <1573848668.82.0.745450639652.issue38817@roundup.psfhosted.org>


Anton Bryzgalov <tony.bryzgaloff at gmail.com> added the comment:

Example code (also is attached to the issue):


import asyncio

async def count_smth(seconds: int) -> int:
    await asyncio.sleep(seconds)
    return seconds * 3

async def small_job(d: dict, key: str, seconds: int) -> None:
    d[key] += await count_smth(seconds)  # <-- strange happens here

async def main() -> None:
     d = dict(key=0)
     await asyncio.gather(
           small_job(d, 'key', 1),
           small_job(d, 'key', 2),
     )
     print(d['key'])  # expected: 0 + 1 * 3 + 2 * 3 = 9, actual: 6

if __name__ == '__main__':
    asyncio.run(main())


Expected output: 0 + 1 * 3 + 2 * 3 = 9. Actual: 6. Seems to be a race condition.

Same happens for other immutable types: str, tuple (when used as values of dict instead of int). But works correctly with list and custom class with __iadd__ method.

Same effect for treading version (output is the same):


import time
import threading

def count_smth(seconds: int) -> int:
    time.sleep(seconds)
    return seconds * 3

def small_job(d: dict, key: str, seconds: int) -> None:
    d[key] += count_smth(seconds)  # <-- strange happens here

def main() -> None:
    d = dict(key=0)
    t1 = threading.Thread(target=small_job, args=(d, 'key', 1))
    t2 = threading.Thread(target=small_job, args=(d, 'key', 2))
    t1.start()
    t2.start()
    t1.join()
    t2.join()
    print(d['key'])  # expected: 0 + 1 * 3 + 2 * 3 = 9, actual: 6

main()


Inplace operation is expected to occur only at the time when the second operand is evaluated.

----------
Added file: https://bugs.python.org/file48718/inplace_bug_threading.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38817>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:16:55 2019
From: report at bugs.python.org (Andrew Ushakov)
Date: Fri, 15 Nov 2019 20:16:55 +0000
Subject: [issue38755] Long unicode string causes SyntaxError: Non-UTF-8 code
 starting with '\xe2' in file ..., but no encoding declared;
 see http://python.org/dev/peps/pep-0263/ for details
In-Reply-To: <1573302408.95.0.156655994529.issue38755@roundup.psfhosted.org>
Message-ID: <1573849015.67.0.0410764398323.issue38755@roundup.psfhosted.org>


Andrew Ushakov <andrew.ushakov at gmail.com> added the comment:

> On Windows, with 3.7, 3.8.0, and master, neither the posted comment, the one in the file, not the initial statement in #34979 give the SyntaxError.

Just tried again on my corporate laptop with the downloaded file from this site:

Microsoft Windows [Version 10.0.16299.1451]
(c) 2017 Microsoft Corporation. All rights reserved.

D:\Downloads>py
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

D:\Downloads>py tst112.py
  File "tst112.py", line 1
SyntaxError: Non-UTF-8 code starting with '\xe2' in file tst112.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

d:\Downloads>py -3.7
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

d:\Downloads>py -3.7 tst112.py
  File "tst112.py", line 1
SyntaxError: Non-UTF-8 code starting with '\xe2' in file tst112.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38755>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:23:10 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Nov 2019 20:23:10 +0000
Subject: [issue38783] the window size is bigger than the specific size when
 create a window with a fix size in Windows platform
In-Reply-To: <1573630441.73.0.71709021905.issue38783@roundup.psfhosted.org>
Message-ID: <1573849390.53.0.473089260797.issue38783@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

When I add "master.update(); print(master.geometry())" I get "100x100+104+104".  I have the same Windows and 3.7+, but with tcl/tk *8.6*, not the ancient 8.4.   If you really are using the latter, I strongly suggest updating.  Even if not, your result is likely a tcl/tk 3rd party problem, not a tkinter problem.  So I suspect that this should be closed.

----------
nosy: +serhiy.storchaka, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38783>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:28:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Nov 2019 20:28:43 +0000
Subject: [issue38788] Inconsistent documentation of tell/seek on
 textiobase/textiowrapper
In-Reply-To: <1573655788.2.0.430319826045.issue38788@roundup.psfhosted.org>
Message-ID: <1573849723.67.0.3298894172.issue38788@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38788>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:48:00 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Nov 2019 20:48:00 +0000
Subject: [issue38805] locale.getlocale() returns a non RFC1766 language code
In-Reply-To: <1573775129.28.0.0290867966019.issue38805@roundup.psfhosted.org>
Message-ID: <1573850880.87.0.777323364294.issue38805@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38805>
_______________________________________

From report at bugs.python.org  Fri Nov 15 15:53:27 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 15 Nov 2019 20:53:27 +0000
Subject: [issue38782] Convert importlib.abc to use typing.Protocol
In-Reply-To: <1573598860.27.0.897323663705.issue38782@roundup.psfhosted.org>
Message-ID: <1573851207.12.0.116408627521.issue38782@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38782>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:29:07 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 21:29:07 +0000
Subject: [issue38816] Clarify about fork() and the CPython runtime in the
 C-API docs.
In-Reply-To: <1573842946.86.0.905050259402.issue38816@roundup.psfhosted.org>
Message-ID: <1573853347.03.0.195029823696.issue38816@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 73cdb0c6b2c3861e034004cdc57be5e726876078 by Miss Islington (bot) (Eric Snow) in branch 'master':
bpo-38816: Add notes in the C-API docs about fork in subinterpreters. (GH-17176)
https://github.com/python/cpython/commit/73cdb0c6b2c3861e034004cdc57be5e726876078


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38816>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:29:23 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 21:29:23 +0000
Subject: [issue38816] Clarify about fork() and the CPython runtime in the
 C-API docs.
In-Reply-To: <1573842946.86.0.905050259402.issue38816@roundup.psfhosted.org>
Message-ID: <1573853363.98.0.945278068983.issue38816@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +16686
pull_request: https://github.com/python/cpython/pull/17178

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38816>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:30:47 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 21:30:47 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>
Message-ID: <1573853447.59.0.330974247055.issue34651@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16688
pull_request: https://github.com/python/cpython/pull/17179

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:30:47 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 21:30:47 +0000
Subject: [issue38778] Document that os.fork is not allowed in subinterpreters
In-Reply-To: <1573569500.54.0.207485115661.issue38778@roundup.psfhosted.org>
Message-ID: <1573853447.49.0.368427506737.issue38778@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16687
pull_request: https://github.com/python/cpython/pull/17179

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38778>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:36:53 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 21:36:53 +0000
Subject: [issue38816] Clarify about fork() and the CPython runtime in the
 C-API docs.
In-Reply-To: <1573842946.86.0.905050259402.issue38816@roundup.psfhosted.org>
Message-ID: <1573853813.46.0.457895141271.issue38816@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7a5d4c7a8653cb6be126f87731802aa9a4bc90e2 by Miss Islington (bot) in branch '3.8':
bpo-38816: Add notes in the C-API docs about fork in subinterpreters. (GH-17176)
https://github.com/python/cpython/commit/7a5d4c7a8653cb6be126f87731802aa9a4bc90e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38816>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:37:23 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Nov 2019 21:37:23 +0000
Subject: [issue38816] Clarify about fork() and the CPython runtime in the
 C-API docs.
In-Reply-To: <1573842946.86.0.905050259402.issue38816@roundup.psfhosted.org>
Message-ID: <1573853843.89.0.598181159186.issue38816@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38816>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:37:30 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 21:37:30 +0000
Subject: [issue34651] Disallow fork in a subinterpreter.
In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>
Message-ID: <1573853850.29.0.986171387102.issue34651@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a4be5aae6e587f5310f1fc0d66d37e032621ce39 by Miss Islington (bot) in branch '3.8':
bpo-38778: Document that os.fork is not allowed in subinterpreters (GH-17123)
https://github.com/python/cpython/commit/a4be5aae6e587f5310f1fc0d66d37e032621ce39


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34651>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:37:30 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 21:37:30 +0000
Subject: [issue38778] Document that os.fork is not allowed in subinterpreters
In-Reply-To: <1573569500.54.0.207485115661.issue38778@roundup.psfhosted.org>
Message-ID: <1573853850.22.0.595716106476.issue38778@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a4be5aae6e587f5310f1fc0d66d37e032621ce39 by Miss Islington (bot) in branch '3.8':
bpo-38778: Document that os.fork is not allowed in subinterpreters (GH-17123)
https://github.com/python/cpython/commit/a4be5aae6e587f5310f1fc0d66d37e032621ce39


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38778>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:39:07 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Nov 2019 21:39:07 +0000
Subject: [issue38778] Document that os.fork is not allowed in subinterpreters
In-Reply-To: <1573569500.54.0.207485115661.issue38778@roundup.psfhosted.org>
Message-ID: <1573853947.16.0.0245097352526.issue38778@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Flipping the label one more time did the trick.  Thanks again, Phil!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38778>
_______________________________________

From report at bugs.python.org  Fri Nov 15 16:49:05 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Nov 2019 21:49:05 +0000
Subject: [issue26103] Contradiction in definition of "data descriptor" between
 (dotted lookup behavior/datamodel documentation) and (inspect
 lib/descriptor how-to)
In-Reply-To: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za>
Message-ID: <1573854545.87.0.868696953606.issue26103@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16689
pull_request: https://github.com/python/cpython/pull/17180

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26103>
_______________________________________

From report at bugs.python.org  Fri Nov 15 17:30:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2019 22:30:50 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573857050.15.0.082648230476.issue38453@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Windows8.1 Non-Debug 3.x is grumpy:
https://buildbot.python.org/all/#/builders/12/builds/3459

======================================================================
FAIL: test_realpath_cwd (test.test_ntpath.TestNtpath)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_ntpath.py", line 424, in test_realpath_cwd
    self.assertPathEqual(test_file_long, ntpath.realpath(test_file_short))
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_ntpath.py", line 62, in assertPathEqual
    self.assertEqual(path1, path2)
AssertionError: 'D:\\[88 chars]worker_4476\\@test_4476_tmp\\MyVeryLongDirectoryName\\file.txt' != 'D:\\[88 chars]worker_4476\\@test_4476_tmp\\MYVERY~1\\file.txt'
- D:\buildarea\3.x.ware-win81-release.nondebug\build\build\test_python_4088\test_python_worker_4476\@test_4476_tmp\MyVeryLongDirectoryName\file.txt
?                                                                                                                   ^ ^^^^^^^^^^^^^^^^^^^^
+ D:\buildarea\3.x.ware-win81-release.nondebug\build\build\test_python_4088\test_python_worker_4476\@test_4476_tmp\MYVERY~1\file.txt
?                                                                                                                   ^ ^^^^^

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 17:32:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2019 22:32:17 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573857137.08.0.316756265789.issue38453@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Grumpy AMD64 Windows10 3.x:
https://buildbot.python.org/all/#/builders/3/builds/3788

======================================================================
FAIL: test_realpath_cwd (test.test_ntpath.TestNtpath)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_ntpath.py", line 424, in test_realpath_cwd
    self.assertPathEqual(test_file_long, ntpath.realpath(test_file_short))
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_ntpath.py", line 62, in assertPathEqual
    self.assertEqual(path1, path2)
AssertionError: 'D:\\[76 chars]worker_6956\\@test_6956_tmp\\MyVeryLongDirectoryName\\file.txt' != 'D:\\[76 chars]worker_6956\\@test_6956_tmp\\MYVERY~1\\file.txt'
- D:\buildarea\3.x.bolen-windows10\build\build\test_python_6236\test_python_worker_6956\@test_6956_tmp\MyVeryLongDirectoryName\file.txt
?                                                                                                       ^ ^^^^^^^^^^^^^^^^^^^^
+ D:\buildarea\3.x.bolen-windows10\build\build\test_python_6236\test_python_worker_6956\@test_6956_tmp\MYVERY~1\file.txt
?                                                                                                       ^ ^^^^^

pythoninfo:

windows.RtlAreLongPathsEnabled: False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 17:52:34 2019
From: report at bugs.python.org (Dan)
Date: Fri, 15 Nov 2019 22:52:34 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1573858354.01.0.441066203661.issue33125@roundup.psfhosted.org>


Dan <negativeiq at gmail.com> added the comment:

Steve, the 2.7 build I've posted includes native tk, do you need the necessary patches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:20:45 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Nov 2019 23:20:45 +0000
Subject: [issue38813] math.modf() change integer returned part as integer
 instead of float
In-Reply-To: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>
Message-ID: <1573860045.55.0.461175605874.issue38813@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Raymond, I think you've tricked yourself ;-)

Yup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:25:16 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Nov 2019 23:25:16 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573860316.41.0.451546075749.issue38453@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 66c0f01f98fd6db0a4b1e789b9db9c7247a24ba9 by Steve Dower in branch '3.8':
bpo-38453: Ensure ntpath.realpath correctly resolves relative paths (GH-16967)
https://github.com/python/cpython/commit/66c0f01f98fd6db0a4b1e789b9db9c7247a24ba9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:26:32 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Nov 2019 23:26:32 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573860392.07.0.115000308718.issue38453@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, Victor! That looks different from the one I was originally fixing (even though the long/short path mismatch is there), so I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:33:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2019 23:33:32 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573860812.9.0.606578625613.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16690
pull_request: https://github.com/python/cpython/pull/17183

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:39:52 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Nov 2019 23:39:52 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573861192.38.0.0915315136833.issue38453@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +16691
pull_request: https://github.com/python/cpython/pull/17184

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:43:32 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 15 Nov 2019 23:43:32 +0000
Subject: [issue35453] pathlib.Path: glob and rglob should accept PathLike
 patterns
In-Reply-To: <1544439282.17.0.788709270274.issue35453@psf.upfronthosting.co.za>
Message-ID: <1573861412.0.0.0923494236479.issue35453@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

> From what I see, there is no consensus yet.

@serhiy.storchaka said this isn't an issue. I can add tests about this behavior (as you mentioned) or this issue can be directly resolved as not a bug. What are you thinking @nanjekyejoannah and @serhiy.storchaka?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:44:49 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Nov 2019 23:44:49 +0000
Subject: [issue38817] Immutable types inplace operations work incorrect in
 async
In-Reply-To: <1573847808.01.0.483185624752.issue38817@roundup.psfhosted.org>
Message-ID: <1573861489.51.0.493035699582.issue38817@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Inplace operation is expected to occur only at the time when 
> the second operand is evaluated.

That expectation does not match the implementation and it likely isn't possible to get that to work.   In-place operations on immutable objects necessarily create a new object, so the operation isn't as atomic as one might expect (the lookup and the assignment are two separate steps).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38817>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:45:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2019 23:45:02 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573861502.67.0.475565055664.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16692
pull_request: https://github.com/python/cpython/pull/17185

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Nov 15 18:52:36 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 15 Nov 2019 23:52:36 +0000
Subject: [issue38446] Ambiguous signature for builtins.__build_class__
In-Reply-To: <1570793351.47.0.198943437011.issue38446@roundup.psfhosted.org>
Message-ID: <1573861956.8.0.435448511719.issue38446@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

This issue is fixed with PR 16735, @pablogsal can we close it?

----------
nosy: +BTaskaya, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38446>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:02:49 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 16 Nov 2019 00:02:49 +0000
Subject: [issue26011] Document necesities for cmp argument of sorted
In-Reply-To: <1451950339.23.0.203915233375.issue26011@psf.upfronthosting.co.za>
Message-ID: <1573862569.0.0.744976750281.issue26011@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I agree with @josh.r, also for the key (and reverse), they are documented in py3.8. IMHO this issue can be resolved as not a bug.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26011>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:03:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Nov 2019 00:03:25 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573862605.52.0.54508237003.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b5e170f127b57d5b0a4fb58f316acd6191509dce by Victor Stinner in branch 'master':
bpo-38644: Add _PyEval_EvalCode() (GH-17183)
https://github.com/python/cpython/commit/b5e170f127b57d5b0a4fb58f316acd6191509dce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:04:03 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Nov 2019 00:04:03 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573862643.86.0.963832364171.issue38453@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 7c6130c8c36c941255365e5414c956fc919b8629 by Steve Dower in branch 'master':
bpo-38453: Ensure correct short path is obtained for test (GH-17184)
https://github.com/python/cpython/commit/7c6130c8c36c941255365e5414c956fc919b8629


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:04:29 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 00:04:29 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573862669.86.0.497245184751.issue38453@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16693
pull_request: https://github.com/python/cpython/pull/17186

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:04:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Nov 2019 00:04:47 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1573862687.4.0.237880367151.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 51edf8aaa2e17626f9690ed29d25945fc03016b9 by Victor Stinner in branch 'master':
bpo-38644: Cleanup ceval.h (GH-17185)
https://github.com/python/cpython/commit/51edf8aaa2e17626f9690ed29d25945fc03016b9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:06:05 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 16 Nov 2019 00:06:05 +0000
Subject: [issue37083] Document TYPE_COMMENT in documentation reference for
 compound statements
In-Reply-To: <1559079468.64.0.0790187408059.issue37083@roundup.psfhosted.org>
Message-ID: <1573862765.74.0.520409592116.issue37083@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@pablogsal, PR 13202 is merged

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37083>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:11:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Nov 2019 00:11:33 +0000
Subject: [issue38818] Modify PyInterpreterState.eval_frame to pass tstate
 (PyThreadState)
Message-ID: <1573863093.89.0.126489580733.issue38818@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Follow-up of bpo-36710 and bpo-38644: I would like to pass explicitly tstate (PyThreadState) to internal C functions.

The problem is that PyInterpreterState.eval_frame function has no tstate parameter. I propose attached PR to add a tstate parameter. It's a backward incompatible change. The "eval_frame" field comes from the PEP 523.

See also bpo-38500 "Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals".

----------
components: Interpreter Core
messages: 356736
nosy: brett.cannon, vstinner
priority: normal
severity: normal
status: open
title: Modify PyInterpreterState.eval_frame to pass tstate (PyThreadState)
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38818>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:13:41 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 16 Nov 2019 00:13:41 +0000
Subject: [issue33740] PyByteArray_AsString C-API description lacks the
 assurance, that the trailing null-byte is appended.
In-Reply-To: <1527973856.37.0.592728768989.issue33740@psf.upfronthosting.co.za>
Message-ID: <1573863221.67.0.132615731676.issue33740@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

IMHO there is no need/way for adding that clarification after this date (1.5 months left).

----------
nosy: +BTaskaya, benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33740>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:15:32 2019
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Sat, 16 Nov 2019 00:15:32 +0000
Subject: [issue38765] `ast.AST._attributes` is used by `ast.dump()` but not
 documented
In-Reply-To: <1573482663.72.0.733055997415.issue38765@roundup.psfhosted.org>
Message-ID: <1573863332.4.0.95085227637.issue38765@roundup.psfhosted.org>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

I know attributes starting with an underscore are typically considered private, but the already mentioned `_fields` clearly isn't and, for example, `namedtuple` has several methods like `_asdict()` and `_replace()` that are documented to be part of the public API. `_attributes` clearly is part of the API as well but it isn't at all documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38765>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:18:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Nov 2019 00:18:25 +0000
Subject: [issue38818] Modify PyInterpreterState.eval_frame to pass tstate
 (PyThreadState)
In-Reply-To: <1573863093.89.0.126489580733.issue38818@roundup.psfhosted.org>
Message-ID: <1573863505.81.0.948106477441.issue38818@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38818>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:21:31 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 00:21:31 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1573863691.17.0.863413931112.issue38453@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6f602fbd3568ed7bebadfa3c7d3de40a271216f9 by Miss Islington (bot) in branch '3.8':
bpo-38453: Ensure correct short path is obtained for test (GH-17184)
https://github.com/python/cpython/commit/6f602fbd3568ed7bebadfa3c7d3de40a271216f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Fri Nov 15 19:53:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 00:53:38 +0000
Subject: [issue26011] Document necesities for cmp argument of sorted
In-Reply-To: <1451950339.23.0.203915233375.issue26011@psf.upfronthosting.co.za>
Message-ID: <1573865618.42.0.577472592731.issue26011@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26011>
_______________________________________

From report at bugs.python.org  Fri Nov 15 20:14:18 2019
From: report at bugs.python.org (Chris Withers)
Date: Sat, 16 Nov 2019 01:14:18 +0000
Subject: [issue30463] Add __slots__ to ABC convenience class
In-Reply-To: <1495658477.95.0.988068330571.issue30463@psf.upfronthosting.co.za>
Message-ID: <1573866858.83.0.954977862283.issue30463@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

I will note that this means with:

class BaseClass(ABC):
    pass


class MyDerivedClass(BaseClass):

    def __init__(self, thing):
        self.thing = thing

thing = MyDerivedClass()

thing now has both __slots__ and, evidently, a dict. That's a bit weird and confusing.

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30463>
_______________________________________

From report at bugs.python.org  Fri Nov 15 23:34:09 2019
From: report at bugs.python.org (susaki)
Date: Sat, 16 Nov 2019 04:34:09 +0000
Subject: =?utf-8?q?=5Bissue34979=5D_Python_throws_=E2=80=9CSyntaxError=3A_Non-UTF-?=
 =?utf-8?q?8_code_start_with_=5Cxe8=2E=2E=2E=E2=80=9D_when_parse_source_fi?=
 =?utf-8?q?le?=
In-Reply-To: <1573847837.25.0.870999637657.issue34979@roundup.psfhosted.org>
Message-ID: <A4143C6B-475C-418B-BC5A-ADC7F9253C68@gmail.com>


susaki <ljm51689 at gmail.com> added the comment:

I think this issue is duplicated with #14811, I will close it.

The key point of this issue is that the size of `tok->buf` is fixed and equals to `BUFSIZ`(defined in stdio.h, have different value depends on OS).
one line of code will be truncated If it?s size exceeds `BUFSIZ`, then the function `valid_utf8` will failed.

You can increase the size of `s` to reproduce this issue.

? ? cat demo.py
s = '????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????'

? ? ./python -V
Python 3.7.4

? ? ./python demo.py
 File "demo.py", line 1
SyntaxError: Non-UTF-8 code starting with '\xe6' in file demo.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34979>
_______________________________________

From report at bugs.python.org  Sat Nov 16 00:29:13 2019
From: report at bugs.python.org (Alex)
Date: Sat, 16 Nov 2019 05:29:13 +0000
Subject: [issue38819] The redirect
Message-ID: <1573882153.73.0.0661856769758.issue38819@roundup.psfhosted.org>


New submission from Alex <2423067593 at qq.com>:

Hi.
This bug I've found is about the redirect, you know, to redirect the standard input/output stream. It's not really a bug, you can think of it as a feature.
The code is like this:

import sys
sys.stdout = open('redirect.txt','w')

print('hello world!') #Something you want to print
after you run it in the IDLE:

==================== RESTART: XXXXXXXXXXXXXXX.py===================
>>> print(1 + 1)
>>>

You will find you can't output as normal.
The version I choose for this issue is Python 3.8.0b4. However, I find this problem is also exist in Python 3.7.5.
How to repair it?

----------
assignee: terry.reedy
components: IDLE
messages: 356742
nosy: Alex-Python-Programmer, terry.reedy
priority: normal
severity: normal
status: open
title: The redirect
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38819>
_______________________________________

From report at bugs.python.org  Sat Nov 16 00:36:21 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Nov 2019 05:36:21 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573882581.76.0.461131786657.issue38814@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Sorry but with a non-debug build of Python, it's not very likely someone would  be able to glean much from the macOS crash stack trace here.  You also seem to have a very large number of C extension modules, some apparently from Homebrew and others from other sources ("/Users/USER/*/" ?). Also, I don't understand what you mean by:

"I use homebrew with the latest packages and python3.7.5 is now compiled from source, to avoid dependency problems."

And it seems you were reporting lots of problems on IRC beyond what is reported here.

The best I can suggest is to try to ensure that all binaries you are using are all from one source, for example, Homebrew or conda, and make sure any packages with C extension modules are built using the same python instance.  If the problem persists, you may need to consider installing a debug version of Python or building one from source (./configure --with-pydebug ... ) but for 3.7.x at least that means you will also need to rebuild all packages that have C extension modules as debug mode has a different ABI.

Please feel free to reopen this issue with a reproducible test case if further investigation suggests a problem with Python itself.  Good luck!

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 00:52:38 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Nov 2019 05:52:38 +0000
Subject: [issue38819] The redirect
In-Reply-To: <1573882153.73.0.0661856769758.issue38819@roundup.psfhosted.org>
Message-ID: <1573883558.75.0.332613597059.issue38819@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If your goal is to temporarily redirect stdout, there are a couple ways to do it:

    with open('dest1.txt', 'w') as target_file:
        print('hello world', file=target_file)

or:

    with open('dest1.txt', 'w') as target_file:
        with contextlib.redirect_stdout(target_file)
             print('hello world')

Both of these techniques temporarily alter where printing is directed.

In contrast, the code posted above permanently alters the target unless explictly reset.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38819>
_______________________________________

From report at bugs.python.org  Sat Nov 16 01:57:04 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Nov 2019 06:57:04 +0000
Subject: [issue38819] The redirect
In-Reply-To: <1573882153.73.0.0661856769758.issue38819@roundup.psfhosted.org>
Message-ID: <1573887424.51.0.598109212174.issue38819@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If you do the same in the standard python REPL, you get the same result.  So this behavior is not specific to IDLE, although one has to be slightly more careful restoring sys.stdout in IDLE.  (Restoring stdout from saved stdout should work the same without or with IDLE.  Restoring stdout from __stdout__ does not work in IDLE because IDLE redirects stdout from the original value.)

This tracker is for patching real bugs.  Questions about how to use python should be directed elsewhere, such as python-list.

----------
assignee: terry.reedy -> 
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38819>
_______________________________________

From report at bugs.python.org  Sat Nov 16 04:20:49 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Sat, 16 Nov 2019 09:20:49 +0000
Subject: [issue38721] modulefinder should use import hooks properly
In-Reply-To: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>
Message-ID: <1573896049.19.0.809647958259.issue38721@roundup.psfhosted.org>


Dominic Littlewood <11dlittlewood at gmail.com> added the comment:

Okay, I've encountered a snag. To use meta path finders, if the path is None, it's sometimes okay to substitute self.path, and sometimes not. The only way to make absolutely sure the finder works correctly is to change sys.path. To use namespace packages (and possibly some other types of modules finders might produce), it's also necessary to adjust sys.modules. However, both of these things may cause problems if a hook wants to import something in the standard way so it can run properly. This will require some thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Sat Nov 16 05:12:34 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 10:12:34 +0000
Subject: [issue36589] Incorrect error handling in curses.update_lines_cols()
In-Reply-To: <1554923035.79.0.592038232821.issue36589@roundup.psfhosted.org>
Message-ID: <1573899154.61.0.0774687032776.issue36589@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Historically the update_lines_cols() helper returned 0 on error, and I think that it is better to keep it so.

The bug is in the Python function update_lines_cols() added in 3.5 (see issue4254). Its implementation should return NULL if the helper returns 0, and None otherwise. There is no reason to return an integer.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36589>
_______________________________________

From report at bugs.python.org  Sat Nov 16 07:09:37 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Nov 2019 12:09:37 +0000
Subject: [issue38813] math.modf() change integer returned part as integer
 instead of float
In-Reply-To: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>
Message-ID: <1573906177.26.0.17390508779.issue38813@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Tim]

> I don't think it would be doing anyone a real favor by returning [...]

Agreed.

> math.floor(), which does return an int, [...] and I believe it was a mistake to change it to return an int.

Also agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________

From report at bugs.python.org  Sat Nov 16 07:38:04 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 12:38:04 +0000
Subject: [issue38813] math.modf() change integer returned part as integer
 instead of float
In-Reply-To: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>
Message-ID: <1573907884.67.0.44965764349.issue38813@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> math.floor(), which does return an int, [...] and I believe it was a mistake to change it to return an int.

What about math.trunc() and round()? Should they return int or float?

And what about the result of the floor division of floats? Should it be int or float?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________

From report at bugs.python.org  Sat Nov 16 10:06:59 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Nov 2019 15:06:59 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
Message-ID: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

OpenSSL 3.0.0 is currently development [1]. I'm expecting a first beta release in December. Final release is scheduled for Q2 2020. OpenSSL 3.0.0 is API and feature compatible to OpenSSL 1.1.0 and 1.1.1. Only minor changes are required:

* OpenSSL version number is >= 3.0.0, which breaks test_openssl_version
* GENERAL_NAME_print() no longer adds trailing newline to IPv6 address strings. 
* ERR_func_error_string is deprecated

[1] https://www.openssl.org/blog/blog/2019/11/07/3.0-update/

----------
assignee: christian.heimes
components: SSL
messages: 356750
nosy: christian.heimes
priority: high
severity: normal
status: open
title: Make Python compatible with OpenSSL 3.0.0
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38820>
_______________________________________

From report at bugs.python.org  Sat Nov 16 10:11:57 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Nov 2019 15:11:57 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
In-Reply-To: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>
Message-ID: <1573917117.1.0.462155474559.issue38820@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38820>
_______________________________________

From report at bugs.python.org  Sat Nov 16 10:44:18 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Nov 2019 15:44:18 +0000
Subject: [issue38813] math.modf() change integer returned part as integer
 instead of float
In-Reply-To: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>
Message-ID: <1573919058.01.0.283115626172.issue38813@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Serhiy]

> What about math.trunc() and round()? Should they return int or float?

math.trunc was deliberately introduced to be an explicitly-value-modifying conversion to int (as opposed to "int" itself, which is used for both lossy and lossless conversions to int); so from that perspective it should return int.

round is less problematic than floor and ceil because it provides a way to preserve the type (by using `0` as the second argument).

Single-argument round frequently turns out to be the right way to convert a float to an int in practice (e.g., in something like `nsteps = round((stop - start) / step)`, in a case where you know in advance that mathematically stop - start is a small integer multiple of step, but floating-point errors might cause the quotient to deviate from that integer by a small amount in either direction), so I've often appreciated the convenience of being able to use `round(some_float)` instead of `int(round(some_float))`.

Floor division of floats already returns a float, and I can't see a strong reason to change that. It's not exactly the most useful floating-point operation in the first place, so it's hard to find use-cases that argue for one return type over the other.

But I think all of this is academic: it's another case of "Should we have done this differently in the first place?" versus "Should we change it now?". The answer to the first question *might* be "Yes" for some pieces, but the answer to the second is almost certainly "No".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________

From report at bugs.python.org  Sat Nov 16 10:48:51 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Nov 2019 15:48:51 +0000
Subject: [issue38813] math.modf() change integer returned part as integer
 instead of float
In-Reply-To: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>
Message-ID: <1573919331.21.0.224391724089.issue38813@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the suggestion. I'm closing this as rejected, for the reasons Tim gave.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38813>
_______________________________________

From report at bugs.python.org  Sat Nov 16 11:01:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 16:01:02 +0000
Subject: [issue38639] Optimize floor(), ceil() and trunc() for floats
In-Reply-To: <1572427776.81.0.21510885347.issue38639@roundup.psfhosted.org>
Message-ID: <1573920062.24.0.371635749964.issue38639@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5fd5cb8d85fab3393dd76c7f3de1cdeb8ecf7203 by Serhiy Storchaka in branch 'master':
bpo-38639: Optimize floor(), ceil() and trunc() for floats. (GH-16991)
https://github.com/python/cpython/commit/5fd5cb8d85fab3393dd76c7f3de1cdeb8ecf7203


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38639>
_______________________________________

From report at bugs.python.org  Sat Nov 16 11:08:04 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 16 Nov 2019 16:08:04 +0000
Subject: [issue37083] Document TYPE_COMMENT in documentation reference for
 compound statements
In-Reply-To: <1559079468.64.0.0790187408059.issue37083@roundup.psfhosted.org>
Message-ID: <1573920484.68.0.391586494092.issue37083@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37083>
_______________________________________

From report at bugs.python.org  Sat Nov 16 11:42:36 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 16 Nov 2019 16:42:36 +0000
Subject: [issue38790] test_fcntl failing on macOS CI
In-Reply-To: <1573684464.1.0.222448542247.issue38790@roundup.psfhosted.org>
Message-ID: <1573922556.09.0.719132957719.issue38790@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

This issue was reported from victor

See https://bugs.python.org/msg356607
And I attached the patch for this on GH 17154.
Please take a look at the patch also.

I apologize for the trouble as the original test code author.

----------
keywords: +patch
message_count: 1.0 -> 2.0
nosy: +corona10
nosy_count: 4.0 -> 5.0
pull_requests: +16697
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17154

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38790>
_______________________________________

From report at bugs.python.org  Sat Nov 16 11:44:56 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 16 Nov 2019 16:44:56 +0000
Subject: [issue38790] test_fcntl failing on macOS CI
In-Reply-To: <1573684464.1.0.222448542247.issue38790@roundup.psfhosted.org>
Message-ID: <1573922696.5.0.691957233686.issue38790@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38790>
_______________________________________

From report at bugs.python.org  Sat Nov 16 11:55:33 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 16:55:33 +0000
Subject: [issue38650] Add constantness to PyStructSequence_UnnamedField
In-Reply-To: <1572465703.12.0.701099038847.issue38650@roundup.psfhosted.org>
Message-ID: <1573923333.37.0.446174003642.issue38650@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bd44a7ead9f7336d7bb45f186b2b6ca0300154f7 by Serhiy Storchaka in branch 'master':
bpo-38650: Constify PyStructSequence_UnnamedField. (GH-17005)
https://github.com/python/cpython/commit/bd44a7ead9f7336d7bb45f186b2b6ca0300154f7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38650>
_______________________________________

From report at bugs.python.org  Sat Nov 16 11:57:00 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 16:57:00 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1573923420.44.0.607939693946.issue28286@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a0652328a26757a90d63697b5c01f5427b1132b5 by Serhiy Storchaka in branch 'master':
bpo-28286: Deprecate opening GzipFile for writing implicitly. (GH-16417)
https://github.com/python/cpython/commit/a0652328a26757a90d63697b5c01f5427b1132b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:11:50 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 16 Nov 2019 17:11:50 +0000
Subject: [issue38650] Add constantness to PyStructSequence_UnnamedField
In-Reply-To: <1572465703.12.0.701099038847.issue38650@roundup.psfhosted.org>
Message-ID: <1573924310.31.0.931333605351.issue38650@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Looks like https://github.com/python/cpython/blob/088b63ea7a8331a3e34bc93c3b873c60354b4fad/Tools/c-analyzer/known.tsv#L1549 should be updated also.
What do you think?

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38650>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:20:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 17:20:06 +0000
Subject: [issue32856] Optimize the `for y in [x]` idiom in comprehensions
In-Reply-To: <1518770483.24.0.467229070634.issue32856@psf.upfronthosting.co.za>
Message-ID: <1573924806.28.0.468425233193.issue32856@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> However, that's still going to be clearer to most readers than writing

It is subjective. To me, j+1/j looks clearer than (j:=i*i)+1/j. In addition, the for-as-assignment idiom is more powerful in context of comprehensions, it allows to set an initial value. In any case I want to have a choice.

> OOC, rather than optimizing a fairly ugly use case, might another approach be to make walrus less leaky?

I think this ship is sailed. The semantic of the walrus operator is complex enough to make it even more complex by adding more special cases. Also, while the function-wide optimization of variables is possible, it much more complex problem than the proposed simple optimization.

> You should probably rerun your benchmarks though

$ ./python -m timeit -s 'a = list(range(1000))' -- '[y for x in a for y in [x]]'
Unpatched:  5000 loops, best of 5: 66.8 usec per loop
Patched:   10000 loops, best of 5: 21.5 usec per loop

$ ./python -m timeit -s 'a = list(range(1000))' -- '[x for x in a]'
20000 loops, best of 5: 17.8 usec per loop

Issue32925 reduce the difference, but it is still large (~12).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32856>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:22:08 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Nov 2019 17:22:08 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
In-Reply-To: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>
Message-ID: <1573924928.98.0.357915839302.issue38820@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

PR GH-17190 fixes test_openssl_version and removes the trailing newline from IPv6 addresses on all OpenSSL versions. I prefer to have the output consistent on all OpenSSL versions. The newline was silly any way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38820>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:22:24 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 17:22:24 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1573924944.25.0.046842629329.issue28286@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:22:45 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 17:22:45 +0000
Subject: [issue38650] Add constantness to PyStructSequence_UnnamedField
In-Reply-To: <1572465703.12.0.701099038847.issue38650@roundup.psfhosted.org>
Message-ID: <1573924965.46.0.856047245866.issue38650@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38650>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:23:10 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2019 17:23:10 +0000
Subject: [issue38639] Optimize floor(), ceil() and trunc() for floats
In-Reply-To: <1572427776.81.0.21510885347.issue38639@roundup.psfhosted.org>
Message-ID: <1573924990.85.0.399707847037.issue38639@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38639>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:37:53 2019
From: report at bugs.python.org (susaki)
Date: Sat, 16 Nov 2019 17:37:53 +0000
Subject: =?utf-8?q?=5Bissue34979=5D_Python_throws_=E2=80=9CSyntaxError=3A_Non-UTF-?=
 =?utf-8?q?8_code_start_with_=5Cxe8=2E=2E=2E=E2=80=9D_when_parse_source_fi?=
 =?utf-8?q?le?=
In-Reply-To: <1539482499.11.0.788709270274.issue34979@psf.upfronthosting.co.za>
Message-ID: <1573925873.86.0.0875122705604.issue34979@roundup.psfhosted.org>


susaki <ljm51689 at gmail.com> added the comment:

duplicated with #14811

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34979>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:43:26 2019
From: report at bugs.python.org (Federico Bond)
Date: Sat, 16 Nov 2019 17:43:26 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
Message-ID: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>


New submission from Federico Bond <federico.bond at gmail.com>:

The call to 'ngettext' in 'ArgumentParser._match_argument' (Lib/argparse.py) uses a non-integer value, which causes it to fail with a nonsensical exception. Non-integer values were deprecated in bpo-28692.

This happens because the 'default' error message is computed unconditionally, even when the value of 'action.nargs' is 'None' and another message will be ultimately selected.

This issue is similar to bpo-35785 which was not reproduced by other people at the moment and was eventually closed. I could not create a short reproducer but could match several of the points described in that issue. A little debugging turned up that gettext was loading a catalog from the 'natural' PyPI package which uses 'Plural-Forms' too.

  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1755, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1787, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1993, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1923, in consume_optional
    arg_count = match_argument(action, selected_patterns)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 2086, in _match_argument
    action.nargs) % action.nargs
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/gettext.py", line 631, in ngettext
    return dngettext(_current_domain, msgid1, msgid2, n)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/gettext.py", line 610, in dngettext
    return t.ngettext(msgid1, msgid2, n)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/gettext.py", line 462, in ngettext
    tmsg = self._catalog[(msgid1, self.plural(n))]
  File "<string>", line 4, in func
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/gettext.py", line 168, in _as_int
    (n.__class__.__name__,)) from None
TypeError: Plural value must be an integer, got NoneType

----------
components: Library (Lib)
messages: 356761
nosy: Federico Bond
priority: normal
severity: normal
status: open
title: argparse calls ngettext with deprecated non-integer value
type: crash
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:48:12 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 16 Nov 2019 17:48:12 +0000
Subject: [issue37083] Document TYPE_COMMENT in documentation reference for
 compound statements
In-Reply-To: <1559079468.64.0.0790187408059.issue37083@roundup.psfhosted.org>
Message-ID: <1573926492.82.0.247834207809.issue37083@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Honestly I don't think that the exact places where TYPE_COMMENT goes in the grammar should be documented as part of the language reference.  For almost all of them we should be using type annotation syntax, and IMO for the remaining ones we should either add syntax or just move the declaration to a line by itself using `var: type` (PEP 526).

Also note that these are irrelevant to most users -- they only come into play when ast.parse(type_comments=True) is used, or when code is parsed by a separate tool like mypy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37083>
_______________________________________

From report at bugs.python.org  Sat Nov 16 12:52:50 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Nov 2019 17:52:50 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1573926770.23.0.563677683916.issue38821@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Sat Nov 16 13:14:54 2019
From: report at bugs.python.org (CrouZ)
Date: Sat, 16 Nov 2019 18:14:54 +0000
Subject: [issue38822] Inconsistent os.stat behavior for directory with Access
 Denied
Message-ID: <1573928094.88.0.209131085868.issue38822@roundup.psfhosted.org>


New submission from CrouZ <alfred.theorin at gmail.com>:

After upgrading some scripts from Python 2.7 to 3.7 in Windows 10, I got different behavior that seems to be caused by inconsistent behavior for os.stat in Python 3.7.

Python 2.7:
>>> os.stat("D:\\System Volume Information")
nt.stat_result ...
>>> os.stat("D:\\System Volume Information\\")
nt.stat_result ... (same as previous call)

Python 3.7:
>>> os.stat("D:\\System Volume Information")
os.stat_result ...
>>> os.stat("D:\\System Volume Information\\")
Traceback ...
PermissionError: [WinError 5] Access is denied: 'D:\\System Volume Information\\'



What I really do is calling:
>>> os.path.exists("D:\\System Volume Information\\")
False (Unexpected and inconsistent. I expect the return value to be True.)

Behavior for other calls:
>>> os.path.exists("D:\\System Volume Information")
True (OK)
>>> os.path.isdir("D:\\System Volume Information\\")
True (OK, but according to the documentation "Return True if path is an existing directory." where 'existing' links to os.path.exists, which returns False)

The closest issue I could find was Issue28075 which has already been fixed.

----------
components: Windows
messages: 356763
nosy: CrouZ, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Inconsistent os.stat behavior for directory with Access Denied
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38822>
_______________________________________

From report at bugs.python.org  Sat Nov 16 13:54:25 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 16 Nov 2019 18:54:25 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
Message-ID: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

Many of the C stdlib modules can benefit from improved error handling during initialization. I've now had two PRs where the authors had reference leaks on error conditions, but defended their decisions by pointing to examples of similar idioms all over the stdlib.

The problems fall into two related categories, mostly:

- Not DECREF'ing the new module object on failure.
- Not handling errors raised by the PyModule_Add* family of functions... specifically, the weird steal-on-success semantics of PyModule_AddObject. I've already improved the docs for this, so we should see the issue less, but our own code should still be fixed.

I intend to turn this into a longer term project. I'll be working my way through these modules bit-by-bit over time, using this issue to track all of them (since there are a few dozen cases). I'd rather not make one huge one that spams all of the code owners and is impossible to review.

If anybody want to make themselves available to review/merge these as I go along, that would be great! Many of the ones I'll start with are just adding trivial DECREFs to the more popular modules (_asyncio, _contextvars, _functools, _random, _warnings, etc...).

----------
assignee: brandtbucher
components: Library (Lib)
messages: 356764
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Improve stdlib module initialization error handling.
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 14:23:29 2019
From: report at bugs.python.org (Arslan Mahmood)
Date: Sat, 16 Nov 2019 19:23:29 +0000
Subject: [issue38824] [security] requests connects to a wrong host
Message-ID: <1573932209.82.0.268574284955.issue38824@roundup.psfhosted.org>


Change by Arslan Mahmood <h47k6m4n at gmail.com>:


----------
components: Regular Expressions
nosy: Arslan Mahmood, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: [security] requests connects to a wrong host
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38824>
_______________________________________

From report at bugs.python.org  Sat Nov 16 14:25:42 2019
From: report at bugs.python.org (Arslan Mahmood)
Date: Sat, 16 Nov 2019 19:25:42 +0000
Subject: [issue38824] sasddsdsd
Message-ID: <1573932342.06.0.54500557089.issue38824@roundup.psfhosted.org>


Change by Arslan Mahmood <h47k6m4n at gmail.com>:


----------
assignee:  -> christian.heimes
components: +SSL -Regular Expressions
nosy: +christian.heimes
title: [security] requests connects to a wrong host -> sasddsdsd
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38824>
_______________________________________

From report at bugs.python.org  Sat Nov 16 14:37:20 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 16 Nov 2019 19:37:20 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573933040.11.0.59069542647.issue38823@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

How do others feel about the creation of a new private API? It would keep these diffs smaller and ease refactoring... and it would probably be good to have around anyways:

/* Like PyModule_AddObject, but steals o on success AND failure. */

int
_PyModule_StealObject(PyObject *m, const char *name, PyObject *o)
{
    if (PyModule_AddObject(m, name, o) < 0) {
        Py_XDECREF(o);
        return -1;
    }
    return 0;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 15:23:38 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 16 Nov 2019 20:23:38 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573935818.25.0.334494205897.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 15:42:43 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 16 Nov 2019 20:42:43 +0000
Subject: [issue22640] Add silent mode for py_compile
In-Reply-To: <1413361400.01.0.34334853586.issue22640@psf.upfronthosting.co.za>
Message-ID: <1573936963.3.0.888265898667.issue22640@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Internal functions got the parameter added, but not the command-line interface.  Should this be reopened, or a different ticket?  (I think only remove the NameError in 3.8, but complete the feature in 3.9)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22640>
_______________________________________

From report at bugs.python.org  Sat Nov 16 15:50:27 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=)
Date: Sat, 16 Nov 2019 20:50:27 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573937427.16.0.0204101310716.issue38814@roundup.psfhosted.org>


L?szl? K?rolyi <laszlo at karolyi.hu> added the comment:

Hello,

the only C extension I use is xapian and mysql (with mariadb), xapian comes from their own git repo, and mariadb comes from mysqlclient, both (and everything else I don't know about) compile with the python 3.7.5 I installed within a venv.

I'll try to recompile python with the debug mode enabled, and then reinstall the entire venv to see what debug I get.

Where should I look for debug logs then?

Also, as you might have seen from the irc logs and the pastebin links posted there, python crashes somewhere around reading the django language directories, for a mystical reason. Yet to be found out.

----------
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 15:55:53 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 16 Nov 2019 20:55:53 +0000
Subject: [issue22640] Add silent mode for py_compile
In-Reply-To: <1413361400.01.0.34334853586.issue22640@psf.upfronthosting.co.za>
Message-ID: <1573937753.83.0.0963079392775.issue22640@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Am in favor of opening a separate ticket for this. Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22640>
_______________________________________

From report at bugs.python.org  Sat Nov 16 15:58:00 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Nov 2019 20:58:00 +0000
Subject: [issue38824] sasddsdsd
Message-ID: <1573937880.31.0.69640606855.issue38824@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

Empty / invalid bug report

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38824>
_______________________________________

From report at bugs.python.org  Sat Nov 16 16:08:05 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Nov 2019 21:08:05 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573938485.21.0.398201085388.issue38814@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The stack track is pretty suspicious.  I really don't know why it would be crashing where it shows which seems to be pretty early in the interpreter.  If you haven't already, you might just want to try reinstalling from Homebrew first and try again.  If you do try a debug build and it still crashes, the stack trace should be very explicit about where it is crashing.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 16:08:14 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Nov 2019 21:08:14 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573938494.81.0.552129608538.issue38814@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 16:10:09 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 16 Nov 2019 21:10:09 +0000
Subject: [issue38782] Convert importlib.abc to use typing.Protocol
In-Reply-To: <1573598860.27.0.897323663705.issue38782@roundup.psfhosted.org>
Message-ID: <1573938609.1.0.950327562442.issue38782@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38782>
_______________________________________

From report at bugs.python.org  Sat Nov 16 16:57:59 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 16 Nov 2019 21:57:59 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573941479.81.0.096403400177.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:19:58 2019
From: report at bugs.python.org (Lord Anton Hvornum)
Date: Sat, 16 Nov 2019 22:19:58 +0000
Subject: [issue38825] psutil.disk_usage - Lacking documentation
Message-ID: <1573942798.11.0.196925055555.issue38825@roundup.psfhosted.org>


New submission from Lord Anton Hvornum <anton.doxid at gmail.com>:

https://docs.python.org/3.8/library/shutil.html#shutil.disk_usage

There's no mention that this helper function simply calls `os.statvfs()` in the background. Something that is quite troubling when you're trying to get disk_usage (or disk-information) about a non-mounted drive.

It's clear as day if you see the code: https://github.com/python/cpython/blob/master/Lib/shutil.py#L1249

But if you're a novice user, this will puzzle your brain.
Because the end result will be that `disk_usage()` returns the same information for all these cases:

shutil.disk_usage('/dev/sda')
shutil.disk_usage('/dev/sdb')
shutil.disk_usage('/dev/sdc')

Which translates to:

os.statvfs('/dev/sd?')'

--

All I'm asking, is that we add a little note stating:
"On *mounted* filesystems" or a reference to `os.statvfs()` where it's clearly stated that it runs on mounted filesystems.

Thanks in advance.

----------
assignee: docs at python
components: Documentation
messages: 356771
nosy: Lord Anton Hvornum, docs at python
priority: normal
severity: normal
status: open
title: psutil.disk_usage - Lacking documentation
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38825>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:25:37 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=)
Date: Sat, 16 Nov 2019 22:25:37 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573943137.08.0.407204157185.issue38814@roundup.psfhosted.org>


L?szl? K?rolyi <laszlo at karolyi.hu> added the comment:

So after making the changes, recompiling everything and using `python -X faulthandler backend/manage.py runserver --nothreading --noasgi --noreload` to start django without the autoreloader that hides the crashed process' output, here's what I get:

  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py", line 364 in __init__
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/_perf/_big_num_ctypes.py", line 39 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/_int.py", line 56 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/_elliptic_curve.py", line 51 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/keys.py", line 22 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/x509/extensions.py", line 14 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/x509/base.py", line 16 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/x509/__init__.py", line 8 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1035 in _handle_fromlist
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 18 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/hazmat/backends/openssl/__init__.py", line 7 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 953 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/cryptography/hazmat/backends/__init__.py", line 15 in default_backend
  File "/Users/laszlokarolyi/Work/project/backend/ticketshop/printing/api/v1/qz_signer.py", line 19 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/backend/ticketshop/printing/api/urls.py", line 4 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/backend/ticketshop/urls_api.py", line 11 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "/Users/laszlokarolyi/Work/project/backend/ticketshop/urls.py", line 9 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006 in _gcd_import
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/importlib/__init__.py", line 127 in import_module
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/urls/resolvers.py", line 400 in urlconf_module
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/utils/functional.py", line 35 in __get__
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/urls/resolvers.py", line 407 in url_patterns
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/utils/functional.py", line 35 in __get__
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/urls/resolvers.py", line 256 in check
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/core/checks/urls.py", line 26 in check_resolver
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/core/checks/urls.py", line 16 in check_url_config
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/core/checks/registry.py", line 81 in run_checks
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/core/management/base.py", line 346 in _run_checks
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/core/management/base.py", line 359 in check
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/core/management/commands/runserver.py", line 124 in inner_run
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/channels/management/commands/runserver.py", line 66 in inner_run
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/django/core/management/commands/runserver.py", line 111 in run
  ...
fish: 'python -X faulthandler backend/?' terminated by signal SIGABRT (Abort)

Not sure what this is, but it seems something's happening in ctypes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:26:58 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 22:26:58 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573943218.39.0.633428184863.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c3f6bdc332d23588102eba749a5929dd5bb67c9d by Miss Islington (bot) (Brandt Bucher) in branch 'master':
bpo-38823: Clean up refleaks in _asyncio initialization. (GH-17195)
https://github.com/python/cpython/commit/c3f6bdc332d23588102eba749a5929dd5bb67c9d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:27:09 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 22:27:09 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573943229.21.0.303189759922.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16700
pull_request: https://github.com/python/cpython/pull/17196

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:27:15 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 22:27:15 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573943235.7.0.592663499113.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16701
pull_request: https://github.com/python/cpython/pull/17197

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:44:30 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 22:44:30 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573944270.71.0.658213254068.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 48f4f75baeee8ade1fbfab1b0aa6a21a3b13a2f2 by Miss Islington (bot) in branch '3.8':
bpo-38823: Clean up refleaks in _asyncio initialization. (GH-17195)
https://github.com/python/cpython/commit/48f4f75baeee8ade1fbfab1b0aa6a21a3b13a2f2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:45:28 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 22:45:28 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573944328.14.0.0242744440293.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 825e91be0407d6fc7fa034286b4e90634f181fab by Miss Islington (bot) in branch '3.7':
bpo-38823: Clean up refleaks in _asyncio initialization. (GH-17195)
https://github.com/python/cpython/commit/825e91be0407d6fc7fa034286b4e90634f181fab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:47:09 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 16 Nov 2019 22:47:09 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1573944429.4.0.74259650545.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> (a) design the API correctly; 
> (b) ship something that definitely works with a proven ThreadPoolExecutor; 

Yury and Andrew, here's my latest API design for asyncio.ThreadPool: https://github.com/python/cpython/compare/master...aeros:asyncio-threadpool. This is for the initial ThreadPoolExecutor version, using the design based on Yury's suggestions. I plan on extending upon the docstrings, writing tests, and the documentation for it.

My idea was to use the new Lib/asyncio/pools.py and AbstractPool to eventually implement an asyncio.ProcessPool (and the native version of asyncio.ThreadPool).

I plan on opening a PR after I finish writing some tests and documentation, I'd like to include it all in the same PR if possible. But let me know what you think about the current API design, it would be much easier for me to make modifications at this stage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Sat Nov 16 17:55:00 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=)
Date: Sat, 16 Nov 2019 22:55:00 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573944900.53.0.601933986168.issue38814@roundup.psfhosted.org>


L?szl? K?rolyi <laszlo at karolyi.hu> added the comment:

As I'm triangulating the problem down, I can now reproduce the problem without running django:

python -X faulthandler -c 'from asn1crypto._perf import _big_num_ctypes'

gives the output:

Fatal Python error: Aborted

Current thread 0x0000000117155dc0 (most recent call first):
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py", line 364 in __init__
  File "/Users/laszlokarolyi/Work/project/venv/lib/python3.7/site-packages/asn1crypto/_perf/_big_num_ctypes.py", line 39 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 728 in exec_module
  File "<frozen importlib._bootstrap>", line 677 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 967 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 983 in _find_and_load
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1035 in _handle_fromlist
  File "<string>", line 1 in <module>
fish: 'python -X faulthandler -c 'from?' terminated by signal SIGABRT (Abort)

I took the opportunity to see what library loading fails, by printing self._name and mode before line 365 in ctypes/__init__.py:

It tries to load /usr/lib/libcrypto.dylib with mode 4, and that's where it crashes.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 18:00:14 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=)
Date: Sat, 16 Nov 2019 23:00:14 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573945214.88.0.167805910747.issue38814@roundup.psfhosted.org>


L?szl? K?rolyi <laszlo at karolyi.hu> added the comment:

Here's an md5sum of /usr/lib/libcrypto.dylib:

MD5 (/usr/lib/libcrypto.dylib) = d19ca8b227c32d30f92ed0665dfe73d0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 18:13:47 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 16 Nov 2019 23:13:47 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573946027.6.0.0770515239156.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16702
pull_request: https://github.com/python/cpython/pull/17198

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 18:34:26 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Nov 2019 23:34:26 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573947266.77.0.163310668692.issue38814@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Almost any kind of crash is possible when using ctypes.  But you almost certainly don't want to be loading /usr/lib/libcrypto.dylib.  That's the macOS legacy version which is there only for legacy Apple-supplied third-party components, like the Apple-supplie system Python.  Apple doesn't even supply the header files for the system libssl and libcrypto deliberately so you are not supposed to be able to successfully link with them.  So you should try to figure out why asn1crypto is apparently linked with it.  It should likely be trying to link with a libcrypto provided by Homebrew openssl.  Good luck.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 18:54:52 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=)
Date: Sat, 16 Nov 2019 23:54:52 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573948492.88.0.543393041537.issue38814@roundup.psfhosted.org>


L?szl? K?rolyi <laszlo at karolyi.hu> added the comment:

Upon reinstalling openssl with homebrew, I get the following info:

--------------
openssl is keg-only, which means it was not symlinked into /usr/local,
because Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries.

If you need to have openssl first in your PATH run:
  echo 'set -g fish_user_paths "/usr/local/opt/openssl/bin" $fish_user_paths' >> ~/.config/fish/config.fish

For compilers to find openssl you may need to set:
  set -gx LDFLAGS "-L/usr/local/opt/openssl/lib"
  set -gx CPPFLAGS "-I/usr/local/opt/openssl/include"

For pkg-config to find openssl you may need to set:
  set -gx PKG_CONFIG_PATH "/usr/local/opt/openssl/lib/pkgconfig"
----------------

So assumingly the system-wide library should be preferred, may it be whatever one.

`/usr/bin/openssl version` says LibreSSL 2.8.3.

Probably I could still link to the homebrew installed SSL using the provided flags, but I'm quite sure this same problem will pop up at a lot of other Catalina users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 18:57:36 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 23:57:36 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573948656.17.0.93713186699.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 143a97f64128070386b12a0ee589bdaad5e51f40 by Miss Islington (bot) (Brandt Bucher) in branch 'master':
bpo-38823: Clean up refleaks in _contextvars initialization. (GH-17198)
https://github.com/python/cpython/commit/143a97f64128070386b12a0ee589bdaad5e51f40


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 18:57:46 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 23:57:46 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573948666.89.0.759293119526.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16703
pull_request: https://github.com/python/cpython/pull/17199

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 18:58:29 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Nov 2019 23:58:29 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573948709.43.0.198761338526.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16704
pull_request: https://github.com/python/cpython/pull/17200

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 19:14:52 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 17 Nov 2019 00:14:52 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573949692.15.0.0297195572105.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8a334af13368573cc645488481b1173d65eeeb9a by Miss Islington (bot) in branch '3.7':
bpo-38823: Clean up refleaks in _contextvars initialization. (GH-17198)
https://github.com/python/cpython/commit/8a334af13368573cc645488481b1173d65eeeb9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 19:16:36 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 17 Nov 2019 00:16:36 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573949796.68.0.332596636227.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1fe79a43400d092a074c6f9ae5eb290ea3e4f281 by Miss Islington (bot) in branch '3.8':
bpo-38823: Clean up refleaks in _contextvars initialization. (GH-17198)
https://github.com/python/cpython/commit/1fe79a43400d092a074c6f9ae5eb290ea3e4f281


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sat Nov 16 20:03:59 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Nov 2019 01:03:59 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573952639.91.0.781722759056.issue38814@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Sorry, we have strayed from dealing with a Python issue here so, if you need nore assistance, you really should seek help elsewhere.  But a quick web search found this which seems to describe your problem:

https://github.com/wbond/asn1crypto/issues/113

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sat Nov 16 20:45:42 2019
From: report at bugs.python.org (Ben Caller)
Date: Sun, 17 Nov 2019 01:45:42 +0000
Subject: [issue38826] Regular Expression Denial of Service in
 urllib.request.AbstractBasicAuthHandler
Message-ID: <1573955142.95.0.285133152076.issue38826@roundup.psfhosted.org>


New submission from Ben Caller <bcaller at gmail.com>:

The regular expression urllib.request.AbstractBasicAuthHandler.rx is vulnerable to malicious inputs which cause denial of service (REDoS).

The regex is:

    rx = re.compile('(?:.*,)*[ \t]*([^ \t]+)[ \t]+'
                    'realm=(["\']?)([^"\']*)\\2', re.I)

The first line can act like:

    (,*,)*(,+)[ \t]

Showing that there are many different ways to match a long sequence of commas.

Input from the WWW-Authenticate or Proxy-Authenticate headers of HTTP responses will reach the regex via the http_error_auth_reqed method as long as the header value starts with "basic ".

We can craft a malicious input:

    urllib.request.AbstractBasicAuthHandler.rx.search(
        "basic " + ("," * 100) + "A"
    )

Which causes catastrophic backtracking and takes a large amount of CPU time to process.

I tested the length of time (seconds) to complete for different numbers of commas in the string:

18   0.289
19   0.57
20   1.14
21   2.29
22   4.55
23   9.17
24  18.3
25  36.5
26  75.1
27 167

Showing an exponential relationship O(2^x) !

The maximum length of comma string that can fit in a response header is 65509, which would take my computer just 6E+19706 years to complete.

Example malicious server:

    from http.server import BaseHTTPRequestHandler, HTTPServer

    def make_basic_auth(n_commas):
        commas = "," * n_commas
        return f"basic {commas}A"

    class Handler(BaseHTTPRequestHandler):
        def do_GET(self):
            self.send_response(401)
            n_commas = (
                int(self.path[1:])
                if len(self.path) > 1 else
                65509
            )
            value = make_basic_auth(n_commas)
            self.send_header("www-authenticate", value)
            self.end_headers()

    if __name__ == "__main__":
        HTTPServer(("", 44020), Handler).serve_forever()

Vulnerable client:

    import urllib.request
    opener = urllib.request.build_opener(urllib.request.HTTPBasicAuthHandler())
    opener.open("http://localhost:44020/")

As such, python applications using urllib.request may need to be careful not to visit malicious servers.

I think the regex can be replaced with:
    rx = re.compile('basic[ \t]+realm=(["\']?)([^"\']*)\\2', re.I)

- Ben

----------
components: Library (Lib)
messages: 356785
nosy: bc
priority: normal
severity: normal
status: open
title: Regular Expression Denial of Service in urllib.request.AbstractBasicAuthHandler
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38826>
_______________________________________

From report at bugs.python.org  Sat Nov 16 21:09:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Nov 2019 02:09:54 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1573956594.51.0.793989668113.issue3530@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I re-verified the problem, its presence in the doc, and the fix with 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sat Nov 16 21:10:56 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Nov 2019 02:10:56 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1573956656.78.0.93081476479.issue3530@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sat Nov 16 21:27:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Nov 2019 02:27:41 +0000
Subject: [issue38826] Regular Expression Denial of Service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1573955142.95.0.285133152076.issue38826@roundup.psfhosted.org>
Message-ID: <1573957661.73.0.352466902678.issue38826@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Please report security issues to security at python.org so that the security team can analyze and triage it to be made public. More information at https://www.python.org/news/security/

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38826>
_______________________________________

From report at bugs.python.org  Sat Nov 16 21:30:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Nov 2019 02:30:20 +0000
Subject: [issue38825] shutil.disk_usage - Lacking documentation
In-Reply-To: <1573942798.11.0.196925055555.issue38825@roundup.psfhosted.org>
Message-ID: <1573957820.74.0.945829857012.issue38825@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I modified psutil to shutil since I feel it's a typo. Please revert back if it's incorrect.

----------
nosy: +giampaolo.rodola, tarek, xtreak
title: psutil.disk_usage - Lacking documentation -> shutil.disk_usage - Lacking documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38825>
_______________________________________

From report at bugs.python.org  Sun Nov 17 00:59:59 2019
From: report at bugs.python.org (Arslan Mahmood)
Date: Sun, 17 Nov 2019 05:59:59 +0000
Subject: [issue38827] [security] requests (lib) connects to a wrong host
Message-ID: <1573970399.04.0.637340235366.issue38827@roundup.psfhosted.org>


Change by Arslan Mahmood <h47k6m4n at gmail.com>:


----------
components: Library (Lib)
nosy: Arslan Mahmood
priority: normal
severity: normal
status: open
title: [security] requests (lib) connects to a wrong host
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38827>
_______________________________________

From report at bugs.python.org  Sun Nov 17 01:06:31 2019
From: report at bugs.python.org (Arslan Mahmood)
Date: Sun, 17 Nov 2019 06:06:31 +0000
Subject: [issue38824] sasddsdsd
In-Reply-To: <1573937880.31.0.69640606855.issue38824@roundup.psfhosted.org>
Message-ID: <CANvbwURKwGLcT0XFeW12=LkMASJSH3rXwJSSGzOyh25AT5YRmQ@mail.gmail.com>


Arslan Mahmood <h47k6m4n at gmail.com> added the comment:

Hi Christian Heimes!
I have found a bug in requests lib.
I want to report it with POC but don't find message feature on
https://bugs.python.org

On Sun, 17 Nov 2019 at 01:58, Christian Heimes <report at bugs.python.org>
wrote:

>
> New submission from Christian Heimes <lists at cheimes.de>:
>
> Empty / invalid bug report
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38824>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38824>
_______________________________________

From report at bugs.python.org  Sun Nov 17 01:15:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Nov 2019 06:15:55 +0000
Subject: [issue38827] [security] requests (lib) connects to a wrong host
Message-ID: <1573971355.14.0.606462604005.issue38827@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

Please stop creating multiple issues with no description. The previous issue also had no description : https://bugs.python.org/issue38824 . requests module has it's own security process : https://requests.kennethreitz.org/en/master/community/vulnerabilities/

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38827>
_______________________________________

From report at bugs.python.org  Sun Nov 17 01:18:05 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Nov 2019 06:18:05 +0000
Subject: [issue38812] Comparing datetime.time objects incorrect for TZ aware
 and unaware
In-Reply-To: <1573824611.55.0.420390589696.issue38812@roundup.psfhosted.org>
Message-ID: <1573971485.85.0.977370503596.issue38812@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38812>
_______________________________________

From report at bugs.python.org  Sun Nov 17 01:26:09 2019
From: report at bugs.python.org (Arslan Mahmood)
Date: Sun, 17 Nov 2019 06:26:09 +0000
Subject: [issue38827] [security] requests (lib) connects to a wrong host
In-Reply-To: <1573971355.14.0.606462604005.issue38827@roundup.psfhosted.org>
Message-ID: <CANvbwUQkUODkm_m8mQg3B8XucjKPk7VDanC4s5wsqOOqMCPUKg@mail.gmail.com>


Arslan Mahmood <h47k6m4n at gmail.com> added the comment:

I'm new that's why multiple issues get created by mistake.

On Sun, 17 Nov 2019 at 11:16, Karthikeyan Singaravelan <
report at bugs.python.org> wrote:

>
> New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:
>
> Please stop creating multiple issues with no description. The previous
> issue also had no description : https://bugs.python.org/issue38824 .
> requests module has it's own security process :
> https://requests.kennethreitz.org/en/master/community/vulnerabilities/
>
> ----------
> nosy: +xtreak
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38827>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38827>
_______________________________________

From report at bugs.python.org  Sun Nov 17 01:33:29 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 17 Nov 2019 06:33:29 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1573972409.97.0.124050280442.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

So, I just had an interesting idea... what if ThreadPool.run() returned a Task instead of a coroutine object?

With the current version of asyncio.ThreadPool, if a user wants to create a Task, they would have to do something like this:

async with asyncio.ThreadPool() as pool:
    task = asyncio.create_task(pool.run(io_blocking_func, 10, kwarg1='test'))
    other_task = asyncio.create_task(pool.run(io_blocking_func, 12))
    if some_conditional:
        task.cancel()
    results = await asyncio.gather(task, other_task, return_exceptions=True)
    ...

To me, this looks like excessive boilerplate, particularly for a higher level API. Even for rather straightforward behavior, it requires nested function calls. If we were to return a task directly, this would be significantly cleaner:

async with asyncio.ThreadPool() as pool:
    task = pool.run(io_blocking_func, 10, kwarg1='test')
    other_task = pool.run(io_blocking_func, 12)
    if some_conditional:
        task.cancel()
    results = await asyncio.gather(task, other_task, return_exceptions=True)
    ...

Since asyncio.ThreadPool is intended to be a high-level API, I don't think it's an issue to return a Task from it's run() method. It would make it significantly easier and more convenient to work with from a user perspective.

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Sun Nov 17 01:56:23 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 17 Nov 2019 06:56:23 +0000
Subject: [issue33046] IDLE option to strip trailing whitespace automatically
 on save
In-Reply-To: <1520745248.32.0.467229070634.issue33046@psf.upfronthosting.co.za>
Message-ID: <1573973783.19.0.871356558773.issue33046@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33046>
_______________________________________

From report at bugs.python.org  Sun Nov 17 02:11:52 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 17 Nov 2019 07:11:52 +0000
Subject: [issue33046] IDLE option to strip trailing whitespace automatically
 on save
In-Reply-To: <1520745248.32.0.467229070634.issue33046@psf.upfronthosting.co.za>
Message-ID: <1573974712.34.0.0891031446432.issue33046@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created a pull request to implement this feature.  There was also some relevant discussion in bpo-23667.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33046>
_______________________________________

From report at bugs.python.org  Sun Nov 17 02:59:02 2019
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 17 Nov 2019 07:59:02 +0000
Subject: [issue38827] [security] requests (lib) connects to a wrong host
In-Reply-To: <1573971355.14.0.606462604005.issue38827@roundup.psfhosted.org>
Message-ID: <1573977542.24.0.056325013046.issue38827@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As mentioned, requests is a third-party project, please report bugs in requests following the instructions in the link provided by Karthikeyan.

----------
nosy: +zach.ware
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38827>
_______________________________________

From report at bugs.python.org  Sun Nov 17 03:43:06 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Nov 2019 08:43:06 +0000
Subject: [issue38616] Using Py_XDECREF to replace Py_DECREF in
 PyAST_FromNodeObject()
In-Reply-To: <1572273667.46.0.78113656156.issue38616@roundup.psfhosted.org>
Message-ID: <1573980186.14.0.133906347131.issue38616@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +16706
pull_request: https://github.com/python/cpython/pull/17202

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38616>
_______________________________________

From report at bugs.python.org  Sun Nov 17 03:43:35 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Nov 2019 08:43:35 +0000
Subject: [issue38616] Using Py_XDECREF to replace Py_DECREF in
 PyAST_FromNodeObject()
In-Reply-To: <1572273667.46.0.78113656156.issue38616@roundup.psfhosted.org>
Message-ID: <1573980215.09.0.162460939362.issue38616@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -16706

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38616>
_______________________________________

From report at bugs.python.org  Sun Nov 17 03:44:03 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Nov 2019 08:44:03 +0000
Subject: [issue38616] Using Py_XDECREF to replace Py_DECREF in
 PyAST_FromNodeObject()
In-Reply-To: <1572273667.46.0.78113656156.issue38616@roundup.psfhosted.org>
Message-ID: <1573980243.37.0.08626241185.issue38616@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +16708
pull_request: https://github.com/python/cpython/pull/17202

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38616>
_______________________________________

From report at bugs.python.org  Sun Nov 17 03:44:03 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Nov 2019 08:44:03 +0000
Subject: [issue38615] imaplib has no timeout setting
In-Reply-To: <1572271081.51.0.380114547236.issue38615@roundup.psfhosted.org>
Message-ID: <1573980243.1.0.142532793084.issue38615@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38615>
_______________________________________

From report at bugs.python.org  Sun Nov 17 03:45:49 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Nov 2019 08:45:49 +0000
Subject: [issue38616] Using Py_XDECREF to replace Py_DECREF in
 PyAST_FromNodeObject()
In-Reply-To: <1572273667.46.0.78113656156.issue38616@roundup.psfhosted.org>
Message-ID: <1573980349.09.0.509485026144.issue38616@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -16708

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38616>
_______________________________________

From report at bugs.python.org  Sun Nov 17 03:47:04 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Nov 2019 08:47:04 +0000
Subject: [issue38615] imaplib has no timeout setting
In-Reply-To: <1572271081.51.0.380114547236.issue38615@roundup.psfhosted.org>
Message-ID: <1573980424.26.0.178429045636.issue38615@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +16709
pull_request: https://github.com/python/cpython/pull/17203

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38615>
_______________________________________

From report at bugs.python.org  Sun Nov 17 03:47:25 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Nov 2019 08:47:25 +0000
Subject: [issue38615] imaplib has no timeout setting
In-Reply-To: <1572271081.51.0.380114547236.issue38615@roundup.psfhosted.org>
Message-ID: <1573980445.33.0.951896718556.issue38615@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -16707

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38615>
_______________________________________

From report at bugs.python.org  Sun Nov 17 04:00:36 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Nov 2019 09:00:36 +0000
Subject: [issue38615] imaplib has no timeout setting
In-Reply-To: <1572271081.51.0.380114547236.issue38615@roundup.psfhosted.org>
Message-ID: <1573981236.63.0.426996074285.issue38615@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@eric.smith

I 've submitted the patch, Can I get a review from you if you don't mind?
Thank you :)

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38615>
_______________________________________

From report at bugs.python.org  Sun Nov 17 05:04:58 2019
From: report at bugs.python.org (Lord Anton Hvornum)
Date: Sun, 17 Nov 2019 10:04:58 +0000
Subject: [issue38825] shutil.disk_usage - Lacking documentation
In-Reply-To: <1573942798.11.0.196925055555.issue38825@roundup.psfhosted.org>
Message-ID: <1573985098.09.0.697746168234.issue38825@roundup.psfhosted.org>


Lord Anton Hvornum <anton.doxid at gmail.com> added the comment:

xtreak: You are correct, that was a typo. My apologies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38825>
_______________________________________

From report at bugs.python.org  Sun Nov 17 05:34:51 2019
From: report at bugs.python.org (Kovid Goyal)
Date: Sun, 17 Nov 2019 10:34:51 +0000
Subject: [issue38828] cookiejar.py broken in 3.8
Message-ID: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>


New submission from Kovid Goyal <kovid at kovidgoyal.net>:

In python 3.8 cookiejar.py is full of code that compares cookie.version to integers, which raises as exception when cookie.version is None. For example, in set_ok_version() and set_ok_path(). Both the Cookie constructor and _cookie_from_cookie_tuple() explicitly assume version can be None and setting version to None worked fine in previous pythonreleases.

----------
components: Library (Lib)
messages: 356797
nosy: kovid
priority: normal
severity: normal
status: open
title: cookiejar.py broken in 3.8
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38828>
_______________________________________

From report at bugs.python.org  Sun Nov 17 05:53:27 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Nov 2019 10:53:27 +0000
Subject: [issue38828] cookiejar.py broken in 3.8
In-Reply-To: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>
Message-ID: <1573988007.62.0.48655760882.issue38828@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please add a sample script to reproduce this that worked fine before Python 3.8?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38828>
_______________________________________

From report at bugs.python.org  Sun Nov 17 06:06:32 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 17 Nov 2019 11:06:32 +0000
Subject: [issue38276] test_asyncio:
 test_cancel_make_subprocess_transport_exec() failed on RHEL7 LTO + PGO 3.x
In-Reply-To: <1569416953.01.0.173802643321.issue38276@roundup.psfhosted.org>
Message-ID: <1573988792.93.0.249579355404.issue38276@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38276>
_______________________________________

From report at bugs.python.org  Sun Nov 17 06:11:47 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=)
Date: Sun, 17 Nov 2019 11:11:47 +0000
Subject: [issue38814] Python3.7.5 crashes on OSX with my django project
In-Reply-To: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>
Message-ID: <1573989107.74.0.037814215288.issue38814@roundup.psfhosted.org>


L?szl? K?rolyi <laszlo at karolyi.hu> added the comment:

Hey,

the problem normalized after installing the newest version of cryptography, with which I could reproduce the same problem too.

It turned out that asn1crypto wasn't even needed in my project.

Sorry for the inconvenience, and thank you for your help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38814>
_______________________________________

From report at bugs.python.org  Sun Nov 17 06:18:26 2019
From: report at bugs.python.org (Ben Caller)
Date: Sun, 17 Nov 2019 11:18:26 +0000
Subject: [issue38826] Regular Expression Denial of Service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1573955142.95.0.285133152076.issue38826@roundup.psfhosted.org>
Message-ID: <1573989506.07.0.131728091837.issue38826@roundup.psfhosted.org>


Ben Caller <bcaller at gmail.com> added the comment:

I have been advised that DoS issues can be added to the public bug tracker  since there is no privilege escalation, but should still have the security label.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38826>
_______________________________________

From report at bugs.python.org  Sun Nov 17 06:41:47 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 17 Nov 2019 11:41:47 +0000
Subject: [issue17642] IDLE add font resizing hot keys and wheel
In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za>
Message-ID: <1573990907.69.0.962882204279.issue17642@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17642>
_______________________________________

From report at bugs.python.org  Sun Nov 17 06:52:05 2019
From: report at bugs.python.org (Jean-Didier)
Date: Sun, 17 Nov 2019 11:52:05 +0000
Subject: [issue38829] Make the function flush_io accessible in the C-API
Message-ID: <1573991525.07.0.835950836621.issue38829@roundup.psfhosted.org>


New submission from Jean-Didier <jeandidier.garaud at gmail.com>:

Hello, 
when using an embedded python interpreter in a C++ program, which itself uses MPI, the embedded script's error messages are not flushed properly. 
(see the whole discussion in this StackOverflow : https://stackoverflow.com/questions/29352485/python-print-not-working-when-embedded-into-mpi-program/49076389#49076389).

The current preferred solution involves adding a few calls to flush_io in the C++. 
However, flush_io is a `static` function in `pythonrun.c`, and is not visible in the C-API.

Would it be possible to remove its static attribute, and add a reference to it in pythonrun.h?
Or maybe there is another method to flush IO from the C-API?

----------
components: IO
messages: 356801
nosy: Jean-Didier
priority: normal
severity: normal
status: open
title: Make the function flush_io accessible in the C-API
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38829>
_______________________________________

From report at bugs.python.org  Sun Nov 17 07:10:04 2019
From: report at bugs.python.org (Kovid Goyal)
Date: Sun, 17 Nov 2019 12:10:04 +0000
Subject: [issue38828] cookiejar.py broken in 3.8
In-Reply-To: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>
Message-ID: <1573992604.84.0.0412961939622.issue38828@roundup.psfhosted.org>


Kovid Goyal <kovid at kovidgoyal.net> added the comment:

The issue is obvious with a simple glance at the code. Either the Cookie constructor needs to change version = None to zero or some other integer or the various methods in that module need to handle a None version. I dont personally care about this issue any more since I have worked around it in my code, feel free to fix it or not, as you wish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38828>
_______________________________________

From report at bugs.python.org  Sun Nov 17 07:14:14 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Nov 2019 12:14:14 +0000
Subject: [issue38828] cookiejar.py broken in 3.8
In-Reply-To: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>
Message-ID: <1573992854.85.0.330056022304.issue38828@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
keywords: +3.8regression
stage:  -> test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38828>
_______________________________________

From report at bugs.python.org  Sun Nov 17 07:20:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Nov 2019 12:20:40 +0000
Subject: [issue38829] Make the function flush_io accessible in the C-API
In-Reply-To: <1573991525.07.0.835950836621.issue38829@roundup.psfhosted.org>
Message-ID: <1573993240.06.0.860052297871.issue38829@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PyObject_CallMethod(file, "flush", NULL)

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38829>
_______________________________________

From report at bugs.python.org  Sun Nov 17 08:02:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Nov 2019 13:02:19 +0000
Subject: [issue38828] http.cookiejar handle cookie.version to be None
In-Reply-To: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>
Message-ID: <1573995739.2.0.325140377319.issue38828@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

You specifically mentioned Python 3.8 and I just wanted to understand the issue to see if it's a regression. I don't see any version related code changes in recent times. Hence this is not necessarily a regression in 3.8 unless there is a reproducible script. The code in set_ok_version for cookie.version to be None is not tested hence I assume there are no tests for the reported scenario that would be good to have. I have also changed the issue title accordingly.

----------
title: cookiejar.py broken in 3.8 -> http.cookiejar handle cookie.version to be None

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38828>
_______________________________________

From report at bugs.python.org  Sun Nov 17 08:18:14 2019
From: report at bugs.python.org (Kovid Goyal)
Date: Sun, 17 Nov 2019 13:18:14 +0000
Subject: [issue38828] http.cookiejar handle cookie.version to be None
In-Reply-To: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>
Message-ID: <1573996694.66.0.816506172469.issue38828@roundup.psfhosted.org>


Kovid Goyal <kovid at kovidgoyal.net> added the comment:

It's trivially True that it is a regression from python 2 since in python 2 comparison to None is fine. Whether it ever worked in any python 3 version before 3.8 I'm not sure about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38828>
_______________________________________

From report at bugs.python.org  Sun Nov 17 08:21:17 2019
From: report at bugs.python.org (Mike)
Date: Sun, 17 Nov 2019 13:21:17 +0000
Subject: [issue38812] Comparing datetime.time objects incorrect for TZ aware
 and unaware
In-Reply-To: <1573971485.9.0.513516737769.issue38812@roundup.psfhosted.org>
Message-ID: <CAEVHbAmbwH1AJvuQFV_A5=HbbZ=KW7wgcvDYMNwP4yY33txXFA@mail.gmail.com>


Mike <mikesutton at gmail.com> added the comment:

Ok. I'll file a bug on pytz. Thanks!

On Sat, Nov 16, 2019 at 11:18 PM Karthikeyan Singaravelan <
report at bugs.python.org> wrote:

>
> Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:
>
>
> ----------
> nosy: +p-ganssle
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38812>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38812>
_______________________________________

From report at bugs.python.org  Sun Nov 17 08:21:51 2019
From: report at bugs.python.org (Kovid Goyal)
Date: Sun, 17 Nov 2019 13:21:51 +0000
Subject: [issue38828] http.cookiejar handle cookie.version to be None
In-Reply-To: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>
Message-ID: <1573996911.88.0.96116206366.issue38828@roundup.psfhosted.org>


Kovid Goyal <kovid at kovidgoyal.net> added the comment:

Here's a trivial script to reproduce:

from urllib.request import Request
from http.cookiejar import Cookie, CookieJar

jar = CookieJar()
jar.set_cookie(Cookie(
            None, 'test', 'test',
            None, False,
            '.test.com', True, False,
            '/', True,
            False, None, False, None, None, None
        ))
r = Request('http://www.test.com')
jar.add_cookie_header(r)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38828>
_______________________________________

From report at bugs.python.org  Sun Nov 17 08:34:43 2019
From: report at bugs.python.org (Samuel Mathias)
Date: Sun, 17 Nov 2019 13:34:43 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
Message-ID: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>


New submission from Samuel Mathias <samuel.mathias at gmail.com>:

On the "logging cookbook" page:

https://docs.python.org/3/howto/logging-cookbook.html#logging-cookbook

The recipe "A Qt GUI for logging" produces the following error:

`TypeError: update_status() missing 1 required positional argument: 'record'`

----------
assignee: docs at python
components: Documentation
messages: 356808
nosy: Samuel Mathias, docs at python
priority: normal
severity: normal
status: open
title: `A Qt GUI for logging` produces TypeError
type: crash
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Sun Nov 17 08:44:08 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 17 Nov 2019 13:44:08 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1573998248.96.0.694874452533.issue38823@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Is anything left to be done for the issue?

----------
nosy: +asvetlov
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sun Nov 17 09:09:04 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 17 Nov 2019 14:09:04 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573999744.94.0.0283865791909.issue38724@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 645005e947c13c4a0706310a2a46112bf63cadc0 by Tal Einat (Andrey Doroschenko) in branch 'master':
bpo-38724: Implement subprocess.Popen.__repr__ (GH-17151)
https://github.com/python/cpython/commit/645005e947c13c4a0706310a2a46112bf63cadc0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Sun Nov 17 09:09:40 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 17 Nov 2019 14:09:40 +0000
Subject: [issue38724] Implement subprocess.Popen.__repr__
In-Reply-To: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>
Message-ID: <1573999780.25.0.0549981789479.issue38724@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for the suggestion Ram, and thanks for PR Andrey!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38724>
_______________________________________

From report at bugs.python.org  Sun Nov 17 09:13:35 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 17 Nov 2019 14:13:35 +0000
Subject: [issue38824] sasddsdsd
In-Reply-To: <1573937880.31.0.69640606855.issue38824@roundup.psfhosted.org>
Message-ID: <1574000015.36.0.107583769184.issue38824@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The requests library is not part of Python core. Please report any bugs with requests at https://github.com/psf/requests/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38824>
_______________________________________

From report at bugs.python.org  Sun Nov 17 09:38:15 2019
From: report at bugs.python.org (rosoroso)
Date: Sun, 17 Nov 2019 14:38:15 +0000
Subject: [issue38831] urllib.request header characters being changed to
 lowercase
Message-ID: <1574001495.49.0.848749127731.issue38831@roundup.psfhosted.org>


New submission from rosoroso <robert.calvert at ibm.com>:

When using the urllib request headers, I've found that certain letters are converted to their lowercase versions whilst part of a request object (H->h in the example, see at bottom).
Whilst this should not usually be an issue (Since headers are not supposed to be case sensitive), I've found an API for which that is not the case.

Options for fixing this could include, not changing the case of characters in header fields or updating the docs to include a warning of this behaviour (https://docs.python.org/3/library/urllib.request.html)

import urllib.request
header = {"Test-Header":"Value"}
requestobject = urllib.request.Request("https://www.example.com",None,header)
print ("Original header is:", header)
print ("Request header is:", requestobject.header_items())

'''
Orginal header is: {'Test-Header': 'Value'}
Request header is: [('Test-header', 'Value')]
Version was Python 3.6.5
'''

----------
messages: 356813
nosy: rosoroso
priority: normal
severity: normal
status: open
title: urllib.request header characters being changed to lowercase
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38831>
_______________________________________

From report at bugs.python.org  Sun Nov 17 10:07:41 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 17 Nov 2019 15:07:41 +0000
Subject: [issue38812] Comparing datetime.time objects incorrect for TZ aware
 and unaware
In-Reply-To: <1573824611.55.0.420390589696.issue38812@roundup.psfhosted.org>
Message-ID: <1574003261.99.0.372230146284.issue38812@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I do not think this is a bug in pytz, but if it's a bug in Python it's one in reporting what the error is.

The issue is that the time zone offset for "rules-based zones" like America/Denver (i.e. most time zones) is *undefined* for bare times, because the offset that apply depends on the *date* and the *time*.

The documentation for `tzinfo.utcoffset` specifies that if the offset is unknown, a time zone offset should return None: https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset

The documentation for determining whether an object is aware or naive also specifies that if utcoffset() returns `None`, the object is naive (even if tzinfo is not None): https://docs.python.org/3/library/datetime.html#determining-if-an-object-is-aware-or-naive

So basically, everyone is doing the right thing except the person who attached this `pytz` time zone to a time object (as a side note, it may be worth reading this blog post that explains why the way this time zone is attached to the `time` object is incorrect: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html).

That said, we may be able to improve the error message raised here by distinguishing between the case where there's no `tzinfo` at all and the case where `utcoffset()` returns `None`. I think we can change the exception message to have a helpful hint like, "cannot compare offset-naive and offset-aware times; one of the operands is offset-naive because its offset is undefined."

We could possibly be even more specific.

----------
components: +Library (Lib)
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38812>
_______________________________________

From report at bugs.python.org  Sun Nov 17 10:22:37 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 17 Nov 2019 15:22:37 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574004157.41.0.201557996815.issue22367@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could PR17010 be reverted?

For 10 days now several bots, AIX and  x86-64 High Sierra - afaik, are failing the tests.

re: https://bugs.python.org/issue22367#msg356614 - while that may address High Sierra, it does not address AIX.

See message https://bugs.python.org/issue35633#msg333662 - wherein Victor states his preference to ignore the test (for AIX).

A additional change to your next PR could be to also ignore AIX for this test. AIX returns a different error, "Permission Error", iirc.

----------
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Sun Nov 17 10:22:49 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Nov 2019 15:22:49 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
In-Reply-To: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>
Message-ID: <1574004169.08.0.657115893603.issue38830@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Sun Nov 17 10:24:27 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 17 Nov 2019 15:24:27 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574004267.48.0.877914191941.issue22367@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

ignore my last comment - I missed your comment about skipping the test. My apologies.

I'll be patient.

Thanks for the update!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Sun Nov 17 11:00:26 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 17 Nov 2019 16:00:26 +0000
Subject: [issue37367] octal escapes applied inconsistently throughout the
 interpreter and lib
In-Reply-To: <1561146368.97.0.686299796922.issue37367@roundup.psfhosted.org>
Message-ID: <1574006426.19.0.12714811386.issue37367@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

The PR looks pretty good, but the question is whether we want to break backwards compatibility in the name of correctness.

In this case, the silent buggy behavior of keeping the (mod 256) of the value seems worth fixing to me.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37367>
_______________________________________

From report at bugs.python.org  Sun Nov 17 12:06:54 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Nov 2019 17:06:54 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1574010414.24.0.518571183507.issue38811@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 111772fc27cfe388bc060f019d68a3e33481ec65 by Serhiy Storchaka (Toke H?iland-J?rgensen) in branch 'master':
bpo-38811: Check for presence of os.link method in pathlib. (GH-17170)
https://github.com/python/cpython/commit/111772fc27cfe388bc060f019d68a3e33481ec65


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Sun Nov 17 12:07:14 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 17 Nov 2019 17:07:14 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1574010434.67.0.5391406224.issue38811@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16710
pull_request: https://github.com/python/cpython/pull/17204

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Sun Nov 17 12:10:16 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Nov 2019 17:10:16 +0000
Subject: [issue36589] Incorrect error handling in curses.update_lines_cols()
In-Reply-To: <1554923035.79.0.592038232821.issue36589@roundup.psfhosted.org>
Message-ID: <1574010616.9.0.439520129535.issue36589@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2bc343417a4de83fa6998ff91303877734ecd366 by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-36589: Fix the error handling in curses.update_lines_cols(). (GH-12766)
https://github.com/python/cpython/commit/2bc343417a4de83fa6998ff91303877734ecd366


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36589>
_______________________________________

From report at bugs.python.org  Sun Nov 17 12:19:34 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Sun, 17 Nov 2019 17:19:34 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574011174.53.0.247613450944.issue38823@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Yes, there are still a few dozen modules I plan to update!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sun Nov 17 12:28:33 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 17 Nov 2019 17:28:33 +0000
Subject: [issue38832] setup.py can report builtin modules as missing modules
Message-ID: <1574011713.16.0.567314798681.issue38832@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

setup.py can report statically linked modules as missing when detect_modules() have flagged the modules as missing.

In my case I have modified Modules/Setup.local to statically link _ssl and _hashlib:

$ cat Modules/Setup.local 
SSL=/tmp/openssl
_socket socketmodule.c
_ssl _ssl.c -I$(SSL)/include $(SSL)/lib/libcrypto.a $(SSL)/lib/libssl.a
_hashlib _hashopenssl.c -I$(SSL)/include $(SSL)/lib/libcrypto.a

make successfully compiles _socket, _ssl, and _hashlib into the main interpreter binary. setup.py does not list _ssl and _hashlib as builtin but as missing modules because detect_modules() detects dependencies as missing.

The problem can be reproduced on an old Ubuntu or RHEL system with OpenSSL 1.0.1 and a custom OpenSSL installation.

----------
components: Build
messages: 356821
nosy: christian.heimes, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: setup.py can report builtin modules as missing modules
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38832>
_______________________________________

From report at bugs.python.org  Sun Nov 17 12:42:34 2019
From: report at bugs.python.org (Charles Anderson)
Date: Sun, 17 Nov 2019 17:42:34 +0000
Subject: [issue38833] Issue with multiprocessing.Pool & multiprocessing.Queue
Message-ID: <1574012554.58.0.644556587117.issue38833@roundup.psfhosted.org>


New submission from Charles Anderson <mmrocksmm12 at gmail.com>:

When calling mp.Pool().apply_async(), and passing a mp.Queue() instance as an argument the execution halts.

This is contrasted by using mp.Manager().Queue() which when passed to apply_async() works as expected.

----------
components: Library (Lib)
files: python_mp_pool_queue_issue.py
messages: 356822
nosy: bigbizze
priority: normal
severity: normal
status: open
title: Issue with multiprocessing.Pool & multiprocessing.Queue
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48719/python_mp_pool_queue_issue.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38833>
_______________________________________

From report at bugs.python.org  Sun Nov 17 13:04:25 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Nov 2019 18:04:25 +0000
Subject: [issue38831] urllib.request header characters being changed to
 lowercase
In-Reply-To: <1574001495.49.0.848749127731.issue38831@roundup.psfhosted.org>
Message-ID: <1574013865.58.0.94266154858.issue38831@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Well, the standard says they're case insensitive: https://tools.ietf.org/html/rfc7230#section-3.2

Forcing the case on the header item seems quite deliberate: https://github.com/python/cpython/blob/master/Lib/urllib/request.py#L399
I assume that the .capitalize call is made in order to normalize headers, in case another header with the same name but different capitalization is added.

I can't recommend making a code change here. We're compliant with the standard, and any change would no doubt break someone's code.

I do agree that it might be worth documenting.

It's unfortunate that the caller can't specify an exact string they want to use (in order to handle broken servers), but that's the way it's been for ages.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38831>
_______________________________________

From report at bugs.python.org  Sun Nov 17 13:32:20 2019
From: report at bugs.python.org (=?utf-8?b?0K7RgNC40Lkg0JvQtdC+0L3QvtCy?=)
Date: Sun, 17 Nov 2019 18:32:20 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1574015540.6.0.697944955557.issue38597@roundup.psfhosted.org>


???? ?????? <tavoseg at gmail.com> added the comment:

Looks like I have same problem for Windows 10 (version 1809, build - 17763.864).

I created repository with steps for reproducing - https://github.com/Yuriy-Leonov/cython_imports_limit_issue

----------
components:  -Interpreter Core, Windows
nosy: +???? ??????
versions: +Python 3.6 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Sun Nov 17 13:37:57 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 17 Nov 2019 18:37:57 +0000
Subject: [issue38116] Make select module PEP-384 compatible
In-Reply-To: <1568213295.38.0.552886185542.issue38116@roundup.psfhosted.org>
Message-ID: <1574015877.47.0.378781823241.issue38116@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

PR 15971 is merged, what else is needed @dino.viehland?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38116>
_______________________________________

From report at bugs.python.org  Sun Nov 17 13:53:56 2019
From: report at bugs.python.org (Tim Peters)
Date: Sun, 17 Nov 2019 18:53:56 +0000
Subject: [issue38767] Replace Mersenne Twister RNG with a PCG family algorithm
In-Reply-To: <1573492126.38.0.315773504148.issue38767@roundup.psfhosted.org>
Message-ID: <1574016836.79.0.60265407272.issue38767@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Thanks for the NumPy discussion link, Mark!  Did that set a world record for an issue report's length? ;-)  Not complaining - it's a very high quality and informative discussion.

I'd be comfortable adopting whichever PRNGs numpy uses.  numpy has better brainpower to apply to "due diligence" in this area, and the discussion made clear too that they're acutely aware of that most users know next to nothing about the pathologies, so that the defaults have to be ignorance-resistant.

It's cute that you raised good questions about how "independent" PCG streams are, and that PCG's creator invented a new member of the family to address the pathologies your line of questioning uncovered.  No "proof" that the new member is robust, but lots of testing.  That appears to be as good as the state of art allows for now.

I had/have similar concerns about the Twister, but never pursued them.  Much like PCG, in fact, it mixes a simple generator with a more-elaborate permutation of the underlying generator's output sequence (which they call "tempering").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38767>
_______________________________________

From report at bugs.python.org  Sun Nov 17 13:58:49 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 17 Nov 2019 18:58:49 +0000
Subject: [issue35143] `from __future__ import annotations` has no effect
 inside `ast.parse`
In-Reply-To: <1541147333.05.0.788709270274.issue35143@psf.upfronthosting.co.za>
Message-ID: <1574017129.38.0.173253073061.issue35143@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Hey @lukasz.langa, I want to work on this. Should we add an interface to _PyAST_ExprAsUnicode or just the bugfix for annotations?

----------
nosy: +BTaskaya, benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35143>
_______________________________________

From report at bugs.python.org  Sun Nov 17 14:21:10 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Sun, 17 Nov 2019 19:21:10 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574018470.34.0.280791170092.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16711
pull_request: https://github.com/python/cpython/pull/17206

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Sun Nov 17 15:03:56 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 17 Nov 2019 20:03:56 +0000
Subject: [issue23667] IDLE to provide option for making trailing whitespace
 visible
In-Reply-To: <1426376584.28.0.267295855034.issue23667@psf.upfronthosting.co.za>
Message-ID: <1574021036.7.0.84112179062.issue23667@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

See also issue33046 specifically suggesting auto-removal of trailing whitespace on saving a file, as per Raymond's second suggestion here. It has a PR which seems about ready to go.

I see that as the simplest approach to this issue, both in terms of implementation and in terms of UI/UX.

Could we mark that issue as superseding this one?

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23667>
_______________________________________

From report at bugs.python.org  Sun Nov 17 15:28:55 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 17 Nov 2019 20:28:55 +0000
Subject: [issue37948] get_type_hints fails if there are un-annotated fields in
 a dataclass
In-Reply-To: <1566800952.19.0.982220665774.issue37948@roundup.psfhosted.org>
Message-ID: <1574022535.51.0.849914227032.issue37948@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> I'm not sure what can be done with this. The problem is that the decorator doesn't know what's in the caller's namespace. The type being added is "typing.Any". If the caller doesn't import typing, then get_type_hints will fail (as demonstrated here).

IIUC the main problem is that get_type_hints() fails even if typing is imported. I would expect this to work (just repeating the original example in a more compact form):

import dataclasses
import typing
A = dataclasses.make_dataclass('A', ['a_var'])
typing.get_type_hints(A)  # This currently crashes

Interestingly, if I use a very similar call that it works:

>>> typing.get_type_hints(A, globalns=globals())
{'a_var': typing.Any}

So the core of the issue is that the globals are identified incorrectly, and indeed if I look at the generated class it looks wrong:

>>> A.__module__
'types'  # Should be '__main__'

I think we should fix the ``__module__`` attribute of the dynamically generated dataclasses (for example the way it is done for named tuples).

Btw, https://github.com/python/cpython/pull/14166 may potentially fix the ``__module__`` attribute here too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37948>
_______________________________________

From report at bugs.python.org  Sun Nov 17 16:56:19 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Nov 2019 21:56:19 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574027779.37.0.0809973269306.issue38678@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:00:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Nov 2019 22:00:50 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1574028050.07.0.00426094335222.issue25866@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 4544e78ec4558b75bf95e5b7dfc1b5bbb07ae5f0 by Raymond Hettinger (alclarks) in branch 'master':
bpo-25866: Minor cleanups to "sequence" in docs (GH-17177)
https://github.com/python/cpython/commit/4544e78ec4558b75bf95e5b7dfc1b5bbb07ae5f0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:00:55 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 17 Nov 2019 22:00:55 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1574028055.87.0.60845558559.issue25866@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16713
pull_request: https://github.com/python/cpython/pull/17208

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:01:19 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 17 Nov 2019 22:01:19 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1574028079.06.0.3496872525.issue25866@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16714
pull_request: https://github.com/python/cpython/pull/17209

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:02:14 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Nov 2019 22:02:14 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1574028134.03.0.488345442413.issue25866@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:07:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Nov 2019 22:07:51 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1574028471.75.0.174934526943.issue25866@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 72321c7be096434e3343bd5b37a4436aa9eea098 by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-25866: Minor cleanups to "sequence" in docs (GH-17177) (GH-17209)
https://github.com/python/cpython/commit/72321c7be096434e3343bd5b37a4436aa9eea098


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:09:31 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Nov 2019 22:09:31 +0000
Subject: [issue29979] cgi.parse_multipart is not consistent with FieldStorage
In-Reply-To: <1491296331.11.0.181533719685.issue29979@psf.upfronthosting.co.za>
Message-ID: <1574028571.65.0.0236773764943.issue29979@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29979>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:13:36 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Nov 2019 22:13:36 +0000
Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on
 the word "sequence".
In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za>
Message-ID: <1574028816.87.0.116178130892.issue25866@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 20a4f6cde65549fd0252eb8c879963e0e8b40390 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-25866: Minor cleanups to "sequence" in docs (GH-17177) (GH-17208)
https://github.com/python/cpython/commit/20a4f6cde65549fd0252eb8c879963e0e8b40390


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25866>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:33:13 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Nov 2019 22:33:13 +0000
Subject: [issue38831] urllib.request header characters being changed to
 lowercase
In-Reply-To: <1574001495.49.0.848749127731.issue38831@roundup.psfhosted.org>
Message-ID: <1574029993.9.0.73018314086.issue38831@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I suggest to keep the discussion with Issue 12455

----------
nosy: +martin.panter
superseder:  -> urllib2 forces title() on header names, breaking some requests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38831>
_______________________________________

From report at bugs.python.org  Sun Nov 17 17:54:32 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Nov 2019 22:54:32 +0000
Subject: [issue38831] urllib.request header characters being changed to
 lowercase
In-Reply-To: <1574001495.49.0.848749127731.issue38831@roundup.psfhosted.org>
Message-ID: <1574031272.38.0.846042306824.issue38831@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Yes, this does seem to be a duplicate. I'll close this.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38831>
_______________________________________

From report at bugs.python.org  Sun Nov 17 18:20:53 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Nov 2019 23:20:53 +0000
Subject: [issue38710] unsynchronized write pointer in io.TextIOWrapper in 'r+'
 mode
In-Reply-To: <1573013055.2.0.421780617853.issue38710@roundup.psfhosted.org>
Message-ID: <1574032853.23.0.285354139731.issue38710@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Previously Issue 12215 and a couple of other duplicates were opened about this. Writing after reading with TextIOWrapper doesn't work as people expect. The report was closed apparently because Victor thought there wasn't enough interest in it.

FWIW the seek-then-write workaround will probably work for most common codecs, but would suffer the same problems discussed in Issue 26158 for codecs like UTF-7 and ISO-2022 that would need the encoder state constructed from the decoder state.

----------
nosy: +martin.panter
superseder:  -> TextIOWrapper: issues with interlaced read-write

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38710>
_______________________________________

From report at bugs.python.org  Sun Nov 17 19:53:55 2019
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Mon, 18 Nov 2019 00:53:55 +0000
Subject: [issue38834] TypedDict: no way to tell which (if any) keys are
 optional at runtime
Message-ID: <1574038434.98.0.659515857103.issue38834@roundup.psfhosted.org>


New submission from Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:

Consider the following cases:

```python
class A(typing.TypedDict):
    a: int  # a is required

class B(A, total=False):
    b: bool  # a is required, b is optional

class C(B):
    c: str  # a is required, b is optional, c is required again
```

PEP-589 is clear about the semantics, and this is obvious enough when reading the code.  At runtime the __annotations__ attribute of each class gives us the set of allowed keys and the type of each corresponding value, but we have a problem:

- C has __total__==True, but b is not actually required.
- B has __total__==False, but a *is* required.
- I can't see any way to get the parent classes of a TypedDict class!

The _TypedDictMeta metaclass updates the attributes, but leaves no record of the parent type - at runtime A, B, and C all appear to inherit directly from dict.

After discussion on the typing-sig mailing list, I propose to add __required_keys__ and __optional_keys__ attributes to TypedDict subclasses, as frozensets of strings.

This will be very useful for Hypothesis' `from_type()` strategy, as well as for type-based validation frameworks like pydantic or typeguard.

----------
components: Library (Lib)
messages: 356836
nosy: Zac Hatfield-Dodds, levkivskyi
priority: normal
severity: normal
status: open
title: TypedDict: no way to tell which (if any) keys are optional at runtime
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38834>
_______________________________________

From report at bugs.python.org  Sun Nov 17 21:13:58 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 18 Nov 2019 02:13:58 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574043238.31.0.122555401495.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

This cause of failure PR 17010 was due to change of start methods as follows:
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods
Changed in version 3.8: On macOS, the spawn start method is now the default. The fork start method should be considered unsafe as it can lead to crashes of the subprocess. See bpo-33725.


So I updated the test through PR 17154 and I check that my local mac machine works well. (I did not check it on my local mac machine when I submitted PR 17010 since open description lock was Linux feature, this was my mistake)

And thanks to the tip from Michael Felt, I update the test to skip on the AIX machine. So I expect that when PR 17154 is landed, everything will go well.

?  cpython git:(bpo-22367-test-fix) ? ./python.exe Lib/test/test_fcntl.py -v
struct.pack:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
test_fcntl_64_bit (__main__.TestFcntl) ... skipped 'F_NOTIFY or DN_MULTISHOT unavailable'
test_fcntl_bad_file (__main__.TestFcntl) ... ok
test_fcntl_bad_file_overflow (__main__.TestFcntl) ... ok
test_fcntl_f_getpath (__main__.TestFcntl) ... ok
test_fcntl_file_descriptor (__main__.TestFcntl) ... Status from fcntl with O_NONBLOCK:  0
String from fcntl with F_SETLKW:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
ok
test_fcntl_fileno (__main__.TestFcntl) ... Status from fcntl with O_NONBLOCK:  0
String from fcntl with F_SETLKW:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
ok
test_flock (__main__.TestFcntl) ... ok
test_flock_overflow (__main__.TestFcntl) ... ok
test_lockf_exclusive (__main__.TestFcntl) ... struct.pack:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
ok
test_lockf_share (__main__.TestFcntl) ... struct.pack:  b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00'
ok

----------------------------------------------------------------------

Ran 10 tests in 0.246s

OK (skipped=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Sun Nov 17 21:16:42 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 18 Nov 2019 02:16:42 +0000
Subject: [issue38790] test_fcntl failing on macOS CI
In-Reply-To: <1573684464.1.0.222448542247.issue38790@roundup.psfhosted.org>
Message-ID: <1574043402.92.0.0356065463028.issue38790@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

This cause of failure PR 17010 was due to change of start methods as follows:
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods
Changed in version 3.8: On macOS, the spawn start method is now the default. The fork start method should be considered unsafe as it can lead to crashes of the subprocess. See bpo-33725.


So I updated the test through PR 17154 and I check that my local mac machine works well. (I did not check it on my local mac machine when I submitted PR 17010 since open description lock was Linux feature, this was my mistake)

And thanks to the tip from Michael Felt, I update the test to skip on the AIX machine. So I expect that when PR 17154 is landed, everything will go well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38790>
_______________________________________

From report at bugs.python.org  Sun Nov 17 21:52:20 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Mon, 18 Nov 2019 02:52:20 +0000
Subject: [issue38744] python 3.8 hang in multiprocessing.Pool() locking on
 FreeBSD
In-Reply-To: <1573225244.96.0.151354887911.issue38744@roundup.psfhosted.org>
Message-ID: <1574045540.72.0.756001571401.issue38744@roundup.psfhosted.org>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38744>
_______________________________________

From report at bugs.python.org  Sun Nov 17 22:40:36 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Nov 2019 03:40:36 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574048436.2.0.840485787901.issue38678@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Raymond's patch changes the tutorial example to something more useful for beginners.  It also gives the proper fix for the old example, which is to add 'default=0' after "action='count'", but puts this in the proper place, the ref manual explanation of 'count'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Sun Nov 17 22:44:53 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Nov 2019 03:44:53 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574048693.28.0.803150612031.issue38678@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Sun Nov 17 23:51:36 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Nov 2019 04:51:36 +0000
Subject: [issue23667] IDLE to provide option for making trailing whitespace
 visible
In-Reply-To: <1426376584.28.0.267295855034.issue23667@psf.upfronthosting.co.za>
Message-ID: <1574052696.94.0.649354190315.issue23667@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given the issues I raised and Raymond's rejection of this, his first suggested option, on the PR, in favor of his second suggested option, #33046, I agree, at least for now.

The use case for whitespace tagging would be if someone wants to selectively delete trailing whitespace.  However, python/cpython rejects any trailing whitespace for all of .py, .c, and .rst files.  So this must be exceedingly rare and is not something that IDLE must facilitate.

----------
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed
superseder:  -> IDLE option to strip trailing whitespace automatically on save

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23667>
_______________________________________

From report at bugs.python.org  Mon Nov 18 00:17:47 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Mon, 18 Nov 2019 05:17:47 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
In-Reply-To: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>
Message-ID: <1574054267.64.0.115107176592.issue35727@roundup.psfhosted.org>


Christopher Hunt <chrahunt at gmail.com> added the comment:

Any other concerns here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Mon Nov 18 00:31:54 2019
From: report at bugs.python.org (thautwarm)
Date: Mon, 18 Nov 2019 05:31:54 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1574055114.02.0.0890906364193.issue34850@roundup.psfhosted.org>


thautwarm <yaoxiansamma at gmail.com> added the comment:

What if using identity equality on integer literals is intended?

I'm now trying to speed up the generated code via the integer interning mechanism told by https://docs.python.org/3/c-api/long.html#c.PyLong_FromLong .

I think it okay to not complain when the operand of `is` or `is not` is an integer between -5 and 256.

----------
nosy: +thautwarm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Mon Nov 18 00:41:31 2019
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 18 Nov 2019 05:41:31 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1574055691.31.0.0650875181289.issue34850@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

That would potentially let an invalid usage slip through, since you know what you're doing, you can suppress the warning with:

  warnings.filterwarnings('ignore', category=SyntaxWarning, message='"is" with a literal')

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:06:22 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Nov 2019 06:06:22 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574057182.85.0.908567904673.issue38678@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 04c79d6088a22d467f04dbe438050c26de22fa85 by Raymond Hettinger in branch 'master':
bpo-38678: Improve argparse example in tutorial (GH-17207)
https://github.com/python/cpython/commit/04c79d6088a22d467f04dbe438050c26de22fa85


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:06:42 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 06:06:42 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574057202.94.0.873468635557.issue38678@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16715
pull_request: https://github.com/python/cpython/pull/17212

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:06:50 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 06:06:50 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574057210.66.0.521318235947.issue38678@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16716
pull_request: https://github.com/python/cpython/pull/17213

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:10:05 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Nov 2019 06:10:05 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574057405.32.0.962504802783.issue38678@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:11:22 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Nov 2019 06:11:22 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1574057482.45.0.312203820272.issue5150@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

reindent.py does the following:

1. Change Python (.py) files to use 4-space indents and no hard tab characters.  IDLE editor does this by default, as do other programming editors, except as PEP8 recommends something else for continuation lines within fences <(), [], {}>.  Before doing anything with reindent, I would want to check whether it messes with IDLE;s smart indents.

The format module and Format menu has functions to add/remove tabs and changes space indents, as well as rewrap.

The only thing left is dealing with a messed up file, but suspect that this is rarer than 19 (1st public version of reindent.py) or even 10 years ago (this issue).  Is this issue still needed?

2. Trim excess spaces and tabs from ends of lines.  Format => strip whitespace, added on this issue, does this. (The code is now in the format module.)

3. Remove empty lines at the end of files.  Rstrip should do this but does not.  This is a separate issue from reindenting.

4. Ensure that the last line ends with a newline.  Save in iomenu ensures this, but this should be part of 'strip whitespace', especially if we 'rstrip' on save (#33046).

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:17:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Nov 2019 06:17:17 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574057837.99.0.222166910338.issue38678@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 39134b374fd506c5f0f6d232e259ba48c651d88f by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-38678: Improve argparse example in tutorial (GH-17207) (GH-17212)
https://github.com/python/cpython/commit/39134b374fd506c5f0f6d232e259ba48c651d88f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:17:31 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Nov 2019 06:17:31 +0000
Subject: [issue38678] TypeError for Tutorial 10.3 Example 2
In-Reply-To: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>
Message-ID: <1574057851.63.0.338236328346.issue38678@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset d2faac63af007e52620c642dfcc576b787b55dcd by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-38678: Improve argparse example in tutorial (GH-17207) (GH-17213)
https://github.com/python/cpython/commit/d2faac63af007e52620c642dfcc576b787b55dcd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38678>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:21:21 2019
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Mon, 18 Nov 2019 06:21:21 +0000
Subject: [issue38834] TypedDict: no way to tell which (if any) keys are
 optional at runtime
In-Reply-To: <1574038434.98.0.659515857103.issue38834@roundup.psfhosted.org>
Message-ID: <1574058081.65.0.965881581065.issue38834@roundup.psfhosted.org>


Change by Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38834>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:38:53 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 18 Nov 2019 06:38:53 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574059133.83.0.499960112016.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16718
pull_request: https://github.com/python/cpython/pull/17215

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:46:56 2019
From: report at bugs.python.org (Bachsau)
Date: Mon, 18 Nov 2019 06:46:56 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1574059616.99.0.164543175229.issue34850@roundup.psfhosted.org>


Change by Bachsau <mail at bachsau.name>:


----------
nosy:  -Bachsau

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:47:35 2019
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 18 Nov 2019 06:47:35 +0000
Subject: [issue27647] Update Windows 2.7 build to Tcl/Tk 8.5.19
In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za>
Message-ID: <1574059655.04.0.890074466235.issue27647@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed
superseder:  -> [2.7] test_tk: test_use() of test_tkinter.test_widgets randomly fails with "integer value too large to represent" on with AMD64 Windows8 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27647>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:49:46 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 18 Nov 2019 06:49:46 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574059786.95.0.540949648248.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16719
pull_request: https://github.com/python/cpython/pull/17216

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:50:13 2019
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 18 Nov 2019 06:50:13 +0000
Subject: [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1574059813.09.0.375713788806.issue29275@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +easy, newcomer friendly
stage:  -> needs patch
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29275>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:56:16 2019
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 18 Nov 2019 06:56:16 +0000
Subject: [issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix
In-Reply-To: <1483210830.52.0.920210756798.issue29125@psf.upfronthosting.co.za>
Message-ID: <1574060176.81.0.111776771209.issue29125@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Nearly 3 years on, the patch looks fine to me (though I would also accept this issue as justification for removing Tix ;).

----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29125>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:57:11 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Nov 2019 06:57:11 +0000
Subject: [issue38790] test_fcntl failing on macOS CI
In-Reply-To: <1573684464.1.0.222448542247.issue38790@roundup.psfhosted.org>
Message-ID: <1574060231.21.0.997977983481.issue38790@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38790>
_______________________________________

From report at bugs.python.org  Mon Nov 18 01:58:56 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Nov 2019 06:58:56 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574060336.05.0.462688047943.issue22367@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Bump.  Serhiy, are you planning to follow up on this?

----------
nosy: +ned.deily
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Mon Nov 18 03:30:12 2019
From: report at bugs.python.org (Simon Friedberger)
Date: Mon, 18 Nov 2019 08:30:12 +0000
Subject: [issue38789] difflib lacks a way to check if results are empty
In-Reply-To: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>
Message-ID: <1574065812.26.0.0880692419076.issue38789@roundup.psfhosted.org>


Simon Friedberger <simon.nov2019 at a-oben.org> added the comment:

Hi Tim!

Sorry, if my explanation wasn't clear.

For some of the iterators - like the one produced by ndiff - the iterator will always return data, even if there is no difference in the files.

My current solution is to run difflib.unified_diff and check if the iterator is non-empty and then run difflib.ndiff again to get the output that I want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38789>
_______________________________________

From report at bugs.python.org  Mon Nov 18 03:32:50 2019
From: report at bugs.python.org (Simon Friedberger)
Date: Mon, 18 Nov 2019 08:32:50 +0000
Subject: [issue38789] difflib lacks a way to check if results are empty
In-Reply-To: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>
Message-ID: <1574065970.39.0.716822242423.issue38789@roundup.psfhosted.org>


Simon Friedberger <simon.nov2019 at a-oben.org> added the comment:

And, just to state this explicitly, I think you are right that there are general idioms for checking if a generator can produce an item but I think it would be nicer if iterators which could do this is in a cheap way (like in this case) would allow it explicitly.

I don't know, maybe I'm wrong. Just seems nice. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38789>
_______________________________________

From report at bugs.python.org  Mon Nov 18 03:44:17 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 18 Nov 2019 08:44:17 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574066657.83.0.402105041867.issue22367@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

FYI: I loaded the pr just now and tested on AIX.

$ ./python -m test test_fcntl
0:00:00 Run tests sequentially
0:00:00 [1/1] test_fcntl

== Tests result: SUCCESS ==

1 test OK.

Total duration: 767 ms
Tests result: SUCCESS

$ git status
On branch pr_17154

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Mon Nov 18 04:47:13 2019
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 18 Nov 2019 09:47:13 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1574070433.01.0.843005644157.issue38656@roundup.psfhosted.org>


Florian Bruhin <python.org at the-compiler.org> added the comment:

I'm seeing the same in ranger and I'm currently trying to debug this - I'm still
not quite sure what I'm seeing as there seem to be various issues/weirdnesses
which overlap each other.

This strikes me as odd:

>>> import mimetypes
>>> mimetypes.guess_type('E01.mkv')
('video/x-matroska', None)
>>> mimetypes.types_map['.mkv']
'video/x-matroska'

>>> mt = mimetypes.MimeTypes()
>>> mt.guess_type('E01.mkv')
(None, None)
>>> mt.types_map
({'.rtf': 'application/rtf', [redacted for brevity]}, {'.js': 'application/javascript', [redacted for brevity]})
>>> mt.types_map[0]['.mkv']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: '.mkv'
>>> mt.types_map[1]['.mkv']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: '.mkv'

The Python documentation claims: "This class represents a MIME-types database.
By default, it provides access to the same database as the rest of this module.
The initial database is a copy of that provided by the module" - yet that
apparently isn't the case.

I see this with both Python 3.7.5 and 3.8.0, but with 3.6.9 I get the correct
output for both module- and class-level access.

----------
nosy: +The Compiler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Mon Nov 18 05:00:34 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Mon, 18 Nov 2019 10:00:34 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574071234.0.0.876222523746.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

Can we still consider this for 3.9? I still think this is an easy way to accidentally blow your foot off with something that will probably only show up in production.

----------
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Nov 18 05:18:58 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 18 Nov 2019 10:18:58 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574072338.35.0.791755410365.issue37228@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I see two proposals:
1. Change the default for reuse_address flag
2. Document existing behavior as dangerous.

What is the suggestion? Pick one, please :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Nov 18 05:48:08 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Mon, 18 Nov 2019 10:48:08 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574074088.92.0.158544415494.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

I definitely propose changing the default for UDP sockets. Having multiple processes binding to a the same port and load-balancing incoming UDP traffic intentionally is a rare scenario which should be supported but not the default.

For TCP the default is reasonable because everyone creating server sockets will usually want to set it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Nov 18 06:01:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 11:01:21 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1574074881.87.0.255680050394.issue38815@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

And the last one, AMD64 FreeBSD Shared 3.7:
https://buildbot.python.org/all/#/builders/367/builds/25

FAIL: test_min_max_version (test.test_ssl.ContextTests)
FAIL: test_min_max_version_mismatch (test.test_ssl.ThreadedTests)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38815>
_______________________________________

From report at bugs.python.org  Mon Nov 18 06:05:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 11:05:36 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1574075136.19.0.502105149602.issue38811@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16720
pull_request: https://github.com/python/cpython/pull/17219

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Nov 18 06:07:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 11:07:50 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1574075270.55.0.251756680761.issue38811@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The change failed on x86 Windows7 3.x buildbot:
https://buildbot.python.org/all/#/builders/58/builds/3257

Moreover, PR 17170 was merged whereas the CLA was not signed. So I created PR 17219 to revert the change to fix the Windows 7 failure and to wait until the CLA is signed.

======================================================================
ERROR: test_symlink_to_not_implemented (test.test_pathlib.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_pathlib.py", line 2031, in test_symlink_to_not_implemented
    link.symlink_to(target)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\pathlib.py", line 1395, in symlink_to
    self._accessor.symlink(target, self, target_is_directory)
OSError: [WinError 1314] A required privilege is not held by the client: 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_848\\test_python_worker_2032\\@test_2032_tmp\\fileA' -> 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_848\\test_python_worker_2032\\@test_2032_tmp\\dirA\\linkAA'

======================================================================
ERROR: test_symlink_to_not_implemented (test.test_pathlib.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_pathlib.py", line 2031, in test_symlink_to_not_implemented
    link.symlink_to(target)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\pathlib.py", line 1395, in symlink_to
    self._accessor.symlink(target, self, target_is_directory)
OSError: [WinError 1314] A required privilege is not held by the client: 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_848\\test_python_worker_2032\\@test_2032_tmp\\fileA' -> 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_848\\test_python_worker_2032\\@test_2032_tmp\\dirA\\linkAA'

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Nov 18 06:14:30 2019
From: report at bugs.python.org (Mihail Milushev)
Date: Mon, 18 Nov 2019 11:14:30 +0000
Subject: [issue9625] argparse: Problem with defaults for variable nargs when
 using choices
In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za>
Message-ID: <1574075670.7.0.0400185102884.issue9625@roundup.psfhosted.org>


Mihail Milushev <python.org at site.lanzz.org> added the comment:

It looks like choices are broken for nargs='*' even without using default:

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('test', nargs='*', choices=['foo', 'bar', 'baz'])
_StoreAction(option_strings=[], dest='test', nargs='*', const=None, default=None, type=None, choices=['foo', 'bar', 'baz'], help=None, metavar=None)
>>> parser.parse_args([])
usage: [-h] [{foo,bar,baz} [{foo,bar,baz} ...]]
: error: argument test: invalid choice: [] (choose from 'foo', 'bar', 'baz')

----------
nosy: +lanzz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9625>
_______________________________________

From report at bugs.python.org  Mon Nov 18 06:26:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 11:26:40 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1574076400.6.0.754920175087.issue38811@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 59c80889ff3f74230a613732aacf93d4de1e0e04 by Victor Stinner in branch 'master':
Revert "bpo-38811: Check for presence of os.link method in pathlib. (GH-17170)" (#17219)
https://github.com/python/cpython/commit/59c80889ff3f74230a613732aacf93d4de1e0e04


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Nov 18 06:45:25 2019
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 18 Nov 2019 11:45:25 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1574077525.16.0.897775012515.issue38656@roundup.psfhosted.org>


Florian Bruhin <python.org at the-compiler.org> added the comment:

I now bisected this with the following script:

#!/bin/bash
git clean -dxf
./configure || exit 125
make -j2 || exit 125
output=$(./python -c "import mimetypes; mt = mimetypes.MimeTypes(); print(mt.guess_type('E01.mkv')[0])")
echo "$output"
echo "$(git describe) $output" >> ../bisect-results.txt
[[ $output == None ]] && exit 1 || exit 0

This shows 9fc720e5e4f772598013ea48a3f0d22b2b6b04fa as the commit which broke this (bpo-4963, GH-3062).

----------
nosy: +dhess, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Mon Nov 18 06:46:16 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Nov 2019 11:46:16 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
In-Reply-To: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>
Message-ID: <1574077576.01.0.259178223376.issue38830@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:03:25 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Nov 2019 12:03:25 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
In-Reply-To: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>
Message-ID: <1574078605.88.0.322409200273.issue38830@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 5383956583bb758f3828513bcdd011871f24a0e8 by Vinay Sajip in branch 'master':
bpo-38830: Correct slot signature in Qt example. (GH-17220)
https://github.com/python/cpython/commit/5383956583bb758f3828513bcdd011871f24a0e8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:06:02 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Nov 2019 12:06:02 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
In-Reply-To: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>
Message-ID: <1574078762.66.0.745233564608.issue38830@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +16722
pull_request: https://github.com/python/cpython/pull/17221

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:10:51 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Nov 2019 12:10:51 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
In-Reply-To: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>
Message-ID: <1574079051.01.0.917386854742.issue38830@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +16723
pull_request: https://github.com/python/cpython/pull/17222

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:23:52 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Nov 2019 12:23:52 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
In-Reply-To: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>
Message-ID: <1574079832.23.0.459773745169.issue38830@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 21eb731057d614fb642c609ae89f66d75fa0ac3a by Vinay Sajip in branch '3.8':
[3.8] bpo-38830: Correct slot signature in Qt example. (GH-17220) (GH-17221)
https://github.com/python/cpython/commit/21eb731057d614fb642c609ae89f66d75fa0ac3a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:24:19 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Nov 2019 12:24:19 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
In-Reply-To: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>
Message-ID: <1574079859.3.0.83342697175.issue38830@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 9a4c5c30d93278e420a7dadafbaa35a5b52325ec by Vinay Sajip in branch '3.7':
[3.7] bpo-38830: Correct slot signature in Qt example. (GH-17220) (GH-17222)
https://github.com/python/cpython/commit/9a4c5c30d93278e420a7dadafbaa35a5b52325ec


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:24:50 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Nov 2019 12:24:50 +0000
Subject: [issue38830] `A Qt GUI for logging` produces TypeError
In-Reply-To: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>
Message-ID: <1574079890.32.0.216750748757.issue38830@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38830>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:29:24 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 12:29:24 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1574080164.95.0.519494037599.issue16576@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16724
pull_request: https://github.com/python/cpython/pull/17223

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:30:01 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 12:30:01 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1574080201.13.0.350266414688.issue16576@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16725
pull_request: https://github.com/python/cpython/pull/17224

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:32:06 2019
From: report at bugs.python.org (=?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 18 Nov 2019 12:32:06 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1574080326.24.0.0192463336997.issue38811@roundup.psfhosted.org>


Change by Toke H?iland-J?rgensen <toke at toke.dk>:


----------
pull_requests: +16726
pull_request: https://github.com/python/cpython/pull/17225

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Nov 18 07:32:06 2019
From: report at bugs.python.org (=?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 18 Nov 2019 12:32:06 +0000
Subject: [issue26978] Implement pathlib.Path.link (Using os.link)
In-Reply-To: <1556420459.86.0.258434208738.issue26978@roundup.psfhosted.org>
Message-ID: <1574080326.38.0.499430644847.issue26978@roundup.psfhosted.org>


Change by Toke H?iland-J?rgensen <toke at toke.dk>:


----------
pull_requests: +16727
pull_request: https://github.com/python/cpython/pull/17225

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26978>
_______________________________________

From report at bugs.python.org  Mon Nov 18 08:23:28 2019
From: report at bugs.python.org (David K. Hess)
Date: Mon, 18 Nov 2019 13:23:28 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1574083408.16.0.440053610905.issue38656@roundup.psfhosted.org>


David K. Hess <david_k_hess at mac.com> added the comment:

Hi, I'm the author of the commit that's been fingered. Some comments about the behavior being reported....

First, as pointed out by @xtreak, indeed the mimetypes module uses mimetypes files present on the platform to add to the built in list of mimetypes. In this case, "video/x-mastroska" and ".mkv" are not found in the mimetypes module and were never there - they are coming from the host OS.

Also, for better or worse, the mimetypes module has an internal "init" method that does more than just instantiates a MimeTypes instance for default use:

https://github.com/python/cpython/blob/5c0c325453a175350e3c18ebb10cc10c37f9595c/Lib/mimetypes.py#L345

It also loads in these system files (and also Windows Registry entries on Win32) into a fresh MimeTypes instance. So, addressing what @The Compiler is seeing, properly resetting the mimetypes module really involves calling mimetypes.init(). By historical design, instantiating a MimeTypes class instance directly will not use host OS system mime type files.

As to why this commit is causing a change in the observed behavior, the problem that was corrected in this commit was that the mimetypes module had non-deterministic behavior related to initialization. In the original init code, the module level mime types tables are changed (really corrupted) after first load and you can never reinitialize the module back to a known good state (i.e. to original module defaults without information from the host OS system).

So, realistically, the behavior currently observed is the correct behavior given the presence and historical nature of the init function. The fact that a fresh MimeTypes instance without having been init()'d or with no filenames provided is returning an OS entry prior to this commit is really part of the initialization bug which was fixed.

Regarding the ranger bug, the main thing is you should not use a MimeTypes instance directly unless you run it through the same initializations that the init code does.

Anyway, that's my perspective having waded through all of that during the original BPO. I don't claim it's the correct one but that's where we are at.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Mon Nov 18 08:29:10 2019
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 18 Nov 2019 13:29:10 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1574083750.01.0.0448288527804.issue38656@roundup.psfhosted.org>


Florian Bruhin <python.org at the-compiler.org> added the comment:

Ah, I think I see what's happening now.

Before that commit, when doing "mt = mimetypes.MimeTypes()", its self.types_map is populated as follows:

- Its __init__ method calls the mimetypes.init() function.
- That then reads all the files in mimetypes.knownfiles into a temporary MimeTypes object
- The resulting types_map is saved as a module global (mimetypes.types_map).
- The __init__ of our "mt" object continues and picks up all the types from that global types_map.

After the change, instead this happens:

- Its __init__ method calls the mimetypes.init() function.
- Like above, mimetypes.init() populates mimetypes.types_map
- However, MimeTypes.__init__ now uses _types_map_default instead of the (now reassigned) types_map, i.e. it never reads the entries from knownfiles.

In other words, it only picks up the hardcoded types in the module, but never reads the files it's (according to the documentation) supposed to read - thus the difference between using "mimetypes.guess_type('E01.mkv')" (which uses the correctly initialized global object) and using "mimetypes.MimeTypes().guess_type('E01.mkv')" (which doesn't know about mkv, as it's defined in one of the mimes.types files, not hardcoded in the module).

As a workaround, this results in the same behavior as before:

mt = mimetypes.MimeTypes()
for fn in mimetypes.knownfiles:
    if os.path.isfile(fn):
        mt.read(fn)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Mon Nov 18 08:34:34 2019
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 18 Nov 2019 13:34:34 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1574084074.23.0.685434694682.issue38656@roundup.psfhosted.org>


Florian Bruhin <python.org at the-compiler.org> added the comment:

Ah, I only saw dhess' comment after already submitting mine.

> By historical design, instantiating a MimeTypes class instance directly will not use host OS system mime type files.

Yet that wasn't what happened before that commit, and it's also not the behaviour which was (and is) documented - from https://docs.python.org/3.6/library/mimetypes.html#mimetypes.MimeTypes

    By default, it provides access to the same database as the rest of this module. The initial database is a copy of that provided by the module, and may be extended by loading additional mime.types-style files into the database using the read() or readfp() methods. The mapping dictionaries may also be cleared before loading additional data if the default data is not desired.

    The optional filenames parameter can be used to cause additional files to be loaded ?on top? of the default database.

You might be right in that the new behaviour is in some way more correct - but it's wildly backwards-incompatible, and it's contrary to everything the documentation says.

I've only skimmed over bpo-4963 though - maybe I missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Mon Nov 18 08:37:51 2019
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 18 Nov 2019 13:37:51 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1574084271.37.0.47002780134.issue38656@roundup.psfhosted.org>


Change by Florian Bruhin <python.org at the-compiler.org>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Mon Nov 18 09:28:07 2019
From: report at bugs.python.org (David K. Hess)
Date: Mon, 18 Nov 2019 14:28:07 +0000
Subject: [issue38656] mimetypes for python 3.7.5 fails to detect matroska video
In-Reply-To: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>
Message-ID: <1574087287.66.0.158320254355.issue38656@roundup.psfhosted.org>


David K. Hess <david_k_hess at mac.com> added the comment:

The documentation you quoted does read to me as compatible? The database it is referring to is the one hardcoded in the module ??not the one assembled from that and the host OS. But, maybe this is just the vagaries of language and perspective at play.

Anyway I do agree it is an unexpected behavior change from the perspective of a user of the MimeTypes class directly. To get the best context for this change, it's useful to run through the long history of the issue that drove it:

https://bugs.python.org/issue4963

Note, that discussion never touched on the use case of instantiating a MimeTypes class directly and there are apparently no test cases covering this particular scenario either. With no awareness of this perspective/use case it didn't get directly addressed.

Perhaps all MimeTypes instances should auto-load system files unless a new __init__ param selects for this new "clean" behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38656>
_______________________________________

From report at bugs.python.org  Mon Nov 18 09:29:21 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Nov 2019 14:29:21 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1574087361.32.0.239211493705.issue16576@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset bef2815533011be9f0ce5fa2965bcada76b509b8 by Vinay Sajip (Miss Islington (bot)) in branch '3.8':
bpo-16576: Add checks for bitfields passed by value to functions. (GH-17097) (GH-17223)
https://github.com/python/cpython/commit/bef2815533011be9f0ce5fa2965bcada76b509b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Mon Nov 18 09:35:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 14:35:51 +0000
Subject: [issue38835] pyfpe.h: Exclude PyFPE_START_PROTECT and
 PyFPE_END_PROTECT from the Py_LIMITED_API
Message-ID: <1574087751.21.0.402733884196.issue38835@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The bpo-29137 removed the fpectl module. But two macros were kept in pyfpe.h:

/* These macros used to do something when Python was built with --with-fpectl,
 * but support for that was dropped in 3.7. We continue to define them though,
 * to avoid breaking API users.
 */

#define PyFPE_START_PROTECT(err_string, leave_stmt)
#define PyFPE_END_PROTECT(v)

I propose to exclude them from the stable API. Maybe at least exclude them from the stable API >= 3.9?

commit 735ae8d139a673b30b321dc10acfd3d14f0d633b
Author: Nathaniel J. Smith <njs at pobox.com>
Date:   Fri Jan 5 23:15:34 2018 -0800

    bpo-29137: Remove fpectl module (#4789)
    
    This module has never been enabled by default, never worked correctly
    on x86-64, and caused ABI problems that caused C extension
    compatibility. See bpo-29137 for details/discussion.

----------
components: Library (Lib)
messages: 356870
nosy: vstinner
priority: normal
severity: normal
status: open
title: pyfpe.h: Exclude PyFPE_START_PROTECT and PyFPE_END_PROTECT from the Py_LIMITED_API
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38835>
_______________________________________

From report at bugs.python.org  Mon Nov 18 09:40:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 14:40:05 +0000
Subject: [issue38835] pyfpe.h: Exclude PyFPE_START_PROTECT and
 PyFPE_END_PROTECT from the Py_LIMITED_API
In-Reply-To: <1574087751.21.0.402733884196.issue38835@roundup.psfhosted.org>
Message-ID: <1574088005.78.0.259571695982.issue38835@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python/pyfpe.c still contains two variables (PyFPE_jbuf and PyFPE_counter) and one function (PyFPE_dummy) for ABI compatibility:
---
/* These variables used to be used when Python was built with --with-fpectl,
 * but support for that was dropped in 3.7. We continue to define them,
 * though, because they may be referenced by extensions using the stable ABI.
 */

#include "setjmp.h"

jmp_buf PyFPE_jbuf;
int PyFPE_counter;

double
PyFPE_dummy(void *dummy)
{
    return 1.0;
}
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38835>
_______________________________________

From report at bugs.python.org  Mon Nov 18 09:52:53 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 14:52:53 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574088773.05.0.0906665522692.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16728
pull_request: https://github.com/python/cpython/pull/17226

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 09:53:00 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 14:53:00 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574088780.24.0.386115340901.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16729
pull_request: https://github.com/python/cpython/pull/17227

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 09:52:42 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 14:52:42 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574088762.89.0.612259630263.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 289cf0fbf78c4f38c38ac71ac8b772be7ec2672f by Miss Islington (bot) (Brandt Bucher) in branch 'master':
bpo-38823: Clean up refleaks in _tkinter initialization. (GH-17206)
https://github.com/python/cpython/commit/289cf0fbf78c4f38c38ac71ac8b772be7ec2672f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 09:55:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 14:55:58 +0000
Subject: [issue38835] pyfpe.h: Exclude PyFPE_START_PROTECT and
 PyFPE_END_PROTECT from the Py_LIMITED_API
In-Reply-To: <1574087751.21.0.402733884196.issue38835@roundup.psfhosted.org>
Message-ID: <1574088958.81.0.195110208132.issue38835@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38835>
_______________________________________

From report at bugs.python.org  Mon Nov 18 10:09:52 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 15:09:52 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574089792.14.0.527798301777.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9e4d0312101cc2bc44a9549974d4a25f80e1dc12 by Miss Islington (bot) in branch '3.7':
bpo-38823: Clean up refleaks in _tkinter initialization. (GH-17206)
https://github.com/python/cpython/commit/9e4d0312101cc2bc44a9549974d4a25f80e1dc12


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 10:10:34 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 15:10:34 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574089834.72.0.476999809708.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 42a4359390b78b3360e100fc9c075495e48354b2 by Miss Islington (bot) in branch '3.8':
bpo-38823: Clean up refleaks in _tkinter initialization. (GH-17206)
https://github.com/python/cpython/commit/42a4359390b78b3360e100fc9c075495e48354b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 10:40:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 15:40:21 +0000
Subject: [issue38835] pyfpe.h: Exclude PyFPE_START_PROTECT and
 PyFPE_END_PROTECT from the Py_LIMITED_API
In-Reply-To: <1574087751.21.0.402733884196.issue38835@roundup.psfhosted.org>
Message-ID: <1574091621.68.0.893984337792.issue38835@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16731
pull_request: https://github.com/python/cpython/pull/17231

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38835>
_______________________________________

From report at bugs.python.org  Mon Nov 18 10:42:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 15:42:59 +0000
Subject: [issue29137] Fix fpectl-induced ABI breakage
In-Reply-To: <1483402510.43.0.646850547969.issue29137@psf.upfronthosting.co.za>
Message-ID: <1574091778.99.0.125249346871.issue29137@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I propose PR 17231: "PyFPE_START_PROTECT() and PyFPE_END_PROTECT() macros are empty: they do nothing for one year (since commit 735ae8d), stop using them."

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29137>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:11:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 16:11:14 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1574093474.75.0.942457622859.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16732
pull_request: https://github.com/python/cpython/pull/17232

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:13:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 16:13:40 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1574093620.26.0.885640791493.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16733
pull_request: https://github.com/python/cpython/pull/17233

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:14:56 2019
From: report at bugs.python.org (Jason Killen)
Date: Mon, 18 Nov 2019 16:14:56 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574093696.77.0.976275944892.issue38722@roundup.psfhosted.org>


Change by Jason Killen <jsnklln at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:17:33 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 18 Nov 2019 16:17:33 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574093853.94.0.359586066106.issue37228@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'd be -1 on changing the default of an existing method, at least without consulting with a wider audience.  We can add a new method to the loop and deprecate create_datagram_endpoint.

I suggest to post to python-dev and discuss this before making any decisions.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:18:53 2019
From: report at bugs.python.org (Jason Killen)
Date: Mon, 18 Nov 2019 16:18:53 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574093933.62.0.695052864363.issue38722@roundup.psfhosted.org>


Jason Killen <jsnklln at gmail.com> added the comment:

Tests working now.  PR submitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:37:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 16:37:50 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1574095070.97.0.964623024311.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

One further step would be to change the VECTORCALL/FASTCALL calling convention to pass tstate. But I am not sure what is the risk to do that in Python 3.9? Cython uses FASTCALL internally for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:39:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 16:39:51 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1574095191.85.0.282481742518.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 04394df74b3d0783893da7dafa7803a003516402 by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in float.__getformat__() (GH-17232)
https://github.com/python/cpython/commit/04394df74b3d0783893da7dafa7803a003516402


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:40:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 16:40:11 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1574095211.09.0.333669320767.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset bc7d3aa6d74b718699b7a6bced9b0dfdfbf95c13 by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in _multibytecodec init (GH-17233)
https://github.com/python/cpython/commit/bc7d3aa6d74b718699b7a6bced9b0dfdfbf95c13


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:44:25 2019
From: report at bugs.python.org (Jason Killen)
Date: Mon, 18 Nov 2019 16:44:25 +0000
Subject: [issue38812] Comparing datetime.time objects incorrect for TZ aware
 and unaware
In-Reply-To: <1573824611.55.0.420390589696.issue38812@roundup.psfhosted.org>
Message-ID: <1574095465.74.0.46989850507.issue38812@roundup.psfhosted.org>


Jason Killen <jsnklln at gmail.com> added the comment:

Yep I wasn't seeing the forest for the trees.  Thanks for clearing that up.  I'll swoop back in and see what I can do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38812>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:49:55 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 18 Nov 2019 16:49:55 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574095795.03.0.201864718038.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16735
pull_request: https://github.com/python/cpython/pull/17235

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:53:43 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 16:53:43 +0000
Subject: [issue23407] os.walk always follows Windows junctions
In-Reply-To: <1423342763.81.0.179122512075.issue23407@psf.upfronthosting.co.za>
Message-ID: <1574096023.06.0.522534230055.issue23407@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

At a minimum, it needs to be turned into a GitHub PR.

We've made some significant changes in this area in 3.8, so possibly the best available code is now in shutil.rmtree (or shutil.copytree) rather than the older patch files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23407>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:55:04 2019
From: report at bugs.python.org (MaT1g3R)
Date: Mon, 18 Nov 2019 16:55:04 +0000
Subject: [issue38836] Links are duplicated in documentation search result
Message-ID: <1574096104.71.0.223088739291.issue38836@roundup.psfhosted.org>


New submission from MaT1g3R <peijun.ma at protonmail.com>:

When I do a search in documentation, for example:

https://docs.python.org/3.9/search.html?q=os.walk

The links in the results are sometimes duplicated, for example this
link below shows up twice in the search result:

https://docs.python.org/3.9/library/os.html?highlight=os%20walk#os.walk

----------
assignee: docs at python
components: Documentation
messages: 356883
nosy: MaT1g3R, docs at python
priority: normal
severity: normal
status: open
title: Links are duplicated in documentation search result
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38836>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:55:36 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 18 Nov 2019 16:55:36 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574096136.28.0.610274563872.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16736
pull_request: https://github.com/python/cpython/pull/17236

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:58:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Nov 2019 16:58:09 +0000
Subject: [issue38836] Links are duplicated in documentation search result
In-Reply-To: <1574096104.71.0.223088739291.issue38836@roundup.psfhosted.org>
Message-ID: <1574096289.66.0.907367363496.issue38836@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38836>
_______________________________________

From report at bugs.python.org  Mon Nov 18 11:59:50 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 16:59:50 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1574096390.36.0.867446685611.issue33125@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

If the patches are for Tcl/Tk, then you should submit it to them.

I'm not a Tk maintainer, and I never want to be one, so frankly I'd be happier to say it's not supported on ARM :)

But if it builds fine with our PCbuild/prepare_tcltk.bat script and people want it then I'll keep it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:03:58 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 17:03:58 +0000
Subject: [issue38822] Inconsistent os.stat behavior for directory with Access
 Denied
In-Reply-To: <1573928094.88.0.209131085868.issue38822@roundup.psfhosted.org>
Message-ID: <1574096638.93.0.0545736514704.issue38822@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I haven't debugged it, but I'm guessing we're not handling the trailing slash properly when falling back to asking the parent directory for information.

Looking at the actual stat result for "C:\System Volume Information" vs. "C:\Windows", most of the information is missing in the first case, which should mean that we can't access it but we know it's a directory because the entry in C:\ said so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38822>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:14:51 2019
From: report at bugs.python.org (Dave Lotton)
Date: Mon, 18 Nov 2019 17:14:51 +0000
Subject: [issue38837] struct.pack: Unable to pack more than 256 bytes at a time
Message-ID: <1574097291.45.0.986281483128.issue38837@roundup.psfhosted.org>


New submission from Dave Lotton <dlotton at gmail.com>:

Using struct.pack it is not possible (Python 3.6.8 and 2.7.15) to pack more than 256 bytes at a time.  

This seems like an arbitrarily small number, and seems to be inconsistent with the capabilities of the unpack function, which is able to unpack a larger number of bytes.

Below demonstrates the issue...

>>> # Create large data set to be packed
>>> data = range(0,512)

>>> # Demonstrate format string for packing
>>> '<%dB' % len(data)
'<512B'

>>> # Try to pack large data set
>>> packed = pack('<%dB' % len(data), *data)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: ubyte format requires 0 <= number <= 255

>>> # Make data set <= 256 bytes
>>> data = range(0,256)
>>> packed = pack('<%dB' % len(data), *data)
>>> # Data successfully packed


>>> # Append another 256 bytes to packed data
>>> packed += pack('<%dB' % len(data), *data)

>>> # Unpack all 512 bytes
>>> unpacked = unpack('<%dB' % len(packed), packed)
>>> 
>>> unpacked
(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255)




The 256 byte limit on packing seems arbitrarily small and is inconsistent with the unpack function.  I'm wondering if there is a rationale for this limit, or it has simply been an oversight in the implementation.

I am using Mint Linux 19.2 64-bit (Ubuntu Bionic - based distro).  The problem is manifested on both Python 3.6.8 and 2.7.15 included in the distro.

----------
components: Library (Lib)
messages: 356886
nosy: Dave Lotton
priority: normal
severity: normal
status: open
title: struct.pack: Unable to pack more than 256 bytes at a time
type: behavior
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38837>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:19:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 17:19:38 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1574097578.18.0.0128116948544.issue38597@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Could you share just one of your .pyd files?

Without being able to see whether they are compiled incorrectly, it's hard to be sure whether this is the same cause as before. It certainly looks like distutils is still going to link correctly.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:32:26 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 17:32:26 +0000
Subject: [issue38453] ntpath.realpath() does not fully resolve relative paths
In-Reply-To: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>
Message-ID: <1574098346.48.0.0338546223583.issue38453@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Closing this as I believe it's done, but happy to reopen if we find another edge case (or start a new issue).

----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38453>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:32:35 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 17:32:35 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1574098355.54.0.356490585975.issue38809@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ee703cbb418b7458bebb1d26a5e19d6b55280b28 by Miss Islington (bot) (Tal Einat) in branch 'master':
bpo-38809: Windows build scripts use python.exe from virtual envs (GH-17164)
https://github.com/python/cpython/commit/ee703cbb418b7458bebb1d26a5e19d6b55280b28


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:32:41 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 17:32:41 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1574098361.41.0.276799952001.issue38809@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16737
pull_request: https://github.com/python/cpython/pull/17237

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:32:50 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 17:32:50 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1574098370.39.0.660694467048.issue38809@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16738
pull_request: https://github.com/python/cpython/pull/17238

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:40:40 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 18 Nov 2019 17:40:40 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574098840.66.0.637466471871.issue38722@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:44:48 2019
From: report at bugs.python.org (paul j3)
Date: Mon, 18 Nov 2019 17:44:48 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1574099088.71.0.519586087321.issue38821@roundup.psfhosted.org>


Change by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:53:17 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 17:53:17 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1574099597.99.0.658839649756.issue38809@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2b928d9bf75d82b86dc3b4fcbc243d36a7958f4c by Miss Islington (bot) in branch '3.7':
bpo-38809: Windows build scripts use python.exe from virtual envs (GH-17164)
https://github.com/python/cpython/commit/2b928d9bf75d82b86dc3b4fcbc243d36a7958f4c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:53:24 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 17:53:24 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1574099604.68.0.90667507524.issue38809@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cbbf1098f383e575d93841e555329eb66283c2f1 by Miss Islington (bot) in branch '3.8':
bpo-38809: Windows build scripts use python.exe from virtual envs (GH-17164)
https://github.com/python/cpython/commit/cbbf1098f383e575d93841e555329eb66283c2f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:54:12 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 18 Nov 2019 17:54:12 +0000
Subject: [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
In-Reply-To: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>
Message-ID: <1574099652.23.0.0762625890706.issue38809@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38809>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:54:23 2019
From: report at bugs.python.org (Yurii Leonov)
Date: Mon, 18 Nov 2019 17:54:23 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1574099663.88.0.30355042323.issue38597@roundup.psfhosted.org>


Yurii Leonov <tavoseg at gmail.com> added the comment:

Done:
.pyd files are added in https://github.com/Yuriy-Leonov/cython_imports_limit_issue/commit/2f9e7c02798fb52185dabfe6ce3811c439ca2839

folder with name "dist_example_with_error"

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Mon Nov 18 13:22:08 2019
From: report at bugs.python.org (wesinator)
Date: Mon, 18 Nov 2019 18:22:08 +0000
Subject: [issue38838] Exception ignored in: module 'threading' in _shutdown,
 _signal_handler
Message-ID: <1574101328.65.0.270951183149.issue38838@roundup.psfhosted.org>


New submission from wesinator <13hurdw at gmail.com>:

macOS 10.14.6
python 3.7.5 

Exception ignored in: <module 'threading' from '/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py'>
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 1274, in _shutdown
    def _shutdown():
  File "/usr/local/lib/python3.7/site-packages/tcex/tcex.py", line 178, in _signal_handler
    self.exit(1, 'The App received an interrupt signal and will now exit.')
  File "/usr/local/lib/python3.7/site-packages/tcex/tcex.py", line 303, in exit
    sys.exit(code)
SystemExit: 1

----------
components: Library (Lib)
messages: 356893
nosy: wesinator
priority: normal
severity: normal
status: open
title: Exception ignored in: module 'threading' in _shutdown, _signal_handler
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38838>
_______________________________________

From report at bugs.python.org  Mon Nov 18 13:23:14 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Nov 2019 18:23:14 +0000
Subject: [issue38818] Modify PyInterpreterState.eval_frame to pass tstate
 (PyThreadState)
In-Reply-To: <1573863093.89.0.126489580733.issue38818@roundup.psfhosted.org>
Message-ID: <1574101394.9.0.138797439663.issue38818@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I think bpo-38500 needs to get resolved first before this as that will affect whether this is acceptable or not as an API-breaking change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38818>
_______________________________________

From report at bugs.python.org  Mon Nov 18 13:35:13 2019
From: report at bugs.python.org (wesinator)
Date: Mon, 18 Nov 2019 18:35:13 +0000
Subject: [issue38838] Exception ignored in: module 'threading' in _shutdown,
 _signal_handler
In-Reply-To: <1574101328.65.0.270951183149.issue38838@roundup.psfhosted.org>
Message-ID: <1574102113.34.0.856898971189.issue38838@roundup.psfhosted.org>


wesinator <13hurdw at gmail.com> added the comment:

didn't see this was a third party package.

disregard.

sorry

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38838>
_______________________________________

From report at bugs.python.org  Mon Nov 18 13:48:24 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 18 Nov 2019 18:48:24 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574102904.62.0.162746404262.issue38722@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

I don't see why this should be considered a security issue.

This should likely have been done when io.open_code() was initially added, but now that 3.8 is out, I don't think backporting this would be wise.

----------
nosy: +taleinat
type: security -> enhancement
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 13:51:28 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Mon, 18 Nov 2019 18:51:28 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574103088.29.0.682504148764.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

Sure, I fully appreciate implications of changing default behaviour and will post on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Nov 18 13:57:48 2019
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 18 Nov 2019 18:57:48 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574103468.29.0.755449014319.issue38722@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:03:46 2019
From: report at bugs.python.org (Ilya Kulakov)
Date: Mon, 18 Nov 2019 19:03:46 +0000
Subject: [issue17013] Allow waiting on a mock
In-Reply-To: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za>
Message-ID: <1574103826.64.0.979162391957.issue17013@roundup.psfhosted.org>


Ilya Kulakov <kulakov.ilya at gmail.com> added the comment:

I have submitted an alternative implementation of this feature heavily inspired by _AwaitEvent I wrote for asynctest [0]. 

There was recently an interest from the community towards asynctest to the point that got some of its measures merged into CPython [1].

The key features of my implementation [2]:

- Gives meaning to the existing Mock.called property, otherwise not much useful
- Does not require end users to do anything: change is automatically available in every Mock (and any subclass of mock that does not override `called`)
- Use of conditionals provides API that allows much richer extension: instead of hardcoding conditions as events it allows to wait until arbitrary predicate becomes true
- Utilizes existing semantics of python conditionals (both asyncio and threading)

Accepting this PR will allow me to bring _AwaitEvent thereby completing mock.py with waiting mechanics with identical semantics for both threading-based and asyncio-based cases.


0: https://github.com/Martiusweb/asynctest/blob/4b1284d6bab1ae90a6e8d88b882413ebbb7e5dce/asynctest/mock.py#L428
1: https://github.com/python/cpython/pull/9296
2: https://github.com/python/cpython/pull/17133

----------
nosy: +Kentzo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17013>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:06:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 19:06:52 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574104012.1.0.817805823695.issue38500@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:10:40 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 19:10:40 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574104240.02.0.622777294724.issue38722@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It's a security issue because Python 3.8 says it will open files to be executed with io.open_code() instead of open(). This allows a way to bypass that.

That said, this appears to be a fallback case, so I'm not hugely concerned. I haven't quite figured out why it would fall back here (that involved reading the pkgutil sources ;) ).

I would vote for backporting to 3.8.1, but if Tal wants to push back and nobody else has an opinion then whatever.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:11:21 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 19:11:21 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574104281.69.0.150425690364.issue38722@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e243bae9999418859106328d9fce71815b7eb2fe by Miss Islington (bot) (jsnklln) in branch 'master':
bpo-38722: Runpy use io.open_code() (GH-17234)
https://github.com/python/cpython/commit/e243bae9999418859106328d9fce71815b7eb2fe


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:14:19 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 18 Nov 2019 19:14:19 +0000
Subject: [issue35004] Odd behavior when using datetime.timedelta under cProfile
In-Reply-To: <1539729063.07.0.788709270274.issue35004@psf.upfronthosting.co.za>
Message-ID: <1574104459.85.0.262320668915.issue35004@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

This bug is fixed in both 3.8 and 3.7, @p-ganssle what do you think about closing this?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35004>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:16:29 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 18 Nov 2019 19:16:29 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574104589.11.0.835191634129.issue38722@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thanks Steve! I hadn't realized that we'd made such a declaration WRT opening of code files in general. In that case, this is certainly at least a bug fix, and should be backported.

----------
type: enhancement -> security
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:17:04 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 19:17:04 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574104624.05.0.686151100933.issue38722@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16740
pull_request: https://github.com/python/cpython/pull/17241

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:21:04 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 18 Nov 2019 19:21:04 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574104864.88.0.899386649233.issue38722@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thanks for reporting this, Dominic!

Thanks for the PR, Jason!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:21:16 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 18 Nov 2019 19:21:16 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574104876.74.0.469225025605.issue38722@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:32:08 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 19:32:08 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574105528.63.0.986826385828.issue38722@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I hadn't realized that we'd made such a declaration WRT opening of code files in general.

It wasn't exactly a hugely publicised declaration :)

The relevant quote from PEP 578 is:

> All import and execution functionality involving code from a file will be changed to use open_code() unconditionally.

Which I admit is a big claim, and one that was not completely followed through with before 3.8.0. Calling it a "security" fix is borderline, as it isn't really a vulnerability by default, but calling it incorrect behaviour (i.e. a regular bug) is fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:32:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 19:32:49 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574105569.94.0.763650891385.issue38622@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 00923c63995e34cdc25d699478f113de99a69df9 by Steve Dower in branch 'master':
bpo-38622: Add missing audit events for ctypes module (GH-17158)
https://github.com/python/cpython/commit/00923c63995e34cdc25d699478f113de99a69df9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:32:59 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 19:32:59 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574105579.61.0.884468855873.issue38622@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16741
pull_request: https://github.com/python/cpython/pull/17242

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:43:53 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 19:43:53 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574106233.95.0.76629109855.issue38622@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +16742
pull_request: https://github.com/python/cpython/pull/17243

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:47:25 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 19:47:25 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574106445.85.0.930891338405.issue38622@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Typically, as soon as I merge, I spot an edge case issue.

PySys_Audit(n, "O", a) is deliberately going to treat 'a' as the tuple of arguments (when it is a tuple). This lets us simplify/optimise events where the event arguments match the function arguments exactly. If 'a' is not a tuple, it gets wrapped in one.

When 'a' is meant to be a single argument that _might_ be a tuple, such as in PyObj_FromPtr, the format string needs to be "(O)" to ensure it is treated as a one element tuple. This is just how Py_BuildValue works - multiple elements become a tuple and the parens are optional unless you want a one-element tuple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 14:53:43 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 19:53:43 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574106823.26.0.299545206188.issue38622@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 47db7439dd858c3634212c71137eb130f811bda4 by Miss Islington (bot) in branch '3.8':
bpo-38622: Add missing audit events for ctypes module (GH-17158)
https://github.com/python/cpython/commit/47db7439dd858c3634212c71137eb130f811bda4


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 15:37:42 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Mon, 18 Nov 2019 20:37:42 +0000
Subject: [issue38721] modulefinder should use import hooks properly
In-Reply-To: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>
Message-ID: <1574109462.38.0.0239276443904.issue38721@roundup.psfhosted.org>


Dominic Littlewood <11dlittlewood at gmail.com> added the comment:

I now have a PR which - dare I say it - appears to be working as it should. I'll just write some tests for it and then I'll send it off for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Mon Nov 18 15:59:07 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Nov 2019 20:59:07 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574110747.72.0.101786758315.issue37228@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I agree that this is a bad default (and whoever wrote it, probably me, didn't know what this does for UDP).  I think the right solution is to change the default, not to introduce a new method.

Maybe we can deprecate the default somehow? There currently is a line the computes the default based on platform:

            if reuse_address is None:
                reuse_address = os.name == 'posix' and sys.platform != 'cygwin'


We could change this to issue a deprecation warning stating that in the future the default will change to False everywhere. Then in the next release we could change the default to False and remove the warning.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:15:10 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 18 Nov 2019 21:15:10 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574111710.17.0.786502122434.issue37228@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Ouch, that's nasty. It also has security implications. For example, suppose you have a multi-user computer, where one user is has a video call going, which transfers packets over UDP. Another user could check what port they're using, bind to the same port, and steal half the packets, letting them effectively listen in on the first user's phone call.

Well, hopefully most conferencing tools use end-to-end encryption. But the point is that we don't normally let unprivileged users steal network traffic intended for other users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:17:46 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Nov 2019 21:17:46 +0000
Subject: [issue38789] difflib lacks a way to check if results are empty
In-Reply-To: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>
Message-ID: <1574111866.26.0.708194560584.issue38789@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Simon, I think the conversation is starting to drift and would best be continued on python-ideas or StackOverflow.  Ideas like peekable generators have been discussed before but there was almost no uptake.

Several thoughts:

* For equal inputs, ndiff() is supposed to generate non-empty output.  It does not just give differences.

* To the extent that you care about empty results from some other iterator, the easiest thing to do is follow Tim's advice and just list() the iterator.

* The special case of equal inputs is easily handled before running the diff:

     if a == b:
         do_something_for_the_equal_case(a, b)
     else:
         d = ndiff(a, b)
         do_something_for_the_non_equal_case(a, b, d)

I recommend closing this issue because it hasn't elicted anything that is both actionable and desireable.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38789>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:29:41 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 21:29:41 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574112581.38.0.354304103186.issue38722@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16743
pull_request: https://github.com/python/cpython/pull/17244

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:30:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 21:30:05 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574112605.94.0.798446928104.issue38622@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset dcf1f83de8678b09df5bd7d04ca5f4ef1cd02aca by Steve Dower in branch 'master':
bpo-38622: Ensure ctypes.PyObj_FromPtr audit event passes tuples as a single argument (GH-17243)
https://github.com/python/cpython/commit/dcf1f83de8678b09df5bd7d04ca5f4ef1cd02aca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:30:14 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 21:30:14 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574112614.94.0.447202799556.issue38622@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16744
pull_request: https://github.com/python/cpython/pull/17245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:40:50 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 18 Nov 2019 21:40:50 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574113250.39.0.500827793995.issue22367@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: this is affecting the release of Python 3.9.0a1.  I will be continuing with the release in 12 hours.  If the failing macOS test is not fixed by then, alpha1 will ship in this state.

However, I will be blocking alpha2 if this is still the case.

Please prioritize fixing this.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:43:47 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Nov 2019 21:43:47 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1574113427.95.0.661544736766.issue25172@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

test_crypt fails on android following last changes made at 243a73deee4ac61fe06602b7ed56b6df01e19f27.
The android libc does not have a crypt() function and the _crypt module is not built.


generic_x86_64:/data/local/tmp/python $ python
Python 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26)
[Clang 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec7462 on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import crypt
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/crypt.py", line 6, in <module>
    import _crypt
ModuleNotFoundError: No module named '_crypt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/data/local/tmp/python/lib/python3.9/crypt.py", line 11, in <module>
    raise ImportError("The required _crypt module was not built as part of CPython")
ImportError: The required _crypt module was not built as part of CPython
>>>


generic_x86_64:/data/local/tmp/python $ python -m test -v test_crypt
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://andro
id.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_3523
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_crypt
test_blowfish_rounds (test.test_crypt.CryptTestCase) ... skipped 'Not supported on Windows'
test_crypt (test.test_crypt.CryptTestCase) ... skipped 'Not supported on Windows'
test_invalid_rounds (test.test_crypt.CryptTestCase) ... skipped 'Not supported on Windows'
test_methods (test.test_crypt.CryptTestCase) ... skipped 'Not supported on Windows'
test_salt (test.test_crypt.CryptTestCase) ... skipped 'Not supported on Windows'
test_saltedcrypt (test.test_crypt.CryptTestCase) ... skipped 'Not supported on Windows'
test_sha2_rounds (test.test_crypt.CryptTestCase) ... skipped 'Not supported on Windows'
test_failure_only_for_windows (test.test_crypt.TestWhyCryptDidNotImport) ... FAIL
test_import_failure_message (test.test_crypt.TestWhyCryptDidNotImport) ... FAIL

======================================================================
FAIL: test_failure_only_for_windows (test.test_crypt.TestWhyCryptDidNotImport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_crypt.py", line 16, in test_failure_only_for_
windows
    self.assertEqual(sys.platform, 'win32')
AssertionError: 'linux' != 'win32'
- linux
+ win32

======================================================================
FAIL: test_import_failure_message (test.test_crypt.TestWhyCryptDidNotImport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_crypt.py", line 19, in test_import_failure_message
    self.assertIn('not supported', IMPORT_ERROR)
AssertionError: 'not supported' not found in 'The required _crypt module was not built as part of CPython'

----------------------------------------------------------------------

Ran 9 tests in 0.008s

FAILED (failures=2, skipped=7)
test test_crypt failed
test_crypt failed

== Tests result: FAILURE ==

1 test failed:
    test_crypt

Total duration: 165 ms
Tests result: FAILURE

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:53:30 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 18 Nov 2019 21:53:30 +0000
Subject: [issue38822] Inconsistent os.stat behavior for directory with Access
 Denied
In-Reply-To: <1573928094.88.0.209131085868.issue38822@roundup.psfhosted.org>
Message-ID: <1574114010.51.0.850493288264.issue38822@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

In attributes_from_dir() in Modules/posixmodule.c, a trailing backslash or slash should be stripped from the lpFileName parameter of FindFirstFileW. Otherwise the call opens the directory via NtOpenFile, instead of opening its parent directory. Even if opening the directory is successful, which we don't expect in this case, FindFirstFileW forcibly fails the call with ERROR_FILE_NOT_FOUND (2) because it expects a filename filter (e.g. "*") for the internal NtQueryDirectoryFile[Ex] system call.

Care needs to be taken to not strip the trailing slash of the root directory of a DOS drive because that creates a drive-relative path (e.g. "C:"). It is expected that FindFirstFileW will fail for the root of a DOS drive or UNC share, since there's no parent directory to open.

----

"System Volume Information" explicitly grants access only to the SYSTEM account. Implicitly we have read-attributes access to this directory because we have read-data (i.e. list-directory) access to the root directory. Great, but even for 0 desired access, CreateFileW requests both read-attributes and synchronize access, even for overlapped I/O (i.e. kernel File objects created by CreateFileW can always be waited on). So even an elevated administrator normally can't open this directory to query information. However, backup and restore privileges are in effect when an open requests backup semantics, which we already do. We could extend os.stat to temporarily enable SeBackupPrivilege if the caller has it. 

It's also possible to open the directory with a native NtOpenFile or NtCreateFile system call, without the FILE_SYNCHRONOUS_IO_NONALERT option and without requesting SYNCHRONIZE access -- i.e. the File object will be asynchronous and not waitable.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38822>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:58:06 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 21:58:06 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574114286.54.0.422805815265.issue38722@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e37767bee1f7f1940b30768d21bfe2ae68c20a5f by Miss Islington (bot) in branch '3.8':
bpo-38722: Runpy use io.open_code() (GH-17234)
https://github.com/python/cpython/commit/e37767bee1f7f1940b30768d21bfe2ae68c20a5f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Mon Nov 18 16:59:55 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Nov 2019 21:59:55 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574114395.1.0.134102782325.issue38622@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bec7015dcc421a68cde030c5e4ca8e28408ef52d by Miss Islington (bot) in branch '3.8':
bpo-38622: Ensure ctypes.PyObj_FromPtr audit event passes tuples as a single argument (GH-17243)
https://github.com/python/cpython/commit/bec7015dcc421a68cde030c5e4ca8e28408ef52d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:03:04 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Nov 2019 22:03:04 +0000
Subject: [issue38622] _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
In-Reply-To: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>
Message-ID: <1574114584.54.0.94726474647.issue38622@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38622>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:03:20 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 18 Nov 2019 22:03:20 +0000
Subject: [issue22229] wsgiref doesn't appear to ever set REMOTE_HOST in the
 environ
In-Reply-To: <1408469645.6.0.0733162760485.issue22229@psf.upfronthosting.co.za>
Message-ID: <1574114600.38.0.340369807078.issue22229@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I didn't understand the issue. WSGIRequestHandler can be subclassed and address_string method may return something else.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22229>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:08:25 2019
From: report at bugs.python.org (Adam Johnson)
Date: Mon, 18 Nov 2019 22:08:25 +0000
Subject: [issue38839] Some unused functions in test suite
Message-ID: <1574114905.54.0.915715674815.issue38839@roundup.psfhosted.org>


New submission from Adam Johnson <me at adamj.eu>:

Whilst developing a new unused function check for flake8 ( https://github.com/PyCQA/pyflakes/pull/485 ) I ran it against the CPython source code and found some uncalled functions.

----------
messages: 356919
nosy: adamchainz
priority: normal
pull_requests: 16745
severity: normal
status: open
title: Some unused functions in test suite
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38839>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:11:12 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Mon, 18 Nov 2019 22:11:12 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1574115072.96.0.807101518569.issue35943@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

Do we plan to backport the change by nanjekyejoannah to 3.7 branch?

----------
nosy: +Valentyn Tymofieiev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:16:16 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 18 Nov 2019 22:16:16 +0000
Subject: [issue32371] Delay-loading of python dll is impossible when using
 some C macros
In-Reply-To: <1513689198.93.0.213398074469.issue32371@psf.upfronthosting.co.za>
Message-ID: <1574115376.76.0.00935023589666.issue32371@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Can you give us a case where we can reproduce this locally?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32371>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:18:22 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Nov 2019 22:18:22 +0000
Subject: [issue38840] incorrect __all__ list in multiprocessing.managers module
Message-ID: <1574115502.48.0.329816372934.issue38840@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

On android which is a platform that is missing the shared memory implementation, test___all__ fails because 'multiprocessing.managers' has no attribute 'SharedMemoryManager' which is listed in __all__.


2|generic_x86_64:/data/local/tmp/python $ python
Python 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) 
[Clang 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec7462 on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing.shared_memory
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/shared_memory.py", line 22, in <module>
    import _posixshmem
ModuleNotFoundError: No module named '_posixshmem'
>>> 


2|generic_x86_64:/data/local/tmp/python $ python -m test test___all__
0:00:00 Run tests sequentially
0:00:00 [1/1] test___all__
test test___all__ failed -- Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test___all__.py", line 38, in check_all
    exec("from %s import *" % modname, names)
AttributeError: module 'multiprocessing.managers' has no attribute 'SharedMemoryManager'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test___all__.py", line 41, in check_all
    self.fail("__all__ failure in {}: {}: {}".format(
AssertionError: __all__ failure in multiprocessing.managers: AttributeError: module 'multiprocessing.managers' has no attribute 'SharedMemoryManager'

test___all__ failed

== Tests result: FAILURE ==

1 test failed:
    test___all__

Total duration: 1.8 sec
Tests result: FAILURE

----------
components: Library (Lib)
messages: 356922
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: incorrect __all__ list in multiprocessing.managers module
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38840>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:33:46 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 18 Nov 2019 22:33:46 +0000
Subject: [issue22593] Automate update of doc references to UCD version when it
 changes.
In-Reply-To: <1412903498.5.0.872125887702.issue22593@psf.upfronthosting.co.za>
Message-ID: <1574116426.35.0.28213494079.issue22593@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I want to work on this. What do you think about using include directive and include a static file like UCD_VERSION.txt in the documents?

makeunicodedata.py can write the current version every run to UCD_VERSION.txt

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22593>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:36:11 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Nov 2019 22:36:11 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
Message-ID: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

This is the same kind of issue as reported in #28684.


python -m test -v test_asyncio -m test_create_datagram_endpoint_existing_sock_unix
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://andro
id.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_6046
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
test_create_datagram_endpoint_existing_sock_unix (test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests) ... ERROR
/data/local/tmp/python/lib/python3.9/unittest/case.py:687: ResourceWarning: unclosed <socket.socket
fd=7, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_DGRAM, proto=0>
  outcome.errors.clear()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
======================================================================
ERROR: test_create_datagram_endpoint_existing_sock_unix (test.test_asyncio.test_base_events.BaseEven
tLoopWithSelectorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_asyncio/test_base_events.py", line 1707, in t
est_create_datagram_endpoint_existing_sock_unix
    sock.bind(path)
PermissionError: [Errno 13] Permission denied

----------------------------------------------------------------------

Ran 1 test in 0.014s

FAILED (errors=1)
test test_asyncio failed
test_asyncio failed

== Tests result: FAILURE ==

1 test failed:
    test_asyncio

Total duration: 542 ms
Tests result: FAILURE

----------
components: asyncio
messages: 356924
nosy: asvetlov, xdegaye, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:41:31 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 18 Nov 2019 22:41:31 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1574116891.67.0.408284222658.issue36287@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@eamanu are you still interested in this issue? (bumped to 3.9)

----------
nosy: +BTaskaya
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:44:33 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 18 Nov 2019 22:44:33 +0000
Subject: [issue31521] segfault in PyBytes_AsString
In-Reply-To: <1505845145.85.0.99143388289.issue31521@psf.upfronthosting.co.za>
Message-ID: <1574117073.59.0.764362616313.issue31521@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Is there a simpler code for reproducing the issue?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31521>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:59:17 2019
From: report at bugs.python.org (David Cuthbert)
Date: Mon, 18 Nov 2019 22:59:17 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574117957.25.0.938993365547.issue37228@roundup.psfhosted.org>


David Cuthbert <dacut at kanga.org> added the comment:

How much harm would there be in bringing the DeprecationWarning into the next patch of existing (3.6, 3.7, 3.8) releases? The security implications are significant enough that I'd want to be notified of it in my software ASAP.

Users can (and should!) squelch the warning by passing the setting explicitly.

----------
nosy: +dacut

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Nov 18 17:59:34 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 18 Nov 2019 22:59:34 +0000
Subject: [issue19080] Enrich SyntaxError with additional information
In-Reply-To: <1379968925.72.0.669299760684.issue19080@psf.upfronthosting.co.za>
Message-ID: <1574117974.16.0.101369618647.issue19080@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I am not sure about how to implement this to the core, but you can combine tokenize with ast to reproduce this kind of messages in your projects. You can match tokens with SyntaxErrors by lineno and offset.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19080>
_______________________________________

From report at bugs.python.org  Mon Nov 18 18:04:34 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 18 Nov 2019 23:04:34 +0000
Subject: [issue27724] PEP3119 inconsintent with actual CPython impl
In-Reply-To: <1470817080.1.0.906916235476.issue27724@psf.upfronthosting.co.za>
Message-ID: <1574118274.72.0.926368120681.issue27724@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya, gvanrossum
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27724>
_______________________________________

From report at bugs.python.org  Mon Nov 18 18:39:53 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Nov 2019 23:39:53 +0000
Subject: [issue38842] test_multiprocessing_spawn altered the execution
 environment in AMD64 FreeBSD Non-Debug 3.x
Message-ID: <1574120393.33.0.271928086665.issue38842@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Ran 352 tests in 243.972s
OK (skipped=34)
/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/multiprocessing/resource_tracker.py:203: UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown
? warnings.warn('resource_tracker: There appear to be %d '
/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: '/psm_5b8ca94b': [Errno 2] No such file or directory: '/psm_5b8ca94b'
? warnings.warn('resource_tracker: %r: %s' % (name, e))


1 test altered the execution environment:
? ? test_multiprocessing_spawn

It seems that the shared memory leaked is causing the test to fail.?

----------
components: Tests
messages: 356929
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn altered the execution environment in AMD64 FreeBSD Non-Debug 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38842>
_______________________________________

From report at bugs.python.org  Mon Nov 18 18:40:27 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Nov 2019 23:40:27 +0000
Subject: [issue38842] test_multiprocessing_spawn altered the execution
 environment in AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1574120393.33.0.271928086665.issue38842@roundup.psfhosted.org>
Message-ID: <1574120427.14.0.99058393284.issue38842@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

https://buildbot.python.org/all/#builders/368/builds/98

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38842>
_______________________________________

From report at bugs.python.org  Mon Nov 18 18:41:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Nov 2019 23:41:20 +0000
Subject: [issue38842] test_multiprocessing_spawn altered the execution
 environment in AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1574120393.33.0.271928086665.issue38842@roundup.psfhosted.org>
Message-ID: <1574120480.54.0.611014067441.issue38842@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Another failure that seems related:

https://buildbot.python.org/all/#/builders/279/builds/136


Ran 168 tests in 154.704s
OK (skipped=3)
Warning -- multiprocessing.process._dangling was modified by test_concurrent_futures
  Before: set()
  After:  {<weakref at 0x7f48459bffb0; to 'SpawnProcess' at 0x7f48459baf00>}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38842>
_______________________________________

From report at bugs.python.org  Mon Nov 18 18:42:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Nov 2019 23:42:24 +0000
Subject: [issue38842] test_multiprocessing_spawn altered the execution
 environment in AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1574120393.33.0.271928086665.issue38842@roundup.psfhosted.org>
Message-ID: <1574120544.19.0.18269867195.issue38842@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The last test may have a different explanation, though

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38842>
_______________________________________

From report at bugs.python.org  Mon Nov 18 18:43:14 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Nov 2019 23:43:14 +0000
Subject: [issue37083] Document TYPE_COMMENT in documentation reference for
 compound statements
In-Reply-To: <1559079468.64.0.0790187408059.issue37083@roundup.psfhosted.org>
Message-ID: <1574120594.34.0.251673412725.issue37083@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am convinced by Guido's reasoning, I think we can close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37083>
_______________________________________

From report at bugs.python.org  Mon Nov 18 18:43:40 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Nov 2019 23:43:40 +0000
Subject: [issue38446] Ambiguous signature for builtins.__build_class__
In-Reply-To: <1570793351.47.0.198943437011.issue38446@roundup.psfhosted.org>
Message-ID: <1574120620.45.0.20012653624.issue38446@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>  @pablogsal can we close it?

Yup, thanks for the ping, Batuhan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38446>
_______________________________________

From report at bugs.python.org  Mon Nov 18 19:10:29 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 19 Nov 2019 00:10:29 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1574122229.73.0.517809764.issue36287@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi, 

Sorry sincerely I forgot this issue, if there are not any objection I can continue it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Mon Nov 18 19:31:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Nov 2019 00:31:06 +0000
Subject: [issue34792] Tutorial doesn''t discuss / and * function arguments
In-Reply-To: <1537811932.84.0.956365154283.issue34792@psf.upfronthosting.co.za>
Message-ID: <1574123466.75.0.080927662217.issue34792@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I don't think we should backport the changes or modify the file for the 3.7 branch, so I close the issue. Feel free to reopen if you still think it makes sense :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34792>
_______________________________________

From report at bugs.python.org  Mon Nov 18 19:32:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Nov 2019 00:32:24 +0000
Subject: [issue37195] test_utime fails on MacOS Mojave (Kernel Version 18.6.0:)
In-Reply-To: <1559912694.09.0.24854010798.issue37195@roundup.psfhosted.org>
Message-ID: <1574123544.82.0.186432549249.issue37195@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have not noticed it in a while, so I will close it for now unless I can reproduce it again.

----------
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37195>
_______________________________________

From report at bugs.python.org  Mon Nov 18 20:04:24 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 19 Nov 2019 01:04:24 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574125464.7.0.46440462637.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Steve approved this PR 17154 but we need one more reviewer to review this PR.
I hope we can reflect PR 17154 before alpha1 is released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Mon Nov 18 21:23:43 2019
From: report at bugs.python.org (Ivan Kurnosov)
Date: Tue, 19 Nov 2019 02:23:43 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
Message-ID: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>


New submission from Ivan Kurnosov <zerkms at zerkms.com>:

At this moment it's impossible to explain the behaviour of this script using documentation.

Given it was explicitly coded to behave like that - it should be somehow noted in the documentation, that as long as a `CliArgs.foo` field has a default value set already - it won't be overwritten with a default argparse argument value.


```
import argparse

class CliArgs(object):
    foo: str = 'not touched'


parser = argparse.ArgumentParser()
parser.add_argument('--foo', default='bar')

args = CliArgs()
parser.parse_args(namespace=args)
print(args.foo) # 'not touched'

print(parser.parse_args()) # 'bar'
```

----------
assignee: docs at python
components: Documentation
messages: 356939
nosy: docs at python, zerkms
priority: normal
severity: normal
status: open
title: Document argparse behaviour when custom namespace object already has the field set

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38843>
_______________________________________

From report at bugs.python.org  Mon Nov 18 21:46:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Nov 2019 02:46:19 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1574131579.18.0.803837040695.issue38843@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38843>
_______________________________________

From report at bugs.python.org  Mon Nov 18 21:47:28 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 19 Nov 2019 02:47:28 +0000
Subject: [issue38844] test_multiprocessing_fork emit user warning
Message-ID: <1574131648.5.0.417316133388.issue38844@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

https://travis-ci.org/python/cpython/jobs/613795145#L2020

Log detail:
0:01:44 load avg: 3.38 [ 73/419] test_multiprocessing_fork passed (1 min 42 sec) -- running: test_capi (1 min 40 sec)
/home/travis/build/python/cpython/Lib/multiprocessing/resource_tracker.py:203: UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/home/travis/build/python/cpython/Lib/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: '/psm_83d846d5': [Errno 2] No such file or directory: '/psm_83d846d5'

----------
components: Tests
messages: 356940
nosy: corona10
priority: normal
severity: normal
status: open
title: test_multiprocessing_fork emit user warning
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38844>
_______________________________________

From report at bugs.python.org  Mon Nov 18 21:54:29 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 19 Nov 2019 02:54:29 +0000
Subject: [issue38844] test_multiprocessing_fork emit user warning
In-Reply-To: <1574131648.5.0.417316133388.issue38844@roundup.psfhosted.org>
Message-ID: <1574132069.09.0.192032221169.issue38844@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Duplicated with issue38842

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38844>
_______________________________________

From report at bugs.python.org  Mon Nov 18 22:33:21 2019
From: report at bugs.python.org (Tim Peters)
Date: Tue, 19 Nov 2019 03:33:21 +0000
Subject: [issue38789] difflib lacks a way to check if results are empty
In-Reply-To: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>
Message-ID: <1574134401.93.0.721210869928.issue38789@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'm taking Raymond's advice to close this for now.  The issue tracker isn't the right place to work out ideas - python-ideas is far better for that (StackOverflow isn't a good place for that either - StackOverflow is best for when you have a very specific use case and get stuck).

While the issues with generators are common to all generators, in the context of difflib something else Raymond said should be taken to heart:  using any difflib facility is an extremely expensive way to find out that two things are equal.  That's a value of use cases!  That is, if you had asked about this on StackOverflow and asked for help instead of proposing "a (vague) solution", they would have told you at once to check whether `a == b` before dragging difflib into it.

Indeed, that's probably why what you're asking about never came up before.  People generally use difflib only when they know in advance (via a cheap equality test) that there _are_ differences to be found.

In any case, if a "specific & actionable" suggestion comes out of pursuing this, feel encouraged to open this report again!

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38789>
_______________________________________

From report at bugs.python.org  Mon Nov 18 23:34:59 2019
From: report at bugs.python.org (paul j3)
Date: Tue, 19 Nov 2019 04:34:59 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1574138099.68.0.0906992799388.issue38843@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

It doesn't have to be a special class. It can be a `argparse.Namespace` object.  If the preexisting namespace has an attribute set, the action default will not over write it.

    In [85]: parser = argparse.ArgumentParser() 
        ...: parser.add_argument('--foo', default='bar') 
        ...: parser.parse_args([],
                 namespace=argparse.Namespace(foo=123, baz=132))   
    Out[85]: Namespace(baz=132, foo=123)

This is described in comments at the start of parse_known_args()

        ....
        # add any action defaults that aren't present
        for action in self._actions:
            if action.dest is not SUPPRESS:
                if not hasattr(namespace, action.dest):
                    if action.default is not SUPPRESS:
                        setattr(namespace, action.dest, action.default)

        # add any parser defaults that aren't present
        for dest in self._defaults:
            if not hasattr(namespace, dest):
                setattr(namespace, dest, self._defaults[dest])

There are many details about 'defaults' that are not documented.  This might not be the most significant omission.  

I have not seen many questions about the use of a preexisting namespace object (here or on StackOverflow).  While such a namespace can be used to set custom defaults (as shown here), I think it is more useful when using a custom Namespace class, one the defines special behavior.

Originally the main parser's namespace was passed to subparsers.  But a change in 2014, gave the subparser a fresh namespace, and then copied values from it back to the main namespace.  While that gave more power to the subparser's defaults, users lost some ability to use their own namespace class.

https://bugs.python.org/issue27859 - argparse - subparsers does not retain namespace

https://bugs.python.org/issue9351 - argparse set_defaults on subcommands should override top level set_defaults

https://bugs.python.org/issue34827 - Make argparse.NameSpace iterable (closed)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38843>
_______________________________________

From report at bugs.python.org  Tue Nov 19 00:34:10 2019
From: report at bugs.python.org (Ivan Kurnosov)
Date: Tue, 19 Nov 2019 05:34:10 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1574141650.55.0.550078202957.issue38843@roundup.psfhosted.org>


Ivan Kurnosov <zerkms at zerkms.com> added the comment:

> I have not seen many questions about the use of a preexisting namespace object (here or on StackOverflow)

as typing was added to the language natively - it should become more and more frequently used.

I personally see no reason anymore to NOT use a custom namespace: typed arguments object is x100 times better than untyped one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38843>
_______________________________________

From report at bugs.python.org  Tue Nov 19 00:54:16 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 05:54:16 +0000
Subject: [issue38807] Better exception message in os.path.join
In-Reply-To: <1573779750.02.0.708670809394.issue38807@roundup.psfhosted.org>
Message-ID: <1574142856.14.0.775947170113.issue38807@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16746
pull_request: https://github.com/python/cpython/pull/17249

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38807>
_______________________________________

From report at bugs.python.org  Tue Nov 19 00:54:31 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Nov 2019 05:54:31 +0000
Subject: [issue38807] Better exception message in os.path.join
In-Reply-To: <1573779750.02.0.708670809394.issue38807@roundup.psfhosted.org>
Message-ID: <1574142871.18.0.615570995674.issue38807@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset fe75b62575bcfdf1c39be71c1e50257832a596db by Raymond Hettinger (Tom?s Far?as) in branch 'master':
bpo-38807: Add os.PathLike to exception message raised by _check_arg_types (#17160)
https://github.com/python/cpython/commit/fe75b62575bcfdf1c39be71c1e50257832a596db


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38807>
_______________________________________

From report at bugs.python.org  Tue Nov 19 00:54:55 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Nov 2019 05:54:55 +0000
Subject: [issue38807] Better exception message in os.path.join
In-Reply-To: <1573779750.02.0.708670809394.issue38807@roundup.psfhosted.org>
Message-ID: <1574142895.72.0.670104949425.issue38807@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the report and for the PR.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38807>
_______________________________________

From report at bugs.python.org  Tue Nov 19 01:46:19 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Nov 2019 06:46:19 +0000
Subject: [issue38807] Better exception message in os.path.join
In-Reply-To: <1573779750.02.0.708670809394.issue38807@roundup.psfhosted.org>
Message-ID: <1574145979.44.0.775951504214.issue38807@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset b5bb3b637c6b55f49d8979a5f489d01a67c4f917 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-38807: Add os.PathLike to exception message raised by _check_arg_types (GH-17160) (GH-17249)
https://github.com/python/cpython/commit/b5bb3b637c6b55f49d8979a5f489d01a67c4f917


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38807>
_______________________________________

From report at bugs.python.org  Tue Nov 19 02:02:18 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 19 Nov 2019 07:02:18 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574146938.83.0.31906671312.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16747
pull_request: https://github.com/python/cpython/pull/17250

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 02:34:10 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Nov 2019 07:34:10 +0000
Subject: [issue38837] struct.pack: Unable to pack more than 256 bytes at a time
In-Reply-To: <1574097291.45.0.986281483128.issue38837@roundup.psfhosted.org>
Message-ID: <1574148850.31.0.6809100774.issue38837@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The error you're getting is because you're trying to pack a *value* that's larger than 255, not because you're trying to pack more than 256 bytes. Packing more than 256 bytes at a time works fine for me.

>>> packed = struct.pack("<512B", *[n//2 for n in range(512)])  # fine
>>> packed = struct.pack("2B", *[255, 256])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: ubyte format requires 0 <= number <= 255

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38837>
_______________________________________

From report at bugs.python.org  Tue Nov 19 02:50:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 07:50:36 +0000
Subject: [issue38842] test_multiprocessing_spawn altered the execution
 environment in AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1574120393.33.0.271928086665.issue38842@roundup.psfhosted.org>
Message-ID: <1574149836.42.0.898104420599.issue38842@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The build was marked as failed because of this warning:

https://buildbot.python.org/all/#/builders/368/builds/98

...
test_rlock (test.test_multiprocessing_spawn.WithProcessesTestLock) ... ok
test_enable_logging (test.test_multiprocessing_spawn.WithProcessesTestLogging) ... ok
test_level (test.test_multiprocessing_spawn.WithProcessesTestLogging) ... ok
test_rapid_restart (test.test_multiprocessing_spawn.WithProcessesTestManagerRestart) ... ok
Warning -- Dangling processes: {<SpawnProcess name='QueueManager-212' pid=13560 parent=12641 stopped exitcode=-SIGTERM>}

This warning is tracked as bpo-38447.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38842>
_______________________________________

From report at bugs.python.org  Tue Nov 19 02:52:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 07:52:49 +0000
Subject: [issue38842] test_multiprocessing_spawn altered the execution
 environment in AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1574120393.33.0.271928086665.issue38842@roundup.psfhosted.org>
Message-ID: <1574149969.07.0.340564326255.issue38842@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 RHEL7 3.8 was marked as failed because of:
https://buildbot.python.org/all/#/builders/279/builds/136

test_max_workers_too_large (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... skipped 'Windows-only process limit'
test_no_stale_references (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.57s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.78s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.42s
Warning -- reap_children() reaped child process 11860
ok

The test_concurrent_futures reap_children() issue is tracked as bpo-38546.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38842>
_______________________________________

From report at bugs.python.org  Tue Nov 19 02:53:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 07:53:38 +0000
Subject: [issue38842] test_multiprocessing_spawn altered the execution
 environment in AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1574120393.33.0.271928086665.issue38842@roundup.psfhosted.org>
Message-ID: <1574150018.0.0.935494836837.issue38842@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Pablo: Feel free to close this issue as duplicate, or leave it open to track the original "resource_tracker" warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38842>
_______________________________________

From report at bugs.python.org  Tue Nov 19 03:12:49 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 19 Nov 2019 08:12:49 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574151169.63.0.594699133482.issue22367@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 9960230f76eb555d6dfbe8a324efed35610c85f9 by ?ukasz Langa (Dong-hee Na) in branch 'master':
bpo-22367: Update test_fcntl.py for spawn process mode (#17154)
https://github.com/python/cpython/commit/9960230f76eb555d6dfbe8a324efed35610c85f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Tue Nov 19 03:13:10 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 08:13:10 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574151190.83.0.109395695962.issue22367@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16748
pull_request: https://github.com/python/cpython/pull/17252

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Tue Nov 19 03:13:22 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 08:13:22 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574151202.15.0.546981402524.issue22367@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16749
pull_request: https://github.com/python/cpython/pull/17253

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Tue Nov 19 03:16:50 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 19 Nov 2019 08:16:50 +0000
Subject: [issue21767] singledispatch docs should explicitly mention support
 for abstract base classes
In-Reply-To: <1402804826.39.0.801339966603.issue21767@psf.upfronthosting.co.za>
Message-ID: <1574151410.86.0.701073079748.issue21767@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 24555ce2f969bd69517011d23aaf8cc481090211 by ?ukasz Langa (Batuhan Ta?kaya) in branch 'master':
bpo-21767: explicitly mention abc support in functools.singledispatch docs (#17171)
https://github.com/python/cpython/commit/24555ce2f969bd69517011d23aaf8cc481090211


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21767>
_______________________________________

From report at bugs.python.org  Tue Nov 19 03:17:31 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 19 Nov 2019 08:17:31 +0000
Subject: [issue21767] singledispatch docs should explicitly mention support
 for abstract base classes
In-Reply-To: <1402804826.39.0.801339966603.issue21767@psf.upfronthosting.co.za>
Message-ID: <1574151451.56.0.083967414488.issue21767@roundup.psfhosted.org>


Change by ?ukasz Langa <lukasz at langa.pl>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21767>
_______________________________________

From report at bugs.python.org  Tue Nov 19 03:32:41 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 19 Nov 2019 08:32:41 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574152361.37.0.407729929457.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

https://dev.azure.com/python/cpython/_build/results?buildId=54136&view=results

Looks okay at this time.
It was nerve-racking, I worried about my mistake affect publishing Python 3.9.0 alpha1.

Thank you everyone who helps me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Tue Nov 19 03:33:01 2019
From: report at bugs.python.org (Tal Einat)
Date: Tue, 19 Nov 2019 08:33:01 +0000
Subject: [issue38722] runpy should use io.open_code() instead of open()
In-Reply-To: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>
Message-ID: <1574152381.32.0.986443393148.issue38722@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thanks for the clarification Steve! I've backported this to 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38722>
_______________________________________

From report at bugs.python.org  Tue Nov 19 04:07:41 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Tue, 19 Nov 2019 09:07:41 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574154461.49.0.306070160446.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

I had a quick search through github for calls to create_datagram_endpoint() and the reuse_address is either not set or set explicitly to True, probably due to the error in the documentation.

Only in one case (of my admittedly small sample) did it seem like the parameter was set to True intentionally to get the behavior of binding multiple processes to the same port.

Due to the nature of the function, it is also often buried inside packages implementing higher level protocols (SIP, STUN, DNS, RTP) which want to create a convenience function to create asyncio servers and clients.

The deprecation warning and getting it into 3.6 and later sounds very reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Tue Nov 19 04:27:15 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Nov 2019 09:27:15 +0000
Subject: [issue36424] Pickle fails on frozen dataclass that has slots
In-Reply-To: <1553527088.82.0.636469633332.issue36424@roundup.psfhosted.org>
Message-ID: <1574155635.44.0.325206287693.issue36424@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36424>
_______________________________________

From report at bugs.python.org  Tue Nov 19 04:39:13 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 19 Nov 2019 09:39:13 +0000
Subject: [issue36424] Pickle fails on frozen dataclass that has slots
In-Reply-To: <1553527088.82.0.636469633332.issue36424@roundup.psfhosted.org>
Message-ID: <1574156353.74.0.868758571164.issue36424@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36424>
_______________________________________

From report at bugs.python.org  Tue Nov 19 04:50:19 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 19 Nov 2019 09:50:19 +0000
Subject: [issue38032] lib2to3 doesn't parse Python 3 identifiers containing
 non-spacing marks
In-Reply-To: <1567639302.72.0.55214965787.issue38032@roundup.psfhosted.org>
Message-ID: <1574157019.78.0.905702596517.issue38032@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Is there a consensus about fixing this? By the way, this isn't valid in the current tokenizer too. 
1,0-1,2:            NAME           'i?'
1,2-1,3:            ERRORTOKEN     '?'
1,4-1,5:            OP             '='
1,6-1,7:            NUMBER         '5'
1,7-1,8:            NEWLINE        '\n'

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38032>
_______________________________________

From report at bugs.python.org  Tue Nov 19 05:01:52 2019
From: report at bugs.python.org (Pierre Chatelier)
Date: Tue, 19 Nov 2019 10:01:52 +0000
Subject: [issue32371] Delay-loading of python dll is impossible when using
 some C macros
In-Reply-To: <1513689198.93.0.213398074469.issue32371@psf.upfronthosting.co.za>
Message-ID: <1574157712.57.0.00310509028241.issue32371@roundup.psfhosted.org>


Pierre Chatelier <pierre at chachatelier.fr> added the comment:

Can't reproduce any more.
It might have been specific to the Visual Studio version I used at that time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32371>
_______________________________________

From report at bugs.python.org  Tue Nov 19 05:21:15 2019
From: report at bugs.python.org (tlecarrour)
Date: Tue, 19 Nov 2019 10:21:15 +0000
Subject: [issue38845] test_shared_memory_SharedMemoryServer_ignores_sigint and
 others fail on Guix
Message-ID: <1574158875.47.0.121932090087.issue38845@roundup.psfhosted.org>


New submission from tlecarrour <tanguy at bioneland.org>:

Dear Python Bugs Team,

Some tests fail when building Python 3.8 on Guix, for instance?:

```
FAIL: test_shared_memory_SharedMemoryServer_ignores_sigint (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/guix-build-python-3.8.0.drv-0/Python-3.8.0/Lib/test/_test_multiprocessing.py", line 3824, in test_shared_memory_SharedMemoryServer_ignores_sigint
    os.kill(os.getpid(), signal.SIGINT)
AssertionError: KeyboardInterrupt not raised
```

This is because, on Guix, there is no TTY available during the build process.
A patch (cf attachment) has been added to the package definition [1], but it would make sense to have it integrated in Python.

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38208#14

It adds the following decorator to the failing tests:

```
@unittest.skipUnless(sys.stdin.isatty(), "KeyboardInterrupts require a TTY device")
```

Regards

----------
components: Tests
files: python-3.8-fix-tests.patch
keywords: patch
messages: 356959
nosy: tlecarrour
priority: normal
severity: normal
status: open
title: test_shared_memory_SharedMemoryServer_ignores_sigint and others fail on Guix
versions: Python 3.8
Added file: https://bugs.python.org/file48720/python-3.8-fix-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38845>
_______________________________________

From report at bugs.python.org  Tue Nov 19 05:48:27 2019
From: report at bugs.python.org (Alex)
Date: Tue, 19 Nov 2019 10:48:27 +0000
Subject: [issue38828] http.cookiejar handle cookie.version to be None
In-Reply-To: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>
Message-ID: <1574160507.94.0.921461968266.issue38828@roundup.psfhosted.org>


Alex <alexpclarkson at gmail.com> added the comment:

Hi, it looks like this needs a fix - I'll write a patch to fix up the handling and add some more testing to cover this scenario.

----------
nosy: +alclarks

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38828>
_______________________________________

From report at bugs.python.org  Tue Nov 19 05:54:58 2019
From: report at bugs.python.org (Damien LEFEVRE)
Date: Tue, 19 Nov 2019 10:54:58 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
In-Reply-To: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>
Message-ID: <1574160898.03.0.715686381731.issue38680@roundup.psfhosted.org>


Damien LEFEVRE <lefevre.da at gmail.com> added the comment:

Back to testing this.

I have the same issue on Linux, i.e: the deadlock on PyGILState_Ensure.

I cannot test 3.8 because many of the modules are not yet available for this version.

I'll try making a small test application to reproduce the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Tue Nov 19 06:54:28 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Tue, 19 Nov 2019 11:54:28 +0000
Subject: [issue38846] async: Return context manager from open(_unix)_connection
Message-ID: <1574164468.11.0.934598090921.issue38846@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

As a convenience it would be useful if async.open_connection() and open_unix_connection() would return a context manager that closes the writer on exit:

    with await open_unix_connection(...) as (reader, writer):
        ...

This could be achieved by using a custom sub-class of tuple:

    class _ConnectionContext(tuple):
        def __enter__(self):
            return self
        def __exit__(self, *args):
            self[1].close()

I can submit a PR if wanted.

----------
components: asyncio
messages: 356962
nosy: asvetlov, srittau, yselivanov
priority: normal
severity: normal
status: open
title: async: Return context manager from open(_unix)_connection
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38846>
_______________________________________

From report at bugs.python.org  Tue Nov 19 07:03:41 2019
From: report at bugs.python.org (Fabio Zadrozny)
Date: Tue, 19 Nov 2019 12:03:41 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574165021.04.0.300997732752.issue38500@roundup.psfhosted.org>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

@Mark @Brett

Well, PEP 523 still works (it's just more inconvenient to use now).

Still, if PEP 523 will still be supported I think that having the setter/getter makes sense.

If it is to be deprecated as @Mark is suggesting it doesn't really make sense to add it (but then, it should really be deprecated and ideally there'd be some replacement for the current debugger use... not sure about other use cases such as a jit, which was the initial target of PEP 523 -- @Mark, do you want to go that route/create a PEP to deprecate it so that this discussion takes place in a proper place?).

p.s.: as a note, bytecode modification on the actual object is not a usable approach for the debugger because users could break that in real-world use cases (i.e.: what happens if the user creates a **new** code and sets it to the code which had the breakpoint? What about breakpoint changes? Right now the debugger evaluates all assumptions just before the frame is executed, so, it's easier to get things right -- the case you posted currently does what's expected on pydevd). Still, a callback before the execution so that it could change the frame code before it's executed without the remainder of PEP 523 would be enough (and maybe it could be adopted in other Python implementations too) -- actually, for the debugger it'd be awesome if the frame code could be changed from inside a trace call and then that stack would restart execution (close to what happens with setting the frame line to be executed), but I guess this would be a completely different request ;)

p.s.: please don't reply to my previous p.s. here (let's move the discussion to another place -- either by @Mark creating a PEP for discussion or acknowledging the issue is ok given the current status quo).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Tue Nov 19 07:06:08 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 19 Nov 2019 12:06:08 +0000
Subject: [issue38846] async: Return context manager from open(_unix)_connection
In-Reply-To: <1574164468.11.0.934598090921.issue38846@roundup.psfhosted.org>
Message-ID: <1574165168.5.0.669152834461.issue38846@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

>From my understanding, Yuri doesn't want to improve the existing streaming API but invent something blessing new.

The improvement like you proposed has a very low chance to be accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38846>
_______________________________________

From report at bugs.python.org  Tue Nov 19 07:14:19 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 19 Nov 2019 12:14:19 +0000
Subject: [issue38847] AST Optimization for Single Target List Comprehension
Message-ID: <1574165659.02.0.559214725778.issue38847@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

I was going through old issues and I found @inada.naoki's comment on issue 36551

> How about converting `[x for x in it]` to `[*it]` in AST?

Is this feature still wanted? I can try to work on an implementation for this if there is a need. Also should this cover set (`{x for x in it}`) comprehensions?

----------
messages: 356965
nosy: BTaskaya, inada.naoki
priority: normal
severity: normal
status: open
title: AST Optimization for Single Target List Comprehension

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38847>
_______________________________________

From report at bugs.python.org  Tue Nov 19 07:14:31 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 19 Nov 2019 12:14:31 +0000
Subject: [issue38847] AST Optimization for Single Target List Comprehension
In-Reply-To: <1574165659.02.0.559214725778.issue38847@roundup.psfhosted.org>
Message-ID: <1574165671.33.0.908384596516.issue38847@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38847>
_______________________________________

From report at bugs.python.org  Tue Nov 19 07:15:00 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 19 Nov 2019 12:15:00 +0000
Subject: [issue38847] AST Optimization for Single Target List Comprehension
In-Reply-To: <1574165659.02.0.559214725778.issue38847@roundup.psfhosted.org>
Message-ID: <1574165700.51.0.14657108957.issue38847@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
components: +Interpreter Core
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38847>
_______________________________________

From report at bugs.python.org  Tue Nov 19 07:57:07 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Nov 2019 12:57:07 +0000
Subject: [issue27724] PEP3119 inconsintent with actual CPython impl
In-Reply-To: <1470817080.1.0.906916235476.issue27724@psf.upfronthosting.co.za>
Message-ID: <1574168227.87.0.0245627732587.issue27724@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Presumably when the implementation was done the IS_ABSTRACT name sounded more logical than just ABSTRACT. Since the PEP doesn't *specify* the name of this flag[1] I see no reason to change anything. Closing.

_____
[1] The PEP mentions this flag exactly once:

    (If this were implemented in CPython, an internal flag
    ``Py_TPFLAGS_ABSTRACT`` could be used to speed up this check [6]_.)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27724>
_______________________________________

From report at bugs.python.org  Tue Nov 19 08:49:26 2019
From: report at bugs.python.org (Dave Lotton)
Date: Tue, 19 Nov 2019 13:49:26 +0000
Subject: [issue38837] struct.pack: Unable to pack more than 256 bytes at a time
In-Reply-To: <1574097291.45.0.986281483128.issue38837@roundup.psfhosted.org>
Message-ID: <1574171366.1.0.18605707313.issue38837@roundup.psfhosted.org>


Dave Lotton <dlotton at gmail.com> added the comment:

Mark, you are absolutely correct.  I'm an idiot.  

Focused on wrong thing.  Thank you.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38837>
_______________________________________

From report at bugs.python.org  Tue Nov 19 08:53:56 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 13:53:56 +0000
Subject: [issue35409] Async generator might re-throw GeneratorExit on aclose()
In-Reply-To: <1543929680.9.0.788709270274.issue35409@psf.upfronthosting.co.za>
Message-ID: <1574171636.17.0.591138349888.issue35409@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8e0de2a4808d7c2f4adedabff89ee64e0338790a by Miss Islington (bot) (Vincent Michel) in branch 'master':
bpo-35409: Ignore GeneratorExit in async_gen_athrow_throw (GH-14755)
https://github.com/python/cpython/commit/8e0de2a4808d7c2f4adedabff89ee64e0338790a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35409>
_______________________________________

From report at bugs.python.org  Tue Nov 19 08:54:10 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 13:54:10 +0000
Subject: [issue35409] Async generator might re-throw GeneratorExit on aclose()
In-Reply-To: <1543929680.9.0.788709270274.issue35409@psf.upfronthosting.co.za>
Message-ID: <1574171650.52.0.477446968552.issue35409@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16751
pull_request: https://github.com/python/cpython/pull/17257

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35409>
_______________________________________

From report at bugs.python.org  Tue Nov 19 08:54:47 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 13:54:47 +0000
Subject: [issue35409] Async generator might re-throw GeneratorExit on aclose()
In-Reply-To: <1543929680.9.0.788709270274.issue35409@psf.upfronthosting.co.za>
Message-ID: <1574171687.1.0.851581745937.issue35409@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16752
pull_request: https://github.com/python/cpython/pull/17258

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35409>
_______________________________________

From report at bugs.python.org  Tue Nov 19 08:55:48 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 19 Nov 2019 13:55:48 +0000
Subject: [issue35409] Async generator might re-throw GeneratorExit on aclose()
In-Reply-To: <1543929680.9.0.788709270274.issue35409@psf.upfronthosting.co.za>
Message-ID: <1574171748.6.0.177428998672.issue35409@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35409>
_______________________________________

From report at bugs.python.org  Tue Nov 19 09:12:17 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 14:12:17 +0000
Subject: [issue35409] Async generator might re-throw GeneratorExit on aclose()
In-Reply-To: <1543929680.9.0.788709270274.issue35409@psf.upfronthosting.co.za>
Message-ID: <1574172737.03.0.788307554171.issue35409@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6c3b471c8c0bfd49c664d8ee7e95da3710fd6069 by Miss Islington (bot) in branch '3.8':
bpo-35409: Ignore GeneratorExit in async_gen_athrow_throw (GH-14755)
https://github.com/python/cpython/commit/6c3b471c8c0bfd49c664d8ee7e95da3710fd6069


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35409>
_______________________________________

From report at bugs.python.org  Tue Nov 19 09:12:24 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 14:12:24 +0000
Subject: [issue35409] Async generator might re-throw GeneratorExit on aclose()
In-Reply-To: <1543929680.9.0.788709270274.issue35409@psf.upfronthosting.co.za>
Message-ID: <1574172744.08.0.0818277700963.issue35409@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4ffc569b47bef9f95e443f3c56f7e7e32cb440c0 by Miss Islington (bot) in branch '3.7':
bpo-35409: Ignore GeneratorExit in async_gen_athrow_throw (GH-14755)
https://github.com/python/cpython/commit/4ffc569b47bef9f95e443f3c56f7e7e32cb440c0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35409>
_______________________________________

From report at bugs.python.org  Tue Nov 19 09:21:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 14:21:31 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1574173291.04.0.631700644951.issue38576@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +Library (Lib)
versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Tue Nov 19 09:52:00 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 19 Nov 2019 14:52:00 +0000
Subject: [issue32371] Delay-loading of python dll is impossible when using
 some C macros
In-Reply-To: <1513689198.93.0.213398074469.issue32371@psf.upfronthosting.co.za>
Message-ID: <1574175120.55.0.420680365044.issue32371@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks for reporting back.  If you find that you can provide a reliable reproducer later, do please reopen and attach it.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32371>
_______________________________________

From report at bugs.python.org  Tue Nov 19 10:17:43 2019
From: report at bugs.python.org (Pierre Chatelier)
Date: Tue, 19 Nov 2019 15:17:43 +0000
Subject: [issue32371] Delay-loading of python dll is impossible when using
 some C macros
In-Reply-To: <1513689198.93.0.213398074469.issue32371@psf.upfronthosting.co.za>
Message-ID: <1574176663.01.0.221775662225.issue32371@roundup.psfhosted.org>


Pierre Chatelier <pierre at chachatelier.fr> added the comment:

Just reproduced and solved it at the same time !
It happened with Debug build, where I linked to pythonxx.lib instead of pythonxx_d.lib, because I did not download the debug binaries.
Ultimately : my fault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32371>
_______________________________________

From report at bugs.python.org  Tue Nov 19 10:28:49 2019
From: report at bugs.python.org (Pierre Chatelier)
Date: Tue, 19 Nov 2019 15:28:49 +0000
Subject: [issue32371] Delay-loading of python dll is impossible when using
 some C macros
In-Reply-To: <1513689198.93.0.213398074469.issue32371@psf.upfronthosting.co.za>
Message-ID: <1574177329.02.0.163996258878.issue32371@roundup.psfhosted.org>


Pierre Chatelier <pierre at chachatelier.fr> added the comment:

Aaand finally there is still something : it depends on the call context. Once in a C++/CLI class, the link bug occurs again.
Here is attached a minimal project.

----------
status: closed -> open
Added file: https://bugs.python.org/file48721/PythonFromC.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32371>
_______________________________________

From report at bugs.python.org  Tue Nov 19 10:28:56 2019
From: report at bugs.python.org (Pierre Chatelier)
Date: Tue, 19 Nov 2019 15:28:56 +0000
Subject: [issue32371] Delay-loading of python dll is impossible when using
 some C macros
In-Reply-To: <1513689198.93.0.213398074469.issue32371@psf.upfronthosting.co.za>
Message-ID: <1574177336.52.0.117646672437.issue32371@roundup.psfhosted.org>


Change by Pierre Chatelier <pierre at chachatelier.fr>:


----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32371>
_______________________________________

From report at bugs.python.org  Tue Nov 19 10:43:33 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 15:43:33 +0000
Subject: [issue38848] test_compileall fails when the platform lacks a
 functional sem_open()
Message-ID: <1574178213.95.0.878583354455.issue38848@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

See also the related issues:
#32126: [asyncio] test failure when the platform lacks a functional  sem_open()
#28668: instanciation of multiprocessing.Queue raises ImportError in test_logging

The test failure on android API 24:

generic_x86_64:/data/local/tmp/python $ python -m test -v test_compileall -m test_workers
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://andro
id.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_2579
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_compileall
test_workers (test.test_compileall.CommandLineTestsNoSourceEpoch) ... FAIL
test_workers (test.test_compileall.CommandLineTestsWithSourceEpoch) ... FAIL

======================================================================
FAIL: test_workers (test.test_compileall.CommandLineTestsNoSourceEpoch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_py_compile.py", line 20, in wrapper
    return fxn(*args, **kwargs)
  File "/data/local/tmp/python/lib/python3.9/test/test_compileall.py", line 707, in test_workers        self.assertRunOK(self.directory, '-j', '0')
  File "/data/local/tmp/python/lib/python3.9/test/test_compileall.py", line 397, in assertRunOK
    rc, out, err = script_helper.assert_python_ok(
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 157, in assert_pyt
hon_ok
    return _assert_python(True, *args, **env_vars)
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 143, in _assert_py
thon
    res.fail(cmd_line)
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 70, in fail
    raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: ['/data/local/tmp/python/bin/python', '-X', 'faulthandler', '-I', '-S', '-m', 'compile
all', '/data/local/tmp/python/tmp/tmpc1hy_667', '-j', '0']

stdout:
---

---

stderr:
---
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 28, in <module>
    from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'SemLock' from '_multiprocessing' (/data/local/tmp/python/lib/python
3.9/lib-dynload/_multiprocessing.cpython-39d.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 425, in <module>
    exit_status = int(not main())
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 403, in main
    if not compile_dir(dest, maxlevels, args.ddir,
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 91, in compile_dir
    with ProcessPoolExecutor(max_workers=workers) as executor:
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 555, in __init__
    self._call_queue = _SafeQueue(
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 165, in __init__
    super().__init__(max_size, ctx=ctx)
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/context.py", line 67, in Lock
    from .synchronize import Lock
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 30, in <module>
    raise ImportError("This platform lacks a functioning sem_open" +
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required sync
hronization primitives needed will not function, see issue 3770.
---

======================================================================
FAIL: test_workers (test.test_compileall.CommandLineTestsWithSourceEpoch)
======================================================================                      [38/374]
FAIL: test_workers (test.test_compileall.CommandLineTestsWithSourceEpoch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_py_compile.py", line 30, in wrapper
    return fxn(*args, **kwargs)
  File "/data/local/tmp/python/lib/python3.9/test/test_compileall.py", line 707, in test_workers
    self.assertRunOK(self.directory, '-j', '0')
  File "/data/local/tmp/python/lib/python3.9/test/test_compileall.py", line 397, in assertRunOK
    rc, out, err = script_helper.assert_python_ok(
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 157, in assert_pyt
hon_ok
    return _assert_python(True, *args, **env_vars)
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 143, in _assert_py
thon
    res.fail(cmd_line)
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 70, in fail
    raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: ['/data/local/tmp/python/bin/python', '-X', 'faulthandler', '-I', '-S', '-m', 'compile
all', '/data/local/tmp/python/tmp/tmp3llbx9yv', '-j', '0']
stdout:
---

---

stderr:
---
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 28, in <module>
    from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'SemLock' from '_multiprocessing' (/data/local/tmp/python/lib/python
3.9/lib-dynload/_multiprocessing.cpython-39d.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 425, in <module>
    exit_status = int(not main())
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 403, in main
    if not compile_dir(dest, maxlevels, args.ddir,
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 91, in compile_dir
    with ProcessPoolExecutor(max_workers=workers) as executor:
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 555, in __init__
    self._call_queue = _SafeQueue(
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 165, in __init__
    super().__init__(max_size, ctx=ctx)
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/context.py", line 67, in Lock
    from .synchronize import Lock
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 30, in <module>
    raise ImportError("This platform lacks a functioning sem_open" +
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.
---

----------------------------------------------------------------------

Ran 2 tests in 0.693s

FAILED (failures=2)
test test_compileall failed
test_compileall failed

== Tests result: FAILURE ==

1 test failed:
    test_compileall

Total duration: 943 ms
Tests result: FAILURE

----------
components: Tests
messages: 356974
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_compileall fails when the platform lacks a functional  sem_open()
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38848>
_______________________________________

From report at bugs.python.org  Tue Nov 19 10:48:10 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 15:48:10 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1574178490.77.0.740326495069.issue25172@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Tue Nov 19 11:00:15 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 16:00:15 +0000
Subject: [issue38849] test_timestamp_naive fails on android
Message-ID: <1574179215.81.0.231075264826.issue38849@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

test_timestamp_naive of test_datetime fails on android API 24:

generic_x86_64:/data/local/tmp/python $ python -m test -v test_datetime -m test_timestamp_naive
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_2606
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_datetime
test_timestamp_naive (test.datetimetester.TestDateTime_Pure) ... FAIL
test_timestamp_naive (test.datetimetester.TestDateTimeTZ_Pure) ... FAIL
test_timestamp_naive (test.datetimetester.TestSubclassDateTime_Pure) ... FAIL
test_timestamp_naive (test.datetimetester.TestDateTime_Fast) ... FAIL
test_timestamp_naive (test.datetimetester.TestDateTimeTZ_Fast) ... FAIL
test_timestamp_naive (test.datetimetester.TestSubclassDateTime_Fast) ... FAIL

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTime_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_n
aive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTimeTZ_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_n
aive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestSubclassDateTime_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_n
aive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTime_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_n
aive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTimeTZ_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_naive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestSubclassDateTime_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_naive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

----------------------------------------------------------------------

Ran 6 tests in 0.026s

FAILED (failures=6)
test test_datetime failed
test_datetime failed

== Tests result: FAILURE ==

1 test failed:
    test_datetime

Total duration: 331 ms
Tests result: FAILURE

----------
components: Tests
messages: 356975
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_timestamp_naive fails on android
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38849>
_______________________________________

From report at bugs.python.org  Tue Nov 19 11:06:11 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 16:06:11 +0000
Subject: [issue38850] test_largefile fails on android
Message-ID: <1574179571.39.0.141498155807.issue38850@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

The failure on andoid API 24:

generic_x86_64:/data/local/tmp/python $ python -m test -v test_largefile -m test_it
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://andro
id.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_2626
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_largefile
test_it (test.test_largefile.TestCopyfile) ... ERROR
test_it (test.test_largefile.TestSocketSendfile) ... Exception in thread Thread-1:
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/threading.py", line 944, in _bootstrap_inner
    self.run()
  File "/data/local/tmp/python/lib/python3.9/threading.py", line 882, in run
    self._target(*self._args, **self._kwargs)
  File "/data/local/tmp/python/lib/python3.9/test/test_largefile.py", line 193, in run
    f.write(chunk)
OSError: [Errno 28] No space left on device
ERROR

======================================================================
ERROR: test_it (test.test_largefile.TestCopyfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_largefile.py", line 160, in test_it
    shutil.copyfile(TESTFN, TESTFN2)
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 270, in copyfile
    _fastcopy_sendfile(fsrc, fdst)
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 163, in _fastcopy_sendfile
    raise err from None
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 149, in _fastcopy_sendfile
    sent = os.sendfile(outfd, infd, offset, blocksize)
OSError: [Errno 28] No space left on device: '@test_2626_tmp' -> '@test_2626_tmp2'

======================================================================
ERROR: test_it (test.test_largefile.TestSocketSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_largefile.py", line 207, in test_it
    shutil.copyfile(TESTFN, TESTFN2)
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 270, in copyfile
    _fastcopy_sendfile(fsrc, fdst)
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 163, in _fastcopy_sendfile
    raise err from None
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 149, in _fastcopy_sendfile
    sent = os.sendfile(outfd, infd, offset, blocksize)
OSError: [Errno 28] No space left on device: '@test_2626_tmp' -> '@test_2626_tmp2'

======================================================================
ERROR: test_it (test.test_largefile.TestSocketSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_largefile.py", line 207, in test_it
    client.sendfile(f)
  File "/data/local/tmp/python/lib/python3.9/socket.py", line 483, in sendfile
    return self._sendfile_use_sendfile(file, offset, count)
  File "/data/local/tmp/python/lib/python3.9/socket.py", line 400, in _sendfile_use_sendfile
    raise err from None
  File "/data/local/tmp/python/lib/python3.9/socket.py", line 386, in _sendfile_use_sendfile
    sent = os_sendfile(sockno, fileno, offset, blocksize)
BrokenPipeError: [Errno 32] Broken pipe

----------------------------------------------------------------------

Ran 2 tests in 1.207s

FAILED (errors=2)
test test_largefile failed
test_largefile failed

== Tests result: FAILURE ==

1 test failed:
    test_largefile

Total duration: 1.4 sec
Tests result: FAILURE

----------
components: Tests
messages: 356976
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_largefile fails on android
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38850>
_______________________________________

From report at bugs.python.org  Tue Nov 19 11:15:09 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 19 Nov 2019 16:15:09 +0000
Subject: [issue38850] test_largefile fails on android
In-Reply-To: <1574179571.39.0.141498155807.issue38850@roundup.psfhosted.org>
Message-ID: <1574180109.5.0.800707809247.issue38850@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

I got the same failures on Fedora rawhide. See https://bugs.python.org/issue37096

----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38850>
_______________________________________

From report at bugs.python.org  Tue Nov 19 11:33:22 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 19 Nov 2019 16:33:22 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574181202.02.0.55972947011.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16753
pull_request: https://github.com/python/cpython/pull/17260

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 11:49:41 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 19 Nov 2019 16:49:41 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
In-Reply-To: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>
Message-ID: <1574182181.2.0.120076627323.issue38841@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Do I understand you correctly: is Android forbids UDP Unix sockets for non-root user?
Maybe the socket path should point on another location to get the test passed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Tue Nov 19 12:35:02 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 17:35:02 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
In-Reply-To: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>
Message-ID: <1574184902.81.0.895371437663.issue38841@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

No, it is the SELinux configuration on android devices that forbids binds to named UNIX sockets. Changing from a named UNIX socket to an unnamed UNIX socket would fix the problem. I don't know if all platforms support unnamed UNIX sockets.

The fix in issue #28684 (referenced in the OP) provides a new decorator to skip the test for platforms such as android.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Tue Nov 19 12:37:29 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Nov 2019 17:37:29 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1574185049.55.0.443602498418.issue35943@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I've assigned this to Joannah to decide if she wants to backport this.

----------
assignee:  -> nanjekyejoannah
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Tue Nov 19 12:41:04 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Nov 2019 17:41:04 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574185264.78.0.595964744088.issue38500@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I think the real question is whether this is part of the CPython public API or the CPython internal API.

@Fabio how burdensome would it be if we placed this in the internal API that you can get access to but we don't make backwards-compatibility guarantees about? For instance, Victor wants to start passing in thread state which will change the API for 3.9, but we wouldn't expect to change it in a bugfix release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Tue Nov 19 12:45:37 2019
From: report at bugs.python.org (=?utf-8?q?S=C3=BCmer_Cip?=)
Date: Tue, 19 Nov 2019 17:45:37 +0000
Subject: [issue26278] BaseTransport.close() does not trigger connection_lost()
In-Reply-To: <1454515056.72.0.0290408111031.issue26278@psf.upfronthosting.co.za>
Message-ID: <1574185537.89.0.759376641619.issue26278@roundup.psfhosted.org>


S?mer Cip <sumerc at gmail.com> added the comment:

Closing the issue seems like a good idea: as it seems nobody seems to have spotted similar issue and I have only been able to reproduce it in Python 3.4. 

Just for future ref.: The uncommon thing is that the server I was using is a TCP game server holding long-running connections as opposed to short-lived HTTP connections, maybe there is a very random issue at the core but as it is happening very randomly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26278>
_______________________________________

From report at bugs.python.org  Tue Nov 19 13:16:40 2019
From: report at bugs.python.org (Fabio Zadrozny)
Date: Tue, 19 Nov 2019 18:16:40 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574187400.02.0.635654273097.issue38500@roundup.psfhosted.org>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

@Bret

I don't really see a problem in breaking the API in major releases (so, having access for it in the internal API but without a backwards-compatibility guarantee seems like a good fit for me).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Tue Nov 19 14:16:59 2019
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 19 Nov 2019 19:16:59 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574191019.03.0.219981089546.issue38823@roundup.psfhosted.org>


Thomas Wouters <thomas at python.org> added the comment:


New changeset 54b32c987146123f2237f0e21b1d02b1c1ebdf6f by T. Wouters (Brandt Bucher) in branch 'master':
bpo-38823: Clean up refleak in fcntl module initialization. (GH-17236)
https://github.com/python/cpython/commit/54b32c987146123f2237f0e21b1d02b1c1ebdf6f


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 14:40:49 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 19:40:49 +0000
Subject: [issue38851] UDPLITE tests fail on android
Message-ID: <1574192449.59.0.396437190264.issue38851@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Attached test_socket.txt is the output of running 'python -m test -v test_socket' on android API 24. The 108 tests in error are UDPLITE tests introduced in issue #37345.

----------
components: Tests
files: test_socket.txt
messages: 356985
nosy: asvetlov, gappleto97, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: UDPLITE tests fail on android
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48722/test_socket.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38851>
_______________________________________

From report at bugs.python.org  Tue Nov 19 14:44:55 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Nov 2019 19:44:55 +0000
Subject: [issue38839] Fix some unused functions in test suite
In-Reply-To: <1574114905.54.0.915715674815.issue38839@roundup.psfhosted.org>
Message-ID: <1574192695.32.0.746972902651.issue38839@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: Some unused functions in test suite -> Fix some unused functions in test suite

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38839>
_______________________________________

From report at bugs.python.org  Tue Nov 19 14:45:27 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Nov 2019 19:45:27 +0000
Subject: [issue38839] Fix some unused functions in test suite
In-Reply-To: <1574114905.54.0.915715674815.issue38839@roundup.psfhosted.org>
Message-ID: <1574192727.61.0.867620012466.issue38839@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 892221bfa04a41cf581f988ba19dc263f557e157 by Brett Cannon (Adam Johnson) in branch 'master':
bpo-38839: Fix some unused functions in tests (GH-17189)
https://github.com/python/cpython/commit/892221bfa04a41cf581f988ba19dc263f557e157


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38839>
_______________________________________

From report at bugs.python.org  Tue Nov 19 14:46:02 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Nov 2019 19:46:02 +0000
Subject: [issue38839] Fix some unused functions in test suite
In-Reply-To: <1574114905.54.0.915715674815.issue38839@roundup.psfhosted.org>
Message-ID: <1574192762.39.0.0788301400129.issue38839@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38839>
_______________________________________

From report at bugs.python.org  Tue Nov 19 14:50:17 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 19:50:17 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1574193017.78.0.559586171022.issue38707@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c6b20be85c0de6f2355c67ae6e7e578941275cc0 by Miss Islington (bot) (Jake Tesler) in branch 'master':
bpo-38707: Fix for multiprocessing.Process MainThread.native_id (GH-17088)
https://github.com/python/cpython/commit/c6b20be85c0de6f2355c67ae6e7e578941275cc0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Tue Nov 19 14:50:32 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 19:50:32 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1574193032.42.0.377362906472.issue38707@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16754
pull_request: https://github.com/python/cpython/pull/17261

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Tue Nov 19 15:02:17 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 20:02:17 +0000
Subject: [issue38852] test_recursion_limit in test_threading crashes with
 SIGSEGV on android
Message-ID: <1574193737.03.0.937540674169.issue38852@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Actually it is the script that is spawned by test_recursion_limit that crashes with SIGSEGV on android API 24. Lowering the recursion limit in the script from 1000 to 100 with sys.setrecursionlimit() fixes the problem.

Here is the error:

generic_x86_64:/data/local/tmp/python $ python -m test -v test_threading -m test_recursion_limit   
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_4603
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_threading
test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... FAIL

======================================================================
FAIL: test_recursion_limit (test.test_threading.ThreadingExceptionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_threading.py", line 1086, in test_recursion_limit
    self.assertEqual(p.returncode, 0, "Unexpected error: " + stderr.decode())
AssertionError: -11 != 0 : Unexpected error: 

----------------------------------------------------------------------

Ran 1 test in 0.148s

FAILED (failures=1)
test test_threading failed
test_threading failed

== Tests result: FAILURE ==

1 test failed:
    test_threading

Total duration: 354 ms
Tests result: FAILURE

----------
components: Tests
messages: 356988
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_recursion_limit in test_threading crashes with SIGSEGV on android
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38852>
_______________________________________

From report at bugs.python.org  Tue Nov 19 15:11:25 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 20:11:25 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1574194285.02.0.317600329002.issue38707@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 829593a9262e67c72167c6cb20d383203b2ea410 by Miss Islington (bot) in branch '3.8':
bpo-38707: Fix for multiprocessing.Process MainThread.native_id (GH-17088)
https://github.com/python/cpython/commit/829593a9262e67c72167c6cb20d383203b2ea410


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Tue Nov 19 16:09:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 21:09:05 +0000
Subject: [issue26278] BaseTransport.close() does not trigger connection_lost()
In-Reply-To: <1454515056.72.0.0290408111031.issue26278@psf.upfronthosting.co.za>
Message-ID: <1574197745.1.0.227592127774.issue26278@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

If a bug cannot be reproduced, it cannot be fixed. So I close the issue ;-)

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26278>
_______________________________________

From report at bugs.python.org  Tue Nov 19 16:27:41 2019
From: report at bugs.python.org (Cat Chenal)
Date: Tue, 19 Nov 2019 21:27:41 +0000
Subject: [issue38853] set.repr breaches docstring contract
Message-ID: <1574198861.64.0.9694268826.issue38853@roundup.psfhosted.org>


New submission from Cat Chenal <catchenal at gmail.com>:

S = {19,8,-1,25,0,1,2,3,4,5,6,7}
print('Set S = {{19,8,-1,25,0,1,2,3,4,5,6,7}}')

The set is represented by a new string-ordered set:
print(f'Its repr is:\n{S}\n')
Output:
{0, 1, 2, 3, 4, 5, 6, 7, 8, 19, 25, -1}

This is a breach of the contract stated in the docstring: "Build an unordered collection of unique elements."

----------
components: ctypes
messages: 356991
nosy: Ylem
priority: normal
severity: normal
status: open
title: set.repr breaches docstring contract
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38853>
_______________________________________

From report at bugs.python.org  Tue Nov 19 16:35:38 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Nov 2019 21:35:38 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1574199338.25.0.0011460847419.issue38707@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you Jake for the report and PR!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Tue Nov 19 16:37:42 2019
From: report at bugs.python.org (Guido Imperiale)
Date: Tue, 19 Nov 2019 21:37:42 +0000
Subject: [issue38854] Decorator breaks inspect.getsource
Message-ID: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>


New submission from Guido Imperiale <crusaderky at gmail.com>:

Python 3.7.5 and 3.8.0
A decorator causes inspect.getsource() to return clipped output:



from collections import defaultdict
from functools import wraps
import inspect


def foo(*args):
    def decorator(func):
        @wraps(func)
        def wrapper():
            pass
        return wrapper
    return decorator


@foo(dict(), defaultdict(lambda: 1))
def f():
    pass


print(inspect.getsource(f))



Output:

@foo(dict(), defaultdict(lambda: 1))

Expected output:

@foo(dict(), defaultdict(lambda: 1))
def f():
    pass


These changes to the decorator parameters cause the problem to disappear:

- @foo({}, defaultdict(lambda: 1))
- @foo(dict(), defaultdict(list))

----------
messages: 356993
nosy: crusaderky
priority: normal
severity: normal
status: open
title: Decorator breaks inspect.getsource
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Tue Nov 19 16:44:26 2019
From: report at bugs.python.org (Cat Chenal)
Date: Tue, 19 Nov 2019 21:44:26 +0000
Subject: [issue38855] test_unpack.py does not catch the unpacking of a set
Message-ID: <1574199866.94.0.505972513072.issue38855@roundup.psfhosted.org>


New submission from Cat Chenal <catchenal at gmail.com>:

S = {19,8,-1,25,0,1,2,3,4,5,6,7}

a, *b, c = S
print('a:', a)
print('b:', b)
print('c:', c)

Output:
a: 0
b: [1, 2, 3, 4, 5, 6, 7, 8, 19, 25]
c: -1

Either test_unpack.py needs a test for "non-indexable object" to prevent this unpacking of a non-sequence, or the unpacking of a set should be implemented (granted the ordered repr of a set is changed to unordered, see Issue38853).

Being able to "unpack" a set would be nice to have, imho, because one would use that operation to obtain a partition (over unordered elements).

----------
components: Tests, ctypes
messages: 356994
nosy: Ylem
priority: normal
severity: normal
status: open
title: test_unpack.py does not catch the unpacking of a set
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38855>
_______________________________________

From report at bugs.python.org  Tue Nov 19 17:00:21 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 19 Nov 2019 22:00:21 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
In-Reply-To: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>
Message-ID: <1574200821.16.0.344357438421.issue38841@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Please feel free to make a PR for applying @skip_unless_bind_unix_socket decorator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Tue Nov 19 17:06:26 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 19 Nov 2019 22:06:26 +0000
Subject: [issue38856] wait_closed() can raise ConnectionResetError
Message-ID: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>


New submission from Yury Selivanov <yselivanov at gmail.com>:

The exception should probably be just ignored.  Andrew, thoughts?

Here's an example error traceback:

      Traceback (most recent call last):
        File "c:\projects\asyncpg\asyncpg\connection.py", line 1227, in _cancel
          await w.wait_closed()
        File "C:\Python38\lib\asyncio\streams.py", line 376, in wait_closed
          await self._protocol._get_close_waiter(self)
        File "c:\projects\asyncpg\asyncpg\connection.py", line 1202, in _cancel
          await r.read()  # Wait until EOF
        File "C:\Python38\lib\asyncio\streams.py", line 694, in read
          block = await self.read(self._limit)
        File "C:\Python38\lib\asyncio\streams.py", line 701, in read
          await self._wait_for_data('read')
        File "C:\Python38\lib\asyncio\streams.py", line 534, in _wait_for_data
          await self._waiter
        File "C:\Python38\lib\asyncio\proactor_events.py", line 280, in _loop_reading
          data = fut.result()
        File "C:\Python38\lib\asyncio\windows_events.py", line 808, in _poll
          value = callback(transferred, key, ov)
        File "C:\Python38\lib\asyncio\windows_events.py", line 457, in finish_recv
          raise ConnectionResetError(*exc.args)
      ConnectionResetError: [WinError 64] The specified network name is no longer available

----------
messages: 356996
nosy: asvetlov, lukasz.langa, yselivanov
priority: release blocker
severity: normal
status: open
title: wait_closed() can raise ConnectionResetError
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Tue Nov 19 17:13:28 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 19 Nov 2019 22:13:28 +0000
Subject: [issue38853] set.repr breaches docstring contract
In-Reply-To: <1574198861.64.0.9694268826.issue38853@roundup.psfhosted.org>
Message-ID: <1574201608.02.0.300950189365.issue38853@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm sorry, I don't understand what part of the documentation you think is violated here. The docs say that sets are unordered, but of course when printing the elements have to be given in *some* order.

The given output seems unordered to me: -1 is smaller than 25, but it appears last in the output.

The specific order you see will depend on the specific values in the set, as well as the order that they were inserted, deleted, and/or re-inserted in some arbitrary way. For example:

    >>> repr({4, 5, 2**31+1, 2, 2**31+2, 3, 2**31, 0})
    '{0, 2147483648, 2, 3, 2147483650, 2147483649, 5, 4}'


I don't think there is a bug here. Can you explain what you think the bug is, in detail please?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38853>
_______________________________________

From report at bugs.python.org  Tue Nov 19 17:27:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 22:27:08 +0000
Subject: [issue38707] Multiprocessing: bug with Native ID for
 threading.mainthread()
In-Reply-To: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>
Message-ID: <1574202428.38.0.536441726073.issue38707@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for the fix. That was an interesting bug ;-) I like the simplicity of the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38707>
_______________________________________

From report at bugs.python.org  Tue Nov 19 17:37:07 2019
From: report at bugs.python.org (Dan)
Date: Tue, 19 Nov 2019 22:37:07 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1574203027.42.0.84700421999.issue33125@roundup.psfhosted.org>


Dan <negativeiq at gmail.com> added the comment:

According to this -
https://wiki.tcl-lang.org/page/Building+with+Visual+Studio+2017
the issue will be fixed in the next version (8.6.10). TLDR explanation: Tcl/Tk has variables with names that are now reserved keywords in VS2017, meaning that it can't be build with recent compilers and since VS2017 is the first compiler that has official ARM64 support it means that it currently can't be built for that target.
Anyway when version 8.6.10 is eventually released then it should (hopefully) build fine with the current scripts.
Maybe we can add it later when that happens?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:04:14 2019
From: report at bugs.python.org (Jason Fried)
Date: Tue, 19 Nov 2019 23:04:14 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
Message-ID: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>


New submission from Jason Fried <me at jasonfried.info>:

If you are trying to use AsyncMock to mock a coroutine that returns awaitable objects, AsyncMock awaits on those objects instead of returning them as is. 

Example:
  mock = AsyncMock(return_value=asyncio.Future())
  v = await mock()  # blocks on trying to await the future

Expected:
  mock = AsyncMock(return_value=asyncio.Future())
  v = await mock()
  assert isisnstance(v, asyncio.Future)

This problem affects side_effects and wraps.

----------
components: Library (Lib)
messages: 357000
nosy: fried, lisroach
priority: normal
severity: normal
status: open
title: AsyncMock issue with awaitable return_value/side_effect/wraps
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:11:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 23:11:09 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
Message-ID: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Currently, new_interpreter() is a subset of Py_InitializeFromConfig(): the code was duplicated. I would prefer that both functions stay in sync and so that new_interpreter() reuses more Py_InitializeFromConfig() code.

----------
components: Interpreter Core
messages: 357001
nosy: vstinner
priority: normal
severity: normal
status: open
title: new_interpreter() should reuse more Py_InitializeFromConfig() code
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:13:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 23:13:09 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574205189.52.0.137379444907.issue38823@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ac2235432c607ce2c0faf6dff5d9b2534d2f6652 by Victor Stinner (Brandt Bucher) in branch 'master':
bpo-38823: Fix refleaks in faulthandler init error path on Windows (GH-17250)
https://github.com/python/cpython/commit/ac2235432c607ce2c0faf6dff5d9b2534d2f6652


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:13:59 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 23:13:59 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574205239.28.0.491609660618.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16755
pull_request: https://github.com/python/cpython/pull/17263

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:14:06 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 23:14:06 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574205246.45.0.344225572052.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16756
pull_request: https://github.com/python/cpython/pull/17264

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:14:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 23:14:22 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574205262.65.0.588434806327.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:30:13 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 23:30:13 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574206213.32.0.38637495916.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5bd2af9c79796aa03b06d1e35ab6df7e28364e24 by Miss Islington (bot) in branch '3.7':
bpo-38823: Fix refleaks in faulthandler init error path on Windows (GH-17250)
https://github.com/python/cpython/commit/5bd2af9c79796aa03b06d1e35ab6df7e28364e24


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:31:12 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Nov 2019 23:31:12 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574206272.25.0.327215919074.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a5ed2fe0eedefa1649aa93ee74a0bafc8e628a10 by Miss Islington (bot) in branch '3.8':
bpo-38823: Fix refleaks in faulthandler init error path on Windows (GH-17250)
https://github.com/python/cpython/commit/a5ed2fe0eedefa1649aa93ee74a0bafc8e628a10


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:38:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 23:38:21 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574206701.2.0.248780056489.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ef5aa9af7c7e493402ac62009e4400aed7c3d54e by Victor Stinner in branch 'master':
bpo-38858: Reorganize pycore_init_types() (GH-17265)
https://github.com/python/cpython/commit/ef5aa9af7c7e493402ac62009e4400aed7c3d54e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:46:57 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Nov 2019 23:46:57 +0000
Subject: [issue37957] Allow regrtest to receive a file with test (and
 subtests) to ignore
In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org>
Message-ID: <1574207217.68.0.273643767424.issue37957@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset e0cd8aa70a3ce19c3d3712568940aa0cbd9aa97b by Pablo Galindo in branch 'master':
bpo-37957: Allow regrtest to receive a file with test (and subtests) to ignore (GH-16989)
https://github.com/python/cpython/commit/e0cd8aa70a3ce19c3d3712568940aa0cbd9aa97b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37957>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:47:30 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Nov 2019 23:47:30 +0000
Subject: [issue37957] Allow regrtest to receive a file with test (and
 subtests) to ignore
In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org>
Message-ID: <1574207250.89.0.185584542121.issue37957@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37957>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:56:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 23:56:40 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1574207800.79.0.2910534009.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16758
pull_request: https://github.com/python/cpython/pull/17266

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Tue Nov 19 18:57:15 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Nov 2019 23:57:15 +0000
Subject: [issue38847] AST Optimization for Single Target List Comprehension
In-Reply-To: <1574165659.02.0.559214725778.issue38847@roundup.psfhosted.org>
Message-ID: <1574207835.16.0.602280249172.issue38847@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

IMHO, I think is such a specific use case that is not worth the maintenance cost. Especially because of such list comprehension is very uncommon as you can simply do `list(it)` which more readable and anecdotally faster.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38847>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:14:29 2019
From: report at bugs.python.org (Jason Fried)
Date: Wed, 20 Nov 2019 00:14:29 +0000
Subject: [issue38859] AsyncMock says it raises StopIteration but that is
 Impossible
Message-ID: <1574208869.25.0.189658973106.issue38859@roundup.psfhosted.org>


New submission from Jason Fried <me at jasonfried.info>:

If an AsyncMock uses a side_effect that is an Iterable, if called more than items exist its suppose to raise StopIteration according to the docs but PEP 479 says that is impossible. 

My Suggestion is that we update the docs and the code to Raise a StopAsyncIteration since it will not be converted to a RuntimeError

----------
components: Library (Lib)
messages: 357008
nosy: fried, lisroach
priority: normal
severity: normal
status: open
title: AsyncMock says it raises StopIteration but that is Impossible
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38859>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:14:48 2019
From: report at bugs.python.org (Jason Fried)
Date: Wed, 20 Nov 2019 00:14:48 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1574208888.86.0.856749184651.issue38857@roundup.psfhosted.org>


Change by Jason Fried <me at jasonfried.info>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:18:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 00:18:14 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1574209094.36.0.217109028068.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 444b39bb64aa894d3f1831210a8ce40042a5a532 by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in handle_legacy_finalizers() (GH-17266)
https://github.com/python/cpython/commit/444b39bb64aa894d3f1831210a8ce40042a5a532


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:19:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 00:19:32 +0000
Subject: [issue36710] Pass _PyRuntimeState as an argument rather than using
 the _PyRuntime global variable
In-Reply-To: <1556110680.79.0.127639989845.issue36710@roundup.psfhosted.org>
Message-ID: <1574209172.8.0.575884407786.issue36710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16759
pull_request: https://github.com/python/cpython/pull/17267

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36710>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:30:47 2019
From: report at bugs.python.org (Lisa Roach)
Date: Wed, 20 Nov 2019 00:30:47 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
In-Reply-To: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>
Message-ID: <1574209847.07.0.95328812994.issue38753@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:


New changeset 279d8df5e5e8bbd4429420649359f7afcb4c8cce by Lisa Roach (John Belmonte) in branch 'master':
bpo-38753: AsyncMock added in version 3.8 (GH-17102)
https://github.com/python/cpython/commit/279d8df5e5e8bbd4429420649359f7afcb4c8cce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:30:59 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 00:30:59 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
In-Reply-To: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>
Message-ID: <1574209859.72.0.513324259112.issue38753@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16760
pull_request: https://github.com/python/cpython/pull/17268

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:33:12 2019
From: report at bugs.python.org (David Cuthbert)
Date: Wed, 20 Nov 2019 00:33:12 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574209992.34.0.655039101067.issue37228@roundup.psfhosted.org>


David Cuthbert <dacut at kanga.org> added the comment:

I'm working on patches for the deprecation bits (targeting 3.6 for now; will work my way up from there) for review, including documentation. Unless someone tells me to stop. :-)

In an attempt to make this not-so-Linux-specific, I'm reviewing how this works on non-Linux platforms (MacOS, FreeBSD) as well.

Reading Linux's socket(7) man page makes it seem like reuse_port is the issue (but that actually has protections to ensure you're only doing it across the same UID at least). I had to write my own test jig to (re-)convince myself that, indeed, reuse_addr is the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:38:18 2019
From: report at bugs.python.org (Jason Fried)
Date: Wed, 20 Nov 2019 00:38:18 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1574210298.19.0.954039285294.issue38857@roundup.psfhosted.org>


Change by Jason Fried <me at jasonfried.info>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:38:18 2019
From: report at bugs.python.org (Jason Fried)
Date: Wed, 20 Nov 2019 00:38:18 +0000
Subject: [issue38859] AsyncMock says it raises StopIteration but that is
 Impossible
In-Reply-To: <1574208869.25.0.189658973106.issue38859@roundup.psfhosted.org>
Message-ID: <1574210298.73.0.172748620197.issue38859@roundup.psfhosted.org>


Change by Jason Fried <me at jasonfried.info>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38859>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:42:52 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 20 Nov 2019 00:42:52 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1574210572.41.0.506541746844.issue36287@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

No objections from me assuming you are going forward along the way proposed by Serhiy (i.e. only skip values for certain fields if value is the default, not a blanket skip for all Nones and empty lists).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:49:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 00:49:36 +0000
Subject: [issue36710] Pass _PyRuntimeState as an argument rather than using
 the _PyRuntime global variable
In-Reply-To: <1556110680.79.0.127639989845.issue36710@roundup.psfhosted.org>
Message-ID: <1574210976.08.0.125961608315.issue36710@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2e96906da764402b4c8062dbf99171ca506f9e12 by Victor Stinner in branch 'master':
bpo-36710: Pass tstate parameter to GC collect() (GH-17267)
https://github.com/python/cpython/commit/2e96906da764402b4c8062dbf99171ca506f9e12


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36710>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:51:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 00:51:21 +0000
Subject: [issue36710] Pass _PyRuntimeState as an argument rather than using
 the _PyRuntime global variable
In-Reply-To: <1556110680.79.0.127639989845.issue36710@roundup.psfhosted.org>
Message-ID: <1574211081.01.0.891690186884.issue36710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16763
pull_request: https://github.com/python/cpython/pull/17270

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36710>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:59:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 00:59:40 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574211580.62.0.574592408037.issue38823@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 33b671e72450bf4b5a946ce0dde6b7fe21150108 by Victor Stinner (Brandt Bucher) in branch 'master':
bpo-38823: Fix refleak in marshal init error path (GH-17260)
https://github.com/python/cpython/commit/33b671e72450bf4b5a946ce0dde6b7fe21150108


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:59:46 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 00:59:46 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574211586.38.0.56867227845.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16764
pull_request: https://github.com/python/cpython/pull/17271

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 19:59:53 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 00:59:53 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574211593.33.0.105575173632.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16765
pull_request: https://github.com/python/cpython/pull/17272

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 20:01:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 01:01:39 +0000
Subject: [issue37957] Allow regrtest to receive a file with test (and
 subtests) to ignore
In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org>
Message-ID: <1574211699.5.0.470344579197.issue37957@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm trying to keep regrtest in sync between 3.7, 3.8 and master branches. Maybe backport this change to 3.7 and 3.8 branches once buildbots validated the change? I'm keeping them in sync mostly to make bugfixes easier, but also to make my life easier when I debug issues in 3.7 or 3.8 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37957>
_______________________________________

From report at bugs.python.org  Tue Nov 19 20:02:51 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 20 Nov 2019 01:02:51 +0000
Subject: [issue37957] Allow regrtest to receive a file with test (and
 subtests) to ignore
In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org>
Message-ID: <1574211771.5.0.441475619044.issue37957@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ok, I reopen until the backports

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37957>
_______________________________________

From report at bugs.python.org  Tue Nov 19 20:28:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 01:28:11 +0000
Subject: [issue36710] Pass _PyRuntimeState as an argument rather than using
 the _PyRuntime global variable
In-Reply-To: <1556110680.79.0.127639989845.issue36710@roundup.psfhosted.org>
Message-ID: <1574213291.24.0.821073448147.issue36710@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 01b1cc12e7c6a3d6a3d27ba7c731687d57aae92a by Victor Stinner in branch 'master':
bpo-36710: Add PyInterpreterState.runtime field (GH-17270)
https://github.com/python/cpython/commit/01b1cc12e7c6a3d6a3d27ba7c731687d57aae92a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36710>
_______________________________________

From report at bugs.python.org  Tue Nov 19 20:33:40 2019
From: report at bugs.python.org (David Cuthbert)
Date: Wed, 20 Nov 2019 01:33:40 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574213620.19.0.794573550912.issue37228@roundup.psfhosted.org>


David Cuthbert <dacut at kanga.org> added the comment:

FreeBSD 12.1 and MacOS 10.15.1 (Catalina) appear to have saner and safer behavior.

Both require the use of SO_REUSEPORT for this behavior to happen as well. FreeBSD also requires the UID to be the same or 0 for subsequent processes to make the bind() call. I'll call this out as being Linux-specific in the deprecation message for now. (I don't have an AIX, HP-UX, or Solaris system handy to test, nor do I really want one if I'm being honest. :-) .)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Tue Nov 19 20:37:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 01:37:13 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574213833.72.0.272803856564.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16766
pull_request: https://github.com/python/cpython/pull/17273

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Tue Nov 19 20:42:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 01:42:14 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574214134.79.0.692538177161.issue38823@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The Azure Pipelines are sick tonight (unable to publish test results). PR #17272 and PR #17271 are blocked by this CI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Tue Nov 19 20:50:33 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Nov 2019 01:50:33 +0000
Subject: [issue38847] AST Optimization for Single Target List Comprehension
In-Reply-To: <1574165659.02.0.559214725778.issue38847@roundup.psfhosted.org>
Message-ID: <1574214633.55.0.265863358549.issue38847@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Pablo.

Thank you for the suggestion though.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38847>
_______________________________________

From report at bugs.python.org  Tue Nov 19 20:51:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 01:51:33 +0000
Subject: [issue38835] pyfpe.h: Exclude PyFPE_START_PROTECT and
 PyFPE_END_PROTECT from the Py_LIMITED_API
In-Reply-To: <1574087751.21.0.402733884196.issue38835@roundup.psfhosted.org>
Message-ID: <1574214693.63.0.0525115643108.issue38835@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset be143ec99674ba38c5811f34cdb85ef39c2dc8f8 by Victor Stinner in branch 'master':
bpo-38835: Don't use PyFPE_START_PROTECT and PyFPE_END_PROTECT (GH-17231)
https://github.com/python/cpython/commit/be143ec99674ba38c5811f34cdb85ef39c2dc8f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38835>
_______________________________________

From report at bugs.python.org  Tue Nov 19 21:34:04 2019
From: report at bugs.python.org (Justin Capella)
Date: Wed, 20 Nov 2019 02:34:04 +0000
Subject: [issue38860] GenericPyCData_new does not invoke new or init
Message-ID: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>


New submission from Justin Capella <justincapella at gmail.com>:

When subclassing the ctypes.Structure class, __new__ and __init__ are not invoked when using the inherited classmethod from_buffer_copy to create the object.

I think this is because tp_alloc is ultimately used by GenericPyCData_new when creating the object using the from_buffer_copy classmethod inherited from _CData.

https://github.com/python/cpython/blob/be143ec99674ba38c5811f34cdb85ef39c2dc8f8/Modules/_ctypes/_ctypes.c#L3202

Expected behavior: creation of Structure subclass object would invoke __new__ and possibly __init__.

----------
components: ctypes
files: ctypesnew.py
messages: 357022
nosy: b1tninja
priority: normal
severity: normal
status: open
title: GenericPyCData_new does not invoke new or init
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48723/ctypesnew.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38860>
_______________________________________

From report at bugs.python.org  Tue Nov 19 21:52:22 2019
From: report at bugs.python.org (John Goerzen)
Date: Wed, 20 Nov 2019 02:52:22 +0000
Subject: [issue38861] zipfile: Corrupts filenames containing non-UTF8
 characters
Message-ID: <1574218342.23.0.381286067182.issue38861@roundup.psfhosted.org>


New submission from John Goerzen <jgoerzen at users.sourceforge.net>:

The zipfile.py standard library component contains a number of pieces of questionable handling of non-UTF8 filenames.  As the ZIP file format predated Unicode by a significant number of years, this is actually fairly common with older code.

Here is a very simple reproduction case. 

mkdir t
cd t
echo hi > `printf 'test\xf7.txt'`
cd ..
zip -9r t.zip t

0xf7 is the division sign in ISO-8859-1.  In the "t" directory, "ls | hd" displays:

00000000  74 65 73 74 f7 2e 74 78  74 0a                    |test..txt.|
0000000a


Now, here's a simple Python3 program:

import zipfile

z = zipfile.ZipFile("t.zip")
z.extractall()

If you run this on the relevant ZIP file, the 0xf7 character is replaced with a Unicode sequence; "ls | hd" now displays:

00000000  74 65 73 74 e2 89 88 2e  74 78 74 0a              |test....txt.|
0000000c

The impact within Python programs is equally bad.  Fundamentally, the zipfile interface is broken; it should not try to decode filenames into strings and should instead treat them as bytes and leave potential decoding up to applications.  It appears to try, down various code paths, to decode filenames as ascii, cp437, or utf-8.  However, the ZIP file format was often used on Unix systems as well, which didn't tend to use cp437 (iso-8859-* was more common).  In short, there is no way that zipfile.py can reliably guess the encoding of a filename in a ZIP file, so it is a data-loss bug that it attempts and fails to do so.  It is a further bug that extractall mangles filenames; unzip(1) is perfectly capable of extracting these files correctly.  I'm attaching this zip file for reference.

At the very least, zipfile should provide a bytes interface for filenames for people that care about correctness.

----------
files: t.zip
messages: 357023
nosy: jgoerzen
priority: normal
severity: normal
status: open
title: zipfile: Corrupts filenames containing non-UTF8 characters
type: behavior
Added file: https://bugs.python.org/file48724/t.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38861>
_______________________________________

From report at bugs.python.org  Tue Nov 19 22:10:10 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 20 Nov 2019 03:10:10 +0000
Subject: [issue23706] pathlib.Path.write_text should include a newline argument
In-Reply-To: <1426757561.17.0.481870343329.issue23706@psf.upfronthosting.co.za>
Message-ID: <1574219410.83.0.996469041139.issue23706@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
nosy: +uranusjr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23706>
_______________________________________

From report at bugs.python.org  Tue Nov 19 22:49:39 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Nov 2019 03:49:39 +0000
Subject: [issue38853] set.repr breaches docstring contract
In-Reply-To: <1574198861.64.0.9694268826.issue38853@roundup.psfhosted.org>
Message-ID: <1574221779.47.0.117301768116.issue38853@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

To be clear, the docstring is explicitly disclaiming any ordering contract. If you're reading "unordered" as meaning "not reordered" (like a list or tuple, where the elements appear in insertion order), that's not what "unordered" means here. It means "arbitrary order". As it happens, the hashcodes of small integers correspond to their numerical values, (mostly, -1 is a special case), so if no collisions occur and the numbers are sequential, the ordering will often look like it was sorted in semi-numerical order, as in your case.

That doesn't mean it's performing sorting, it just means that's how the hashes happened to distribute themselves across the buckets in the set. A different test case with slightly more distributed numbers won't create the impression of sorting:

>>> print({-5, -1, 13, 17})
{17, -5, 13, -1}

For the record, I chose that case to use CPython implementation details to produce a really unordered result (all the numbers are bucketed mod 8 in a set that small, and this produces no collisions, with all values mod 8 different from the raw value). On other versions of CPython, or alternate interpreters, both your case and mine could easily come out differently.

Point is, this isn't a bug, just a quirk in the small int hash codes.

Steven: I think they thought it was sorted in some string-related way, explaining (to them) why -1 was out of place (mind you, if it were string sorted, -1 would come first since the minus sign is ASCIIbetically first, 19 would fall between 1 and 2, and 25 between 2 and 3, so it doesn't hold up).

There's no bug here.

----------
nosy: +josh.r
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38853>
_______________________________________

From report at bugs.python.org  Tue Nov 19 22:53:49 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Nov 2019 03:53:49 +0000
Subject: [issue38855] test_unpack.py does not catch the unpacking of a set
In-Reply-To: <1574199866.94.0.505972513072.issue38855@roundup.psfhosted.org>
Message-ID: <1574222029.2.0.0309593302797.issue38855@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

It's not clear what you're asking for here.  Your example works, though the contents of `a` and `c` will each be an arbitrary member of S and `b` the rest of the members of S and you have no guarantee of what you'll get.  If you want to be sure of what each name will be attached to, just do `a, *b, c = sorted(S)`.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38855>
_______________________________________

From report at bugs.python.org  Tue Nov 19 23:13:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Nov 2019 04:13:55 +0000
Subject: [issue37367] octal escapes applied inconsistently throughout the
 interpreter and lib
In-Reply-To: <1561146368.97.0.686299796922.issue37367@roundup.psfhosted.org>
Message-ID: <1574223235.32.0.756680611477.issue37367@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I can't find who wrote this block treating octal escapes beginning with 4-7 the same as those beginning with 0-3. 

        case '0': case '1': case '2': case '3':
        case '4': case '5': case '6': case '7':
            c = s[-1] - '0';
            if (s < end && '0' <= *s && *s <= '7') {
                c = (c<<3) + *s++ - '0';
                if (s < end && '0' <= *s && *s <= '7')
                    c = (c<<3) + *s++ - '0';
            }
            *p++ = c;
            break;

Antoine Pitrou merged from somewhere in 2010 and Christiqn Heimes renamed something in 2008 and before that, ???. Guido wrote the initial bytesobject.c in 2006.

Guido, do you agree that the current behavior, treating the same int differently when input into a bytes in different ways, is a bug, and if so, should we backport the fix?

>>> b'\407'
b'\x07'
>>> bytes((0o407,))
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in <module>
    bytes((0o407,))
ValueError: bytes must be in range(0, 256)

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37367>
_______________________________________

From report at bugs.python.org  Tue Nov 19 23:15:48 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Nov 2019 04:15:48 +0000
Subject: [issue38765] `ast.AST._attributes` is used by `ast.dump()` but not
 documented
In-Reply-To: <1573482663.72.0.733055997415.issue38765@roundup.psfhosted.org>
Message-ID: <1574223348.76.0.68224253147.issue38765@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Nosying the ast experts, which I meant to do before.

----------
nosy: +benjamin.peterson, brett.cannon, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38765>
_______________________________________

From report at bugs.python.org  Tue Nov 19 23:39:20 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Nov 2019 04:39:20 +0000
Subject: [issue38712] add signal.pidfd_send_signal
In-Reply-To: <1573016926.97.0.785552850869.issue38712@roundup.psfhosted.org>
Message-ID: <1574224760.83.0.418809472353.issue38712@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 7483451577916e693af6d20cf520b2cc7e2174d2 by Benjamin Peterson in branch 'master':
closes bpo-38712: Add signal.pidfd_send_signal. (GH-17070)
https://github.com/python/cpython/commit/7483451577916e693af6d20cf520b2cc7e2174d2


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38712>
_______________________________________

From report at bugs.python.org  Wed Nov 20 00:51:53 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 20 Nov 2019 05:51:53 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574229113.6.0.00197704894577.issue38823@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Thanks Victor. These obviously aren?t urgent, so feel free to return to them whenever?s convenient.

I also pinged you on #17235 (_tracemalloc) too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:06:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Nov 2019 06:06:45 +0000
Subject: [issue38862] IDLE: Include end whitespace in whitespace fix.
Message-ID: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Format => Strip Trailing Whitespace should strip extra newlines at the end of the file after stripping each line, and make sure that there is at least one.  The latter is done when saving, and that code can be reused.

----------
assignee: terry.reedy
components: IDLE
messages: 357030
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Include end whitespace in whitespace fix.
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:08:14 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Nov 2019 06:08:14 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574230094.87.0.613715640323.issue38862@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: IDLE: Include end whitespace in whitespace fix. -> IDLE: Include end newlines in whitespace fix.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:09:39 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 20 Nov 2019 06:09:39 +0000
Subject: [issue37367] octal escapes applied inconsistently throughout the
 interpreter and lib
In-Reply-To: <1561146368.97.0.686299796922.issue37367@roundup.psfhosted.org>
Message-ID: <1574230179.62.0.969234394271.issue37367@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

For sure the Python tokenizer/parser should reject octal escapes that produce values >= 256. Certainly in bytes strings. Probably also in text strings (nobody using Unicode thinks in octal). This is ancient behavior though (it's the same in 2.7) so it may require a deprecation for the text string case. (For byte strings, it should become an error in 3.9 -- dropping the top bit is nonsensical.)

The regex parser should not be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37367>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:16:52 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Nov 2019 06:16:52 +0000
Subject: [issue33046] IDLE option to strip trailing whitespace automatically
 on save
In-Reply-To: <1520745248.32.0.467229070634.issue33046@psf.upfronthosting.co.za>
Message-ID: <1574230612.32.0.918680275587.issue33046@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I want to add EOF newline stripping before making this automatic.  Otherwise, the new feature will give people a false sense that it is all taken care of.  I opened #38862 and hope to do it tomorrow.

I may then merge Zackary's PR with any still edits of existing code,  and make fixing the General tab and its Help page a new PR.

I am thinking to make the per file option toggle, under Options, analogous to Add/Hide Linenumbers, be 'Fix/Leave Whitespace' + 'on Save' if it does not make box too wide.

----------
dependencies: +IDLE: Include end newlines in whitespace fix.
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33046>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:18:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Nov 2019 06:18:54 +0000
Subject: [issue38636] IDLE regression: toggle tabs and change indent width
 functions
In-Reply-To: <1572383648.52.0.228001978432.issue38636@roundup.psfhosted.org>
Message-ID: <1574230734.67.0.219464616089.issue38636@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset b8462477bfd01ff21461065d5063e6b0238ca809 by Terry Jan Reedy in branch 'master':
bpo-38636: Fix IDLE tab toggle and file indent width (GH-17008)
https://github.com/python/cpython/commit/b8462477bfd01ff21461065d5063e6b0238ca809


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38636>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:19:01 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 06:19:01 +0000
Subject: [issue38636] IDLE regression: toggle tabs and change indent width
 functions
In-Reply-To: <1572383648.52.0.228001978432.issue38636@roundup.psfhosted.org>
Message-ID: <1574230741.13.0.127565622512.issue38636@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16767
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/17274

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38636>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:19:08 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 06:19:08 +0000
Subject: [issue38636] IDLE regression: toggle tabs and change indent width
 functions
In-Reply-To: <1572383648.52.0.228001978432.issue38636@roundup.psfhosted.org>
Message-ID: <1574230748.24.0.547191199339.issue38636@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16768
pull_request: https://github.com/python/cpython/pull/17275

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38636>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:37:13 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 06:37:13 +0000
Subject: [issue38636] IDLE regression: toggle tabs and change indent width
 functions
In-Reply-To: <1572383648.52.0.228001978432.issue38636@roundup.psfhosted.org>
Message-ID: <1574231833.28.0.210834578895.issue38636@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 755caaa753577b907bb7e94560f8adf5eb694d6b by Miss Islington (bot) in branch '3.7':
bpo-38636: Fix IDLE tab toggle and file indent width (GH-17008)
https://github.com/python/cpython/commit/755caaa753577b907bb7e94560f8adf5eb694d6b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38636>
_______________________________________

From report at bugs.python.org  Wed Nov 20 01:37:50 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 06:37:50 +0000
Subject: [issue38636] IDLE regression: toggle tabs and change indent width
 functions
In-Reply-To: <1572383648.52.0.228001978432.issue38636@roundup.psfhosted.org>
Message-ID: <1574231870.68.0.619868238335.issue38636@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 132243957ce834cf5ffced4bf8e39d00f6e34e5f by Miss Islington (bot) in branch '3.8':
bpo-38636: Fix IDLE tab toggle and file indent width (GH-17008)
https://github.com/python/cpython/commit/132243957ce834cf5ffced4bf8e39d00f6e34e5f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38636>
_______________________________________

From report at bugs.python.org  Wed Nov 20 03:00:07 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 20 Nov 2019 08:00:07 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574236807.85.0.213478760074.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16769
pull_request: https://github.com/python/cpython/pull/17276

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 03:00:45 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Nov 2019 08:00:45 +0000
Subject: [issue38855] test_unpack.py does not catch the unpacking of a set
In-Reply-To: <1574199866.94.0.505972513072.issue38855@roundup.psfhosted.org>
Message-ID: <1574236845.85.0.582511833911.issue38855@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm also unclear on what you're looking for.  Unpacking is documented to allow any iterable.  This includes all kinds of potentially weird but potentially useful cases including unordered collections, strings, files, etc.  These behaviors are unlikely to change.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38855>
_______________________________________

From report at bugs.python.org  Wed Nov 20 03:03:48 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Nov 2019 08:03:48 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1574237028.3.0.290438524435.issue38843@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

For now, we should at least document that, "If the preexisting namespace has an attribute set, the action default will not over write it."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38843>
_______________________________________

From report at bugs.python.org  Wed Nov 20 03:06:33 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Nov 2019 08:06:33 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1574237193.34.0.976963669347.issue38843@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Ivan, you don't need to specify default values to have typing.  This will suffice:

    class CliArgs(object):
        foo: Optional[str]
        bar: int
        baz: float

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38843>
_______________________________________

From report at bugs.python.org  Wed Nov 20 03:26:07 2019
From: report at bugs.python.org (David Cuthbert)
Date: Wed, 20 Nov 2019 08:26:07 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574238367.08.0.613741251493.issue37228@roundup.psfhosted.org>


David Cuthbert <dacut at kanga.org> added the comment:

Alright -- my first stab at the DeprecationWarning in 3.6.
https://github.com/dacut/cpython/commit/6a1e261678975e2c70ec6b5e98e8affa28702312

Please critique away, and don't fret about bruising my ego. :-)

Is there a more idiomatic way of getting a warning to show up against the first callee that's not in the current module? I'm not enamored of the monstrosity I'm put together around line 918 of base_events.py (but less enamored about displaying warnings that the user is going to tear their hair out over trying to find the offending source line):

https://github.com/dacut/cpython/commit/6a1e261678975e2c70ec6b5e98e8affa28702312#diff-08afa52ab2b1511bee8527814ad44d80R918

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 03:30:29 2019
From: report at bugs.python.org (Ronald Evers)
Date: Wed, 20 Nov 2019 08:30:29 +0000
Subject: [issue36041] email: folding of quoted string in display_name violates
 RFC
In-Reply-To: <1550594739.09.0.990893515193.issue36041@roundup.psfhosted.org>
Message-ID: <1574238629.78.0.910336829024.issue36041@roundup.psfhosted.org>


Change by Ronald Evers <ronald at ch10.nl>:


----------
nosy: +ronaldevers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36041>
_______________________________________

From report at bugs.python.org  Wed Nov 20 03:33:51 2019
From: report at bugs.python.org (PCManticore)
Date: Wed, 20 Nov 2019 08:33:51 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1574238831.76.0.0335704323107.issue38698@roundup.psfhosted.org>


Change by PCManticore <pcmanticore at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38698>
_______________________________________

From report at bugs.python.org  Wed Nov 20 03:59:03 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Wed, 20 Nov 2019 08:59:03 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574240343.54.0.689889801982.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

David, in terms of documentation changes and the emitted deprecation warning itself, I think it would be appropriate to instruct that please set the parameter explicitly to True or False to silence the warning AND point out that setting it to True has significant security and previously incorrectly documented functional implications.

Now your updated docs and warning read more like we are working around a Linux security bug which is not really the case - this behavior was intentionally added to the kernels and some of the code I do for a living relies on it to work properly. Admittedly the restriction of having the same UID wouldn't hurt.

And browsing again through the hits to my github searches, it makes me cringe how many people are already explicitly setting reuse_address=True in their code because the current documentation mistakenly makes it seem harmless and desirable. Makes me wonder if we need to put out a CVE? At the very least, I will be putting in PRs to the asyncio packages that I myself use and understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 04:14:13 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 20 Nov 2019 09:14:13 +0000
Subject: [issue37367] octal escapes applied inconsistently throughout the
 interpreter and lib
In-Reply-To: <1561146368.97.0.686299796922.issue37367@roundup.psfhosted.org>
Message-ID: <1574241253.4.0.721351237068.issue37367@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Alright, so let's push through the existing PR for rejecting such octal escapes in byte strings.

We'll also need another PR for raising a deprecation warning for such octal escapes in strings.

----------
keywords: +easy, easy (C)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37367>
_______________________________________

From report at bugs.python.org  Wed Nov 20 04:21:02 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 20 Nov 2019 09:21:02 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574241662.49.0.53991512121.issue37228@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

> Now your updated docs and warning read more like we are working around a Linux security bug which is not really the case - this behavior was intentionally added to the kernels and some of the code I do for a living relies on it to work properly. Admittedly the restriction of having the same UID wouldn't hurt.

I think you can use SO_REUSEPORT instead, and for UDP sockets it's identical to SO_REUSEADDR except with the same-UID restriction added?

If that's right then it might make sense to unconditionally switch SO_REUSEADDR -> SO_REUSEPORT, even in existing Python releases ? on the theory that it fixes the main security hole, while being back-compatible enough to be acceptable for a point release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 04:36:04 2019
From: report at bugs.python.org (Jackson Riley)
Date: Wed, 20 Nov 2019 09:36:04 +0000
Subject: [issue17306] Improve the way abstract base classes are shown in help()
In-Reply-To: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za>
Message-ID: <1574242564.11.0.0477483440882.issue17306@roundup.psfhosted.org>


Change by Jackson Riley <jacriley at cisco.com>:


----------
pull_requests: +16771
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17278

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17306>
_______________________________________

From report at bugs.python.org  Wed Nov 20 04:38:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 09:38:39 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574242719.18.0.462646002192.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7eee5beaf87be898a679278c480e8dd0df76d351 by Victor Stinner in branch 'master':
bpo-38858: Factorize Py_EndInterpreter() code (GH-17273)
https://github.com/python/cpython/commit/7eee5beaf87be898a679278c480e8dd0df76d351


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 04:45:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 09:45:01 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574243101.31.0.753830839898.issue36854@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16772
pull_request: https://github.com/python/cpython/pull/17279

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Wed Nov 20 04:56:37 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 09:56:37 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574243797.02.0.585317307966.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16773
pull_request: https://github.com/python/cpython/pull/17280

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 04:57:16 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 09:57:16 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574243836.11.0.807017819789.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16774
pull_request: https://github.com/python/cpython/pull/17281

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:00:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 10:00:36 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574244036.21.0.190871546982.issue38823@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d51a363a4379385fdfe9c09a56324631465ede29 by Victor Stinner (Brandt Bucher) in branch 'master':
bpo-38823: Fix refleak in _tracemalloc init error handling (GH-17235)
https://github.com/python/cpython/commit/d51a363a4379385fdfe9c09a56324631465ede29


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:00:50 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 10:00:50 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574244050.23.0.338856233633.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16775
pull_request: https://github.com/python/cpython/pull/17282

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:00:57 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 10:00:57 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574244057.01.0.884620095113.issue38823@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16776
pull_request: https://github.com/python/cpython/pull/17283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:04:41 2019
From: report at bugs.python.org (Jackson Riley)
Date: Wed, 20 Nov 2019 10:04:41 +0000
Subject: [issue34716] MagicMock.__divmod__ should return a pair
In-Reply-To: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>
Message-ID: <1574244281.89.0.881197492219.issue34716@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Ah thank you Vedran, that makes sense.
In that case, I think I'll make a start on implementing Serhiy's second suggestion - returning a pair of MagicMock instances when MagicMock.__divmod__ is called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34716>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:09:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 10:09:18 +0000
Subject: [issue37340] remove free_list for bound method objects
In-Reply-To: <1560948861.51.0.564500331945.issue37340@roundup.psfhosted.org>
Message-ID: <1574244558.87.0.00243135987298.issue37340@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16777
pull_request: https://github.com/python/cpython/pull/17284

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37340>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:15:25 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 10:15:25 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574244925.52.0.402852206943.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 63f09e7628bd72f1bb2106226655b1f775757806 by Miss Islington (bot) in branch '3.7':
bpo-38823: Fix refleak in marshal init error path (GH-17260)
https://github.com/python/cpython/commit/63f09e7628bd72f1bb2106226655b1f775757806


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:16:10 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 10:16:10 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574244970.1.0.854667712971.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2ea4c37c1ecf05a8495211d55ed6888439b1b9cf by Miss Islington (bot) in branch '3.8':
bpo-38823: Fix refleak in marshal init error path (GH-17260)
https://github.com/python/cpython/commit/2ea4c37c1ecf05a8495211d55ed6888439b1b9cf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:17:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 10:17:22 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574245042.01.0.0315439367158.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9da7430675ceaeae5abeb9c9f7cd552b71b3a93a by Victor Stinner in branch 'master':
bpo-36854: Clear the current thread later (GH-17279)
https://github.com/python/cpython/commit/9da7430675ceaeae5abeb9c9f7cd552b71b3a93a


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:17:55 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 20 Nov 2019 10:17:55 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574245075.45.0.332956393488.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I think you can use SO_REUSEPORT instead, and for UDP sockets it's identical to SO_REUSEADDR except with the same-UID restriction added?

> If that's right then it might make sense to unconditionally switch SO_REUSEADDR -> SO_REUSEPORT, even in existing Python releases ? on the theory that it fixes the main security hole, while being back-compatible enough to be acceptable for a point release.

+1, I think this is the best proposal so far. From my reading of http://man7.org/linux/man-pages/man7/socket.7.html (specifically the SO_REUSEPORT section) this seems correct.


Emitting a `DeprecationWarning` and a delayed change for the default value of `reuse_address` not only leaves open a security concern for the near future (until the change is actually made); it also has a maintenance cost for users and libraries. Also, changing the default value wouldn't address the problem for those who explicitly specified `reuse_address=True`.

The way I see it, changing `socket.SO_REUSEADDR` to `socket.SO_REUSEPORT` would apply the security fix more rapidly, fix the issue for more users, and have a much lower (if not zero) maintenance cost for the majority of users. 

This would also allow us to apply the change to more previous Python versions, since it doesn't affect asyncio's public API. If we're just changing `socket.SO_REUSEADDR` to `socket.SO_REUSEPORT` at: 

https://github.com/python/cpython/blob/7eee5beaf87be898a679278c480e8dd0df76d351/Lib/asyncio/base_events.py#L1321

We should be able to apply to change starting from Python 3.5+, no? I should have the time to open a PR with backports within the next day if needed, particularly since it's a fairly small code change. I'll leave that up to Nathaniel though since he came up with the idea, let me know either way.

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:23:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 10:23:35 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574245415.18.0.784669602014.issue36854@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16778
pull_request: https://github.com/python/cpython/pull/17285

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:27:07 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 10:27:07 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574245627.47.0.352941668046.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset daf7a082b20e59a0518cda1500add42c36ab058f by Miss Islington (bot) in branch '3.8':
bpo-38823: Fix refleak in _tracemalloc init error handling (GH-17235)
https://github.com/python/cpython/commit/daf7a082b20e59a0518cda1500add42c36ab058f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:27:07 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 10:27:07 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574245627.65.0.343011109145.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1d7245c3e0cfe4508855c5025b25d8894155ecc5 by Miss Islington (bot) in branch '3.7':
bpo-38823: Fix refleak in _tracemalloc init error handling (GH-17235)
https://github.com/python/cpython/commit/1d7245c3e0cfe4508855c5025b25d8894155ecc5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:27:07 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 10:27:07 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574245627.47.0.352941668046.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset daf7a082b20e59a0518cda1500add42c36ab058f by Miss Islington (bot) in branch '3.8':
bpo-38823: Fix refleak in _tracemalloc init error handling (GH-17235)
https://github.com/python/cpython/commit/daf7a082b20e59a0518cda1500add42c36ab058f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:44:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 10:44:49 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574246689.0.0.924523397391.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16779
pull_request: https://github.com/python/cpython/pull/17286

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:46:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 10:46:28 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574246788.29.0.456259034239.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset ef5aa9af7c7e493402ac62009e4400aed7c3d54e by Victor Stinner in branch 'master':
> bpo-38858: Reorganize pycore_init_types() (GH-17265)

This change introduced a reference leak:

https://buildbot.python.org/all/#builders/80/builds/771

test_atexit leaked [792, 792, 792] references, sum=2376
test_capi leaked [528, 528, 528] references, sum=1584
test__xxsubinterpreters leaked [17954, 17952, 17954] references, sum=53860
test_threading leaked [792, 792, 792] references, sum=2376

It should be fixed by PR 17286.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 05:48:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 10:48:22 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574246902.32.0.08997761696.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 67e0de6f0b060ac8f373952f0ca4b3117ad5b611 by Victor Stinner in branch 'master':
bpo-36854: gcmodule.c gets its state from tstate (GH-17285)
https://github.com/python/cpython/commit/67e0de6f0b060ac8f373952f0ca4b3117ad5b611


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:03:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:03:57 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574247837.4.0.0613138809881.issue36854@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16780
pull_request: https://github.com/python/cpython/pull/17287

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:07:59 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 20 Nov 2019 11:07:59 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574248079.01.0.50520078536.issue38692@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I have consistent behavior on Fedora 32 in mock [0] and podman [1]. Wanted to test docker as well, but my docker setup is currently broken.

# python3.9
Python 3.9.0a1 (default, Nov 20 2019, 00:00:00) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.pidfd_open(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
PermissionError: [Errno 1] Operation not permitted


=> the test fails.


[0] https://github.com/rpm-software-management/rpm
[1] https://podman.io/

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:08:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:08:41 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574248121.95.0.73317785924.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e7e699e4df73420ddccaa0057cd07ebb3b590b9b by Victor Stinner in branch 'master':
bpo-38858: Fix reference leak in pycore_init_types() (GH-17286)
https://github.com/python/cpython/commit/e7e699e4df73420ddccaa0057cd07ebb3b590b9b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:08:59 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 20 Nov 2019 11:08:59 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574248139.11.0.33087203422.issue38692@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

BTW my kernel is: 5.3.7-301.fc31.x86_64

Sorry for commenting twice, I forgot to mention that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:12:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:12:04 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574248324.97.0.62013495387.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> BTW my kernel is: 5.3.7-301.fc31.x86_64

I get a different error on Fedora 31 with Linux kernel 5.3.9-300.fc31.x86_64:

$ ./python
Python 3.9.0a1+ (heads/method_freelist:e34fa9b8d7, Nov 20 2019, 12:09:54) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
>>> import os
>>> os.pidfd_open(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:12:10 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 20 Nov 2019 11:12:10 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574248330.37.0.891624349653.issue38692@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

I don't know about podman, but it sounds like mock and docker both use buggy sandboxing: https://bugzilla.redhat.com/show_bug.cgi?id=1770154

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:17:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:17:13 +0000
Subject: [issue38835] pyfpe.h: Exclude PyFPE_START_PROTECT and
 PyFPE_END_PROTECT from the Py_LIMITED_API
In-Reply-To: <1574087751.21.0.402733884196.issue38835@roundup.psfhosted.org>
Message-ID: <1574248633.67.0.837081818818.issue38835@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 488d02a24142948bfb1fafd19fa48e61fcbbabc5 by Victor Stinner in branch 'master':
bpo-38835: Exclude PyFPE macros from the stable API (GH-17228)
https://github.com/python/cpython/commit/488d02a24142948bfb1fafd19fa48e61fcbbabc5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38835>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:19:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:19:41 +0000
Subject: [issue38835] pyfpe.h: Exclude PyFPE_START_PROTECT and
 PyFPE_END_PROTECT from the Py_LIMITED_API
In-Reply-To: <1574087751.21.0.402733884196.issue38835@roundup.psfhosted.org>
Message-ID: <1574248781.81.0.0994039593531.issue38835@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Pablo asked on PR 17231:
> Do you want to left the empty macro in Include/pyfpe.h?

https://github.com/python/cpython/pull/17231#pullrequestreview-319366200

I replied:
> If someone wants to remove them, I would suggest to first deprecate them, and wait at least one Python release before removing them. And do that in a separated issue: https://bugs.python.org/issue38835 title is "pyfpe.h: Exclude PyFPE_START_PROTECT and PyFPE_END_PROTECT from the Py_LIMITED_API", it's not directly related :-)

https://github.com/python/cpython/pull/17231#issuecomment-555732122

In short, I'm not interested to remove it right now :-)

The initial issue has been fixed, so I close the issue. Thanks for your review Pablo ;-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38835>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:25:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:25:55 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574249155.26.0.220645552409.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7247407c35330f3f6292f1d40606b7ba6afd5700 by Victor Stinner in branch 'master':
bpo-36854: Move _PyRuntimeState.gc to PyInterpreterState (GH-17287)
https://github.com/python/cpython/commit/7247407c35330f3f6292f1d40606b7ba6afd5700


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:27:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:27:55 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574249275.78.0.355944984993.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's now done in the future Python 3.9!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:28:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:28:00 +0000
Subject: [issue24554] GC should happen when a subinterpreter is destroyed
In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za>
Message-ID: <1574249280.36.0.24754426316.issue24554@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

bpo-36854 has been fixed, so it's time to reconsider fixing this issue :-)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24554>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:55:54 2019
From: report at bugs.python.org (=?utf-8?q?Jan_Huta=C5=99?=)
Date: Wed, 20 Nov 2019 11:55:54 +0000
Subject: [issue9625] argparse: Problem with defaults for variable nargs when
 using choices
In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za>
Message-ID: <1574250954.15.0.923502030356.issue9625@roundup.psfhosted.org>


Jan Huta? <jhutar at gmail.com> added the comment:

I think there is a same issue with "nargs='+'" - if you are aware of the, please ignore me.

$ python3 --version
Python 3.7.5

With "choices=...", there seems to be a problem:


$ cat bbb.py 
#!/usr/bin/env python3

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('choices', nargs='*',
                    default=['a', 'b', 'c'],
                    choices=['a', 'b', 'c'])
args = parser.parse_args()

print(args)
$ ./bbb.py 
usage: bbb.py [-h] [{a,b,c} [{a,b,c} ...]]
bbb.py: error: argument choices: invalid choice: ['a', 'b', 'c'] (choose from 'a', 'b', 'c')
$ ./bbb.py a c
Namespace(choices=['a', 'c'])


but without choices it works:


$ cat bbb.py 
#!/usr/bin/env python3

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('choices', nargs='*',
                    default=['a', 'b', 'c'])
args = parser.parse_args()

print(args)
$ ./bbb.py 
Namespace(choices=['a', 'b', 'c'])
$ ./bbb.py a c
Namespace(choices=['a', 'c'])


As I said, if this is a known issue, I'm sorry for the noise.

----------
nosy: +Jan Huta?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9625>
_______________________________________

From report at bugs.python.org  Wed Nov 20 06:59:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 11:59:17 +0000
Subject: [issue37340] remove free_list for bound method objects
In-Reply-To: <1560948861.51.0.564500331945.issue37340@roundup.psfhosted.org>
Message-ID: <1574251157.79.0.106194820685.issue37340@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4dedd0f0ddc5a983a57bf0105eb34f948a91d2c4 by Victor Stinner in branch 'master':
bpo-37340: Remove PyMethod_ClearFreeList() and PyCFunction_ClearFreeList() (GH-17284)
https://github.com/python/cpython/commit/4dedd0f0ddc5a983a57bf0105eb34f948a91d2c4


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37340>
_______________________________________

From report at bugs.python.org  Wed Nov 20 07:04:46 2019
From: report at bugs.python.org (kim)
Date: Wed, 20 Nov 2019 12:04:46 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1574251486.0.0.673883074819.issue38576@roundup.psfhosted.org>


Change by kim <kimmo at suominen.com>:


----------
nosy: +kim

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Wed Nov 20 07:18:16 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Wed, 20 Nov 2019 12:18:16 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574252296.28.0.0872376390017.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

Going to SO_REUSEPORT will fix the security issue and emitting a deprecation warning for default value invocation will catch the eyes of some maintainers but it will not prevent what caused me to catch this issue in the first place - starting two processes (with same UID) accidentally listening on the same UDP port (in my case it was port 5060 as a default SIP port).

Since there already is a reuse_port parameter to create_datagram_endpoint(), I assume the proposal is to set default value for reuse_addresss=False and reuse_port=True? But if reuse_address is explicitly set to True, are we going to just set SO_REUSEPORT instead and always leave SO_REUSEADDR unset? This would leave the reuse_address parameter completely useless and still allow accidental port reuse.

What if I really do want SO_REUSEADDR? Ok I can create a socket separately, call setsockopt() on it and pass it as the sock parameter to create_datagram_endpoint(). 

Maybe I'm not fully grasping the proposal.. or maybe we should just deprecate reuse_port from both create_datagram_endpoint() and create_server() + reuse_addr from create_datagram_endpoint()? 

This would leave the TCP create_server() with the reuse_addr parameter, defaulting reasonably to True. To use TCP/UDP SO_REUSEPORT or UDP SO_REUSEADDR, the docs would tell you to bake your own socket with socket.socket(). Those few (like me) who really need the functionality can survive without all-in-one convenience functions on asyncio.loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 07:21:21 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Nov 2019 12:21:21 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574252481.23.0.235223460681.issue37228@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is another suggestion:

- make the "reuse_address" parameter a no-op, and raise an error when "reuse_address=True" is passed

- add a new "allow_multiple_bind=False" parameter that enables SO_REUSEPORT

- do that in 3.8 as well

This way we 1) solve the security issue 2) ensure that anyone that passed "reuse_address=True" explicitly is notified that they were doing something dangerous unwillingly.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 07:23:04 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Nov 2019 12:23:04 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574252584.91.0.386609167084.issue37228@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
Removed message: https://bugs.python.org/msg357067

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 07:25:15 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Nov 2019 12:25:15 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574252715.97.0.514600884668.issue37228@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

(previous message deleted, I hadn't noticed the "reuse_port" parameter)

My preference for create_datagram_endpoint() would be:

- make the "reuse_address" parameter a no-op, and raise an error when "reuse_address=True" is passed

- do that in 3.8 as well

This way we 1) solve the security issue 2) ensure that anyone that passed "reuse_address=True" explicitly is notified that they were doing something dangerous unwillingly.

And, yes, someone who really wants SO_REUSEADDR can set it manually, for example by calling `transport.get_extra_info('socket')`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 08:29:33 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 20 Nov 2019 13:29:33 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1574256573.21.0.292554163457.issue38821@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset be5c79e0338005d675a64ba6e5b137e850d556d1 by Tal Einat (Federico Bond) in branch 'master':
bpo-38821: Fix crash in argparse when using gettext (GH-17192)
https://github.com/python/cpython/commit/be5c79e0338005d675a64ba6e5b137e850d556d1


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Wed Nov 20 08:29:42 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 13:29:42 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1574256582.66.0.830977913492.issue38821@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16781
pull_request: https://github.com/python/cpython/pull/17288

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Wed Nov 20 08:30:03 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 13:30:03 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1574256603.6.0.288916349538.issue38821@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16782
pull_request: https://github.com/python/cpython/pull/17289

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Wed Nov 20 08:32:29 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 20 Nov 2019 13:32:29 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1574256749.18.0.181954400184.issue38821@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thanks for the report and the PR with a fix, Federico!

As discussed on in the PR comments, the PR did not include tests since there are currently no tests for argparse i18n. Please create a new issue for that, referencing this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Wed Nov 20 08:32:39 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 20 Nov 2019 13:32:39 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1574256759.63.0.595482878095.issue38821@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Wed Nov 20 08:48:24 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 13:48:24 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1574257704.51.0.700264422314.issue38821@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ecb2afc1bc1c2f3f9f99b09dd866100c3c7dcab7 by Miss Islington (bot) in branch '3.7':
bpo-38821: Fix crash in argparse when using gettext (GH-17192)
https://github.com/python/cpython/commit/ecb2afc1bc1c2f3f9f99b09dd866100c3c7dcab7


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Wed Nov 20 08:48:29 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 13:48:29 +0000
Subject: [issue38821] argparse calls ngettext with deprecated non-integer value
In-Reply-To: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>
Message-ID: <1574257709.26.0.677092787534.issue38821@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 836f137f7ae0799de937e5281cb1da2bfdb8a69d by Miss Islington (bot) in branch '3.8':
bpo-38821: Fix crash in argparse when using gettext (GH-17192)
https://github.com/python/cpython/commit/836f137f7ae0799de937e5281cb1da2bfdb8a69d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38821>
_______________________________________

From report at bugs.python.org  Wed Nov 20 08:52:37 2019
From: report at bugs.python.org (Justin Capella)
Date: Wed, 20 Nov 2019 13:52:37 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1574257957.47.0.879549477211.issue38576@roundup.psfhosted.org>


Justin Capella <justincapella at gmail.com> added the comment:

Can't see the specifics of that "restricted" redhat bug, but this was interesting bug and I wanted to ask if perhaps the domain in such cases should be IDN / punycoded ://xn--n28h.ws/ for example is ://?.la

----------
nosy: +b1tninja

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Wed Nov 20 09:01:19 2019
From: report at bugs.python.org (Siwon Kang)
Date: Wed, 20 Nov 2019 14:01:19 +0000
Subject: [issue38863] http.server is_cgi() does not correctly separate dir
Message-ID: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>


New submission from Siwon Kang <kkangshawn at gmail.com>:

is_cgi() in CGIHTTPRequestHandler class separates given path into (dir, rest) then checks if dir is in cgi_directories. However, it divides based on the first seen '/', multi-level directories like /sub/dir/cgi-bin/hello.py is divided into head=/sub, rest=dir/cgi-bin/hello.py then check whether '/sub' exists in cgi_directories = [..., '/sub/dir/cgi-bin'].
If the function divides by last seen '/', it works correctly as head=/sub/dir/cgi-bin, rest=hello.py

----------
components: Library (Lib)
files: sample.tar.xz
messages: 357074
nosy: kkangshawn
priority: normal
severity: normal
status: open
title: http.server is_cgi() does not correctly separate dir
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48725/sample.tar.xz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Wed Nov 20 09:05:42 2019
From: report at bugs.python.org (Erik Aronesty)
Date: Wed, 20 Nov 2019 14:05:42 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1574258742.36.0.0691093919553.issue22107@roundup.psfhosted.org>


Erik Aronesty <erik at q32.com> added the comment:

This is the fist of what I'm using: 
https://gist.github.com/earonesty/a052ce176e99d5a659472d0dab6ea361

Seems OK for my use cases.   There's probably issues with relying on __del__ this way.   But it solves the Windows close/reopen problem, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22107>
_______________________________________

From report at bugs.python.org  Wed Nov 20 09:38:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 14:38:47 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574260727.39.0.86829573732.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue since the discussion restarted.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 20 09:43:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 14:43:00 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574260980.49.0.894595752285.issue38692@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16783
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17290

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 20 09:46:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 14:46:50 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574261210.02.0.147284067197.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

As I already proposed previously, I proposed PR 17290 to simply skip test_pidfd_open() if os.pidfd_open() fails with a PermissionError.

I don't propose to change os.pidfd_open(), only the test unit for practical reasons: not bother users who have to use a strict Linux sandbox using a syscalls whitelist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Wed Nov 20 09:47:45 2019
From: report at bugs.python.org (Jackson Riley)
Date: Wed, 20 Nov 2019 14:47:45 +0000
Subject: [issue34716] MagicMock.__divmod__ should return a pair
In-Reply-To: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>
Message-ID: <1574261265.24.0.38093484867.issue34716@roundup.psfhosted.org>


Change by Jackson Riley <jacriley at cisco.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34716>
_______________________________________

From report at bugs.python.org  Wed Nov 20 09:53:59 2019
From: report at bugs.python.org (Siwon Kang)
Date: Wed, 20 Nov 2019 14:53:59 +0000
Subject: [issue38863] http.server is_cgi() does not correctly separate dir
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574261639.14.0.0731498151445.issue38863@roundup.psfhosted.org>


Change by Siwon Kang <kkangshawn at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Wed Nov 20 09:59:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 14:59:27 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574261967.56.0.337980940217.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16786
pull_request: https://github.com/python/cpython/pull/17293

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 10:07:49 2019
From: report at bugs.python.org (John Goerzen)
Date: Wed, 20 Nov 2019 15:07:49 +0000
Subject: [issue38864] dbm: Can't open database with bytes-encoded filename
Message-ID: <1574262469.06.0.509781459017.issue38864@roundup.psfhosted.org>


New submission from John Goerzen <jgoerzen at users.sourceforge.net>:

This simple recipe fails:

>>> import dbm
>>> dbm.open(b"foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/dbm/__init__.py", line 78, in open
    result = whichdb(file) if 'n' not in flag else None
  File "/usr/lib/python3.7/dbm/__init__.py", line 112, in whichdb
    f = io.open(filename + ".pag", "rb")
TypeError: can't concat str to bytes

Why does this matter?  On POSIX, a filename is any string of bytes that does not contain 0x00 or '/'.  A database with a filename containing, for instance, German characters in ISO-8859-1, can't be opened by dbm, EVEN WITH decoding.

For instance:

file = b"test\xf7"
>>> dbm.open(file.decode())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf7 in position 4: invalid start byte
db = dbm.open(file.decode('iso-8859-1'), 'c')
db.close()

Then:

ls *.db | hd
00000000  74 65 73 74 c3 b7 2e 64  62 0a                    |test...db.|
0000000a

Note that it didn't insert the 0xf7 here; rather, it inserted the Unicode sequence corresponding to the division character (which is what 0xf7 in iso-8859-1 is).  It is not possible to open a filename named "test\xf7.db" with the dbm module.

----------
messages: 357078
nosy: jgoerzen
priority: normal
severity: normal
status: open
title: dbm: Can't open database with bytes-encoded filename

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38864>
_______________________________________

From report at bugs.python.org  Wed Nov 20 10:16:08 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Nov 2019 15:16:08 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
In-Reply-To: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>
Message-ID: <1574262968.87.0.936177790152.issue38841@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Wed Nov 20 10:36:33 2019
From: report at bugs.python.org (Cat Chenal)
Date: Wed, 20 Nov 2019 15:36:33 +0000
Subject: [issue38853] set.repr breaches docstring contract
In-Reply-To: <1574198861.64.0.9694268826.issue38853@roundup.psfhosted.org>
Message-ID: <1574264193.29.0.0751131960419.issue38853@roundup.psfhosted.org>


Cat Chenal <catchenal at gmail.com> added the comment:

Thank you for pointing out my lack of clarity: I apologize.
I probably should not have split this issue in two (issue38855).

My confusion stems from the fact that I expected the unpacking of a set to return the same output as that obtained from the unpacking of a list.
>From my testing, I gather that the unpacking of a set is performed via its repr, which uses "some ordering".

In closing, I want to note two points:

1. repr is apparently platform-dependent (here: Python 3.6.7 [MSC v.1900 64 bit (AMD64)]):

The code given by steven.daprano run in a jupyter lab cell or in VS Code yields a different output:
>>> repr({4, 5, 2**31+1, 2, 2**31+2, 3, 2**31, 0})
'{2147483648, 2147483649, 2, 2147483650, 4, 5, 3, 0}'

2. Testing reviewer's assertion: "The specific order you see will depend on the specific values in the set, as well as the order that they were inserted, deleted, and/or re-inserted in some arbitrary way."
This counter example, where element 0 is moved to the second position, shows that there is not such order dependence: 
>>> repr({4, 0, 5, 2**31+1, 2, 2**31+2, 3, 2**31})
'{0, 2147483649, 2, 2147483650, 4, 5, 3, 2147483648}'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38853>
_______________________________________

From report at bugs.python.org  Wed Nov 20 10:42:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 15:42:04 +0000
Subject: [issue38865] Can Py_Finalize() be called if the current interpreter
 is not the main interpreter?
Message-ID: <1574264524.01.0.330569638863.issue38865@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Programs/_testembed.c contains the following test used by test_embed:

static int test_audit_subinterpreter(void)
{
    Py_IgnoreEnvironmentFlag = 0;
    PySys_AddAuditHook(_audit_subinterpreter_hook, NULL);
    _testembed_Py_Initialize();

    Py_NewInterpreter(); 
    Py_NewInterpreter(); 
    Py_NewInterpreter(); 
 
    Py_Finalize(); 

    switch (_audit_subinterpreter_interpreter_count) {
        case 3: return 0;
        case 0: return -1;
        default: return _audit_subinterpreter_interpreter_count;
    }
}

When Py_Finalize() is called, the current interpreter is a subinterpreter (the 3rd interpreter), not the main interpreter.

* Is it correct to call Py_Finalize() in such case?
* Is Python supposed to magically destroy the 3 interpreters?

In bpo-38858, I'm trying to reuse the same code to initialize and finalize the "main" interpreter and subinterpreters. I had an issue with test_audit_subinterpreter() when working on the PR 17293.

I modified my PR 17293 to not expect that Py_Finalize() can only be called from the main interpreter, but actually check if the current interpreter is the main interpreter or not. It fix test_audit_subinterpreter() but again, I'm not sure what is the correct behavior?

--

Last year, we had a similar discussion about calling Py_Main() *after* Py_Initialize(). I hacked the code to make it possible because it was supported previously, even if the Py_Main() configuration is only partially applied. But I understood that Nick Coghlan would prefer to deprecate supporting to call Py_Initialize() before Py_Main().

PEP 587 added Py_RunMain() which provides a different solution to this problem:
https://docs.python.org/dev/c-api/init_config.html#c.Py_RunMain

----------
components: Interpreter Core
messages: 357080
nosy: eric.snow, nanjekyejoannah, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: Can Py_Finalize() be called if the current interpreter is not the main interpreter?
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38865>
_______________________________________

From report at bugs.python.org  Wed Nov 20 10:44:52 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 20 Nov 2019 15:44:52 +0000
Subject: [issue38863] http.server is_cgi() does not correctly separate dir
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574264692.59.0.548513931629.issue38863@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

CGI programs are stored in a directory which must be configured in the web server. The path is typically SERVER_ROOT/cgi-bin, so the URL looks like
http://www.domain/cgi-bin/script

So IMHO, is_cgi's assumption is correct.
IMHO, this is not the wrong code.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Wed Nov 20 10:47:45 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 20 Nov 2019 15:47:45 +0000
Subject: [issue38863] http.server is_cgi() does not correctly separate dir
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574264865.32.0.33731562361.issue38863@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

In addition, the code is not about the path on the file system,
but about the web request path.

https://bugs.python.org/msg216960 will help you to understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Wed Nov 20 10:54:34 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Nov 2019 15:54:34 +0000
Subject: [issue38840] incorrect __all__ list in multiprocessing.managers module
In-Reply-To: <1574115502.48.0.329816372934.issue38840@roundup.psfhosted.org>
Message-ID: <1574265274.76.0.611873560891.issue38840@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38840>
_______________________________________

From report at bugs.python.org  Wed Nov 20 11:34:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 16:34:43 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574267683.93.0.928074449397.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fff7bbfdb6b7c143b73b6b4b6b40e828c101110c by Victor Stinner in branch 'master':
bpo-38858: Add _Py_IsMainInterpreter(tstate) (GH-17293)
https://github.com/python/cpython/commit/fff7bbfdb6b7c143b73b6b4b6b40e828c101110c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 11:56:50 2019
From: report at bugs.python.org (Siwon Kang)
Date: Wed, 20 Nov 2019 16:56:50 +0000
Subject: [issue38863] http.server is_cgi() does not correctly separate dir
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574269010.06.0.982186891893.issue38863@roundup.psfhosted.org>


Siwon Kang <kkangshawn at gmail.com> added the comment:

Thank you for your message and the info about 21323. I agree with the idea that cgi files are conventionally placed at the cgi-bin of the root but there is no explicit regulation so other servers, apache for example, handle this kind of sub directories successfully. In short, there is no violation in the form of /subdir/cgi-bin so this is nice to have if the http.server processes this case correctly. By the way, I didn't consider the case of continuous slashes so PR must be modified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:01:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 17:01:58 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574269318.62.0.184987255417.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16789
pull_request: https://github.com/python/cpython/pull/17297

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:10:56 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Nov 2019 17:10:56 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574269856.89.0.0623537293477.issue38500@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

OK, then my vote is to provide getter and setter methods that are underscore-prefixed to mark them as "internal" with clear comments specifying that they are part of PEP 523 and thus should not be needlessly broken in a bugfix release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:15:04 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Nov 2019 17:15:04 +0000
Subject: [issue38765] `ast.AST._attributes` is used by `ast.dump()` but not
 documented
In-Reply-To: <1573482663.72.0.733055997415.issue38765@roundup.psfhosted.org>
Message-ID: <1574270104.03.0.216283709953.issue38765@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

It's also possible the leading underscore was used to prevent name collisions.

Unfortunately I don't know the history of _attributes, so without someone digging through the git history or personally knowing the reason behind it I don't know whether we should be exposing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38765>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:27:06 2019
From: report at bugs.python.org (Jackson Riley)
Date: Wed, 20 Nov 2019 17:27:06 +0000
Subject: [issue38866] test_pyclbr replace asyncore
Message-ID: <1574270826.5.0.92652602871.issue38866@roundup.psfhosted.org>


New submission from Jackson Riley <jacriley at cisco.com>:

sub-issue of (issue28533)[https://bugs.python.org/issue28533]

----------
components: Tests
files: pyclbr.patch
keywords: patch
messages: 357087
nosy: jacksonriley
priority: normal
severity: normal
status: open
title: test_pyclbr replace asyncore
Added file: https://bugs.python.org/file48726/pyclbr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38866>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:28:56 2019
From: report at bugs.python.org (Jackson Riley)
Date: Wed, 20 Nov 2019 17:28:56 +0000
Subject: [issue28533] Replace asyncore
In-Reply-To: <1477420324.44.0.338895938894.issue28533@psf.upfronthosting.co.za>
Message-ID: <1574270936.24.0.0501468239286.issue28533@roundup.psfhosted.org>


Jackson Riley <jacriley at cisco.com> added the comment:

Lib/test/test_pyclbr.py - subissue issue38866
A trivial one!

----------
nosy: +jacksonriley

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28533>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:29:58 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 20 Nov 2019 17:29:58 +0000
Subject: [issue38863] http.server is_cgi() does not correctly separate dir
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574270998.18.0.899908874497.issue38863@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Yes, IMHO, but this code is related to the http.server.CGIHTTPRequestHandler.
This code looks like to be executed on the http.server.CGIHTTPRequestHandler not the apache server.

According to docs,
This defaults to ['/cgi-bin', '/htbin'] and describes directories to treat as containing CGI scripts.

reference: https://docs.python.org/3.9/library/http.server.html?highlight=cgihttprequesthandler#http.server.CGIHTTPRequestHandler.cgi_directories

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:30:52 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Nov 2019 17:30:52 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1574271052.72.0.8731537208.issue33125@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset de148f263fba75cd10d2cb010fe9c495cee4ec83 by Steve Dower in branch 'master':
bpo-33125: Add support for building and releasing Windows ARM64 packages (GH-16828)
https://github.com/python/cpython/commit/de148f263fba75cd10d2cb010fe9c495cee4ec83


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:34:36 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Nov 2019 17:34:36 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1574271276.11.0.764737634902.issue33125@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I've merged the change to master, but note that the release is not enabled, so we aren't actually releasing ARM64 builds yet (though they will be compiled [but not tested] in PRs - nothing should be different from other Windows builds though). There's no harm in giving the build scripts a bit of bake time.

I'm also not concerned about backporting to 3.8 to make it easier to build that version, which I've heard a little bit of demand for. But let's run the scripts in master for a little while first.

Deliberately leaving the stage as "commit review" rather than "backport needed" for now.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:39:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 17:39:17 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574271557.33.0.944258944057.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b93f31fcd9f10b213c614d4944baf9ca2df2016c by Victor Stinner in branch 'master':
bpo-38858: Fix Py_Finalize() when called from a subinterpreter (GH-17297)
https://github.com/python/cpython/commit/b93f31fcd9f10b213c614d4944baf9ca2df2016c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:41:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Nov 2019 17:41:21 +0000
Subject: [issue38867] Enable Tkinter on Windows ARM
Message-ID: <1574271681.28.0.800107532571.issue38867@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

(Split out from issue33125)

We currently do not have ARM/ARM64 builds of Tcl/Tk for Windows, so we cannot enable tkinter on this platform.

When builds of the dependencies become possible (in 8.6.10, apparently), we can enable it again.

----------
components: Tkinter, Windows
messages: 357093
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable Tkinter on Windows ARM
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38867>
_______________________________________

From report at bugs.python.org  Wed Nov 20 12:41:52 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Nov 2019 17:41:52 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1574271712.09.0.280842810903.issue33125@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I also filed issue38867 specifically for enabling Tkinter on Windows ARM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Wed Nov 20 13:23:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 18:23:00 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1574274180.41.0.680627803723.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Debian PGO 3.x:
https://buildbot.python.org/all/#/builders/47/builds/3851

test_submit_keyword (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.62s Warning -- reap_children() reaped child process 32627
Warning -- multiprocessing.process._dangling was modified by test_concurrent_futures

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Nov 20 13:44:44 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 20 Nov 2019 18:44:44 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574275484.28.0.597175528716.issue38823@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +16790
pull_request: https://github.com/python/cpython/pull/17298

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 14:15:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Nov 2019 19:15:42 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1574277342.7.0.358975008086.issue38843@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38843>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:02:21 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 20:02:21 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
In-Reply-To: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>
Message-ID: <1574280141.27.0.786070929811.issue38841@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16791
pull_request: https://github.com/python/cpython/pull/17299

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:02:28 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 20:02:28 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
In-Reply-To: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>
Message-ID: <1574280148.02.0.0545521665713.issue38841@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 559bad1a70ed50cc9caa7cb303b6ac1fe6a34af3 by Miss Islington (bot) (xdegaye) in branch 'master':
bpo-38841: Skip asyncio test_create_datagram_endpoint_existing_sock_unix (GH-17294)
https://github.com/python/cpython/commit/559bad1a70ed50cc9caa7cb303b6ac1fe6a34af3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:04:43 2019
From: report at bugs.python.org (Svetlana Vodianova)
Date: Wed, 20 Nov 2019 20:04:43 +0000
Subject: [issue38868] Shutil cannot delete a folder that contains an .ini file
Message-ID: <1574280283.41.0.914167266294.issue38868@roundup.psfhosted.org>


New submission from Svetlana Vodianova <svetlana.vodianova69 at gmx.com>:

I posted my problem on Stack Overflow, but as of right now haven't received any answers. 

Link: https://stackoverflow.com/questions/58922332/shutil-cannot-delete-a-folder-with-a-hidden-desktop-ini-file

To summarize my problem: If you use copytree to copy a source folder that contains a desktop.ini file to a destination, and then call rmtree() to remove the source folder, it will throw an error indicating it doesn't have permission to remove the folder. Using ignore_patterns() doesn't help either, or to quote my problem on SO:

It seems once the source contains a .ini file, even if it isn't copied to the destination, rmtree() will have a problem removing the source folder.

Powershell has almost the same issue, however, unlike Python, if you tell PS to ignore the .ini file, it will remove the folder without crashing.

rmtree has no problem removing folders containing 0 ini files.

----------
components: IO, Windows
messages: 357097
nosy: QueenSvetlana, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Shutil cannot delete a folder that contains an .ini file
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38868>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:07:05 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Nov 2019 20:07:05 +0000
Subject: [issue38848] compileall fails when the platform lacks a functional
 sem_open()
In-Reply-To: <1574178213.95.0.878583354455.issue38848@roundup.psfhosted.org>
Message-ID: <1574280425.65.0.324438949323.issue38848@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Changing the title to "compileall fails when the platform lacks a functional  sem_open()" as the problem lies in the compileall module itself.
Nosying Antoine as the author of issue #36786.


compileall fails on android API 24:

generic_x86_64:/data/local/tmp/python $ python -m compileall --workers=2 .
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 28, in <module>
    from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'SemLock' from '_multiprocessing' (/data/local/tmp/python/lib/python3.9/lib-dynload/_multiprocessing.cpython-39d.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 425, in <module>
    exit_status = int(not main())
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 403, in main
    if not compile_dir(dest, maxlevels, args.ddir,
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 91, in compile_dir
    with ProcessPoolExecutor(max_workers=workers) as executor:
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 555, in __init__
    self._call_queue = _SafeQueue(
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 165, in __init__
    super().__init__(max_size, ctx=ctx)
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/context.py", line 67, in Lock
    from .synchronize import Lock
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 30, in <module>
    raise ImportError("This platform lacks a functioning sem_open" +
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.

----------
components: +Library (Lib) -Tests
nosy: +pitrou
title: test_compileall fails when the platform lacks a functional  sem_open() -> compileall fails when the platform lacks a functional  sem_open()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38848>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:10:31 2019
From: report at bugs.python.org (Svetlana Vodianova)
Date: Wed, 20 Nov 2019 20:10:31 +0000
Subject: [issue38868] Shutil cannot delete a folder that contains an .ini file
In-Reply-To: <1574280283.41.0.914167266294.issue38868@roundup.psfhosted.org>
Message-ID: <1574280631.99.0.502229085614.issue38868@roundup.psfhosted.org>


Svetlana Vodianova <svetlana.vodianova69 at gmx.com> added the comment:

I posted my problem on Stack Overflow, but as of right now haven't received any answers. 

Link: https://stackoverflow.com/questions/58922332/shutil-cannot-delete-a-folder-with-a-hidden-desktop-ini-file

To summarize my problem: If you use copytree to copy a source folder that contains a desktop.ini file to a destination, and then call rmtree() to remove the destination folder (for example after zipping, you may want to remove the uncompressed destination folder), it will throw an error indicating it doesn't have permission to remove the folder. Using ignore_patterns() doesn't help either, or to quote my problem on SO:

It seems once the source contains a .ini file, even if it isn't copied to the destination, rmtree() will have a problem removing the destination folder.

Powershell has almost the same issue, however, unlike Python, if you tell PS to ignore the .ini file, it will remove the folder without crashing.

rmtree has no problem removing folders containing 0 ini files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38868>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:20:29 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Nov 2019 20:20:29 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
In-Reply-To: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>
Message-ID: <1574281229.13.0.991638905469.issue38841@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b762375ba28893be73f166576aecde44ad2f4001 by Miss Islington (bot) in branch '3.8':
bpo-38841: Skip asyncio test_create_datagram_endpoint_existing_sock_unix (GH-17294)
https://github.com/python/cpython/commit/b762375ba28893be73f166576aecde44ad2f4001


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:27:28 2019
From: report at bugs.python.org (David Cuthbert)
Date: Wed, 20 Nov 2019 20:27:28 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574281648.88.0.649628101522.issue37228@roundup.psfhosted.org>


David Cuthbert <dacut at kanga.org> added the comment:

Jukka -- Fair enough; will reword this a bit. I'm trying to keep the DeprecationWarning short enough so people's eyes don't glaze over; will see what wordsmithing I can do here. (Once you get beyond a certain length, the number of folks who actually read the message goes down the longer it is.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:31:45 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 20 Nov 2019 20:31:45 +0000
Subject: [issue38853] set.repr breaches docstring contract
In-Reply-To: <1574264193.29.0.0751131960419.issue38853@roundup.psfhosted.org>
Message-ID: <20191120203135.GF2542@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> My confusion stems from the fact that I expected the unpacking of a 
> set to return the same output as that obtained from the unpacking of a 
> list.

Why did you expect that?

Sets aren't lists. Lists are ordered, so they hold their items in a 
specific order. Sets are unordered, so there is no guarantee what order 
you will see when you unpack them.

If you create the list [foo, bar, baz] then the output will always be 
[foo, bar, baz] on every platform. That's a guarantee.

Sets are unordered, as documented, so there are no guarantee about what 
order you will see: it might be {foo, baz, bar} or {bar, baz, foo} or 
{foo, bar, baz} or {baz, foo, bar}, any permutation is equally valid, 
regardless of what order you created the set.

> 1. repr is apparently platform-dependent

Quite likely. Since there's no guarantee what order you will see, 
there's no guarantee that the order won't change from platform to 
platform, or version to version.

> 2. Testing reviewer's assertion: "The specific order you see will 
> depend on the specific values in the set, as well as the order that 
> they were inserted, deleted, and/or re-inserted in some arbitrary 
> way."
> This counter example, where element 0 is moved to the second position, 
> shows that there is not such order dependence:

Your example shows that the output order changes when you change the 
input order, in an unpredicatable, arbitrary way, just like I said. 
That's not a counter-example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38853>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:39:37 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Nov 2019 20:39:37 +0000
Subject: [issue38841] [asyncio] bind() on a unix socket raises PermissionError
 on Android for a non-root user
In-Reply-To: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>
Message-ID: <1574282377.13.0.34452439894.issue38841@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38841>
_______________________________________

From report at bugs.python.org  Wed Nov 20 15:48:13 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Nov 2019 20:48:13 +0000
Subject: [issue38848] compileall fails when the platform lacks a functional
 sem_open()
In-Reply-To: <1574178213.95.0.878583354455.issue38848@roundup.psfhosted.org>
Message-ID: <1574282893.48.0.845925052545.issue38848@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38848>
_______________________________________

From report at bugs.python.org  Wed Nov 20 16:04:18 2019
From: report at bugs.python.org (David Cuthbert)
Date: Wed, 20 Nov 2019 21:04:18 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574283858.98.0.760829868756.issue37228@roundup.psfhosted.org>


David Cuthbert <dacut at kanga.org> added the comment:

On the completely deprecate reuse_address and rewrite/force folks to use reuse_port proposals, I'm a bit dubious of this approach.

Right now, we have two knobs that directly correspond to (potential) kernel-level socket parameters, SO_REUSEADDR and SO_REUSEPORT. We just chose an unfortunate default for one of them. Otherwise, the behavior is nicely explicit.

Rewriting or forbidding it, even when the user has (essentially) acknowledged they're accepting risks by passing reuse_address=True, seems to fly in the face of this. Users get bitten when we start convoluting logic here (I was just bitten by fcntl.lockf() not actually calling lockf() last month and ended up having to call lockf() via ctypes.).

There are some platforms (Linux pre-3.9 kernels) that don't have SO_REUSEPORT. I wish I could say I don't care about such platforms; alas, I just had to compile Python 3.7 on a system running a 2.6 kernel last month at a client site.

Finally, I've only scratched the surface with my test cases, on single-homed systems, IPv4, and binding to 0.0.0.0. There are a lot of parameters to try here before we decree that reuse_address has no purpose existing, and an OS could later reimplement saner defaults on SO_REUSEADDR.

Changing a default already has some controversy (Yury was -1 on this change). This seems much bigger and I'm not convinced we fully understand its ramifications.

That said, I'll happily implement whatever the consensus ends up being, or consensus as designated by the vBDFL, or wherever that decision needs to come from. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 16:07:01 2019
From: report at bugs.python.org (John Goerzen)
Date: Wed, 20 Nov 2019 21:07:01 +0000
Subject: [issue38864] dbm: Can't open database with bytes-encoded filename
In-Reply-To: <1574262469.06.0.509781459017.issue38864@roundup.psfhosted.org>
Message-ID: <1574284021.05.0.722873436851.issue38864@roundup.psfhosted.org>


John Goerzen <jgoerzen at users.sourceforge.net> added the comment:

As has been pointed out to me, the surrogateescape method could be used here; however, it is a bit of an odd duckling itself, and the system's open() call accepts bytes; couldn't this as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38864>
_______________________________________

From report at bugs.python.org  Wed Nov 20 16:32:48 2019
From: report at bugs.python.org (Ian Carr-de Avelon)
Date: Wed, 20 Nov 2019 21:32:48 +0000
Subject: [issue38869] Unexpectedly variable result
Message-ID: <1574285568.87.0.779759342815.issue38869@roundup.psfhosted.org>


New submission from Ian Carr-de Avelon <carrdeavelon at gmail.com>:

I can't understand why the result of changes() in the example file changes. I get:
[[6.90642211e-310]
 [1.01702662e-316]
 [1.58101007e-322]]
[[0.]
 [0.]
 [0.]]
with an Ubuntu 14 system that has had a lot of changes made. I've checked the same happens on pythonanywhere.com so it does not seem to just be my system is broken. I wondered if there was some strange state in cv2 I don't know about, but as commenting out the tvec=np.zeros(3) line removes the behaviour I think there is something strange here. Now I've got it down to a few lines I can find a work around  and obviously numpy and opencv are huge packages and it may be in their court, but I think it is worth someone taking a look who knows more than me.
Yours
Ian

----------
files: bug.py
messages: 357105
nosy: IanCarr
priority: normal
severity: normal
status: open
title: Unexpectedly variable result
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file48727/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38869>
_______________________________________

From report at bugs.python.org  Wed Nov 20 16:43:28 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Nov 2019 21:43:28 +0000
Subject: [issue38869] Unexpectedly variable result
In-Reply-To: <1574285568.87.0.779759342815.issue38869@roundup.psfhosted.org>
Message-ID: <1574286208.81.0.482869054732.issue38869@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I don't see anything here to indicate a bug in CPython or the standard library, so I'm closing the issue.  I would recommend asking for help with this on python-list at python.org (comp.lang.python) or StackOverflow.  If you can reduce it to a bug in either numpy or cv2, you'll need to report it to the correct issue tracker for the project.

----------
nosy: +zach.ware
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38869>
_______________________________________

From report at bugs.python.org  Wed Nov 20 16:49:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 21:49:21 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574286561.59.0.682394454337.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16793
pull_request: https://github.com/python/cpython/pull/17301

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Nov 20 17:34:29 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 20 Nov 2019 22:34:29 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
Message-ID: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

As discussed in https://mail.python.org/archives/list/python-dev at python.org/thread/JAQDBMC23HW2PQ27HQNJ7G244T423IDD/ I propose to expose the unparse.py tool as part of the standard library in the ast module.

The exposed function will have the interface:

ast.unparse(ast_obj, *, option1, option2,...)

and will return a string with the unparsed version of ast_obj.

The unparse tool will need some cosmetic improvements that will be tracked separately in this issue.

----------
assignee: pablogsal
components: Library (Lib)
messages: 357107
nosy: BTaskaya, pablogsal
priority: normal
severity: normal
status: open
title: Expose ast.unparse in the ast module
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Wed Nov 20 17:35:35 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 20 Nov 2019 22:35:35 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574289335.88.0.0827953743449.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> There are some platforms (Linux pre-3.9 kernels) that don't have SO_REUSEPORT. I wish I could say I don't care about such platforms; alas, I just had to compile Python 3.7 on a system running a 2.6 kernel last month at a client site.

Based on https://www.kernel.org/releases.html, pre-3.9 Linux kernels are no longer supported upstream, the oldest LTS version is 3.16.

There are likely a number of systems running older unsupported kernel versions, but I don't think that we can be reasonably expected to maintain indefinite backwards compatibility to versions that aren't supported upstream, especially not at the expense of the ones that are supported. 

In those cases, I think the responsibility ultimately falls upon the owners of the system or third party group providing service. This particular fix would be fairly straightforward:

> And, yes, someone who really wants SO_REUSEADDR can set it manually, for example by calling `transport.get_extra_info('socket')`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 17:44:42 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 20 Nov 2019 22:44:42 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574289882.97.0.274340913849.issue38870@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Wed Nov 20 17:49:18 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Wed, 20 Nov 2019 22:49:18 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574290158.43.0.454466835898.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

> We just chose an unfortunate default for one of them

I'd like to point out that it is also documented completely wrong up to this point in time and thus people who chose True are most likely to be unaware of the actual consequences. A user's explicit choice based on misinformation is not really demonstrating intent to shoot oneself in the foot.

So after changing my mind a couple of times I'm still attached to the idea that in 3.10 reuse_address and reuse_port are both removed and the tiny portion of developers who need them will just create a suitably setsockopt'd socket and pass it to the function. 2 lines of additional code is all it takes.

If the documentation had been correct all along and just the default bad, this mess would be much smaller.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 17:52:26 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 20 Nov 2019 22:52:26 +0000
Subject: [issue38868] Shutil cannot delete a folder that contains an .ini file
In-Reply-To: <1574280283.41.0.914167266294.issue38868@roundup.psfhosted.org>
Message-ID: <1574290346.45.0.261054806727.issue38868@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

What is the system error code (winerror) of the PermissionError?

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38868>
_______________________________________

From report at bugs.python.org  Wed Nov 20 17:55:23 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 20 Nov 2019 22:55:23 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574290523.47.0.963418856613.issue38870@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Wed Nov 20 17:55:42 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 20 Nov 2019 22:55:42 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574290542.61.0.914742327235.issue38870@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Wed Nov 20 18:01:49 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 20 Nov 2019 23:01:49 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574290909.37.0.575757439066.issue38870@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

After PR17302 is merged we need to fix the following cosmetic issues indicated by Victor:

(*) unparse adds many useless parentheses. The algorithm seems naive.
For example, it adds "()" to "class _AddedDllDirectory():". It also
adds parenthesis around yield, like "(yield (top, dirs, nondirs))",
whereas the AST node was at "top level": it isn't a sub-expression.
Maybe this algortihm should be made smarter.

(*) newlines in docstring are rendered as two characters: "\" + "n"
(escaped newline: \n), rather than a newline character. I would expect
a newline, it's more common that \n... But it may "break" inline
doctests rendering... Maybe it should be an option (render newlines as
newline character or escape them?), or maybe even let the user choose
how to render them using a callback (that's related to the "pluggable
formatter" question).

(*) Indentation is hardcoded to 4 spaces. What if I want 2 spaces or
something different? Should it become an option?

(*) Float infinity is replaces with 1e309. Again, maybe someone wants
to render this differently? It sounds like an arbitrary choice (which
"works" as expected).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Wed Nov 20 18:12:36 2019
From: report at bugs.python.org (Zoran Simic)
Date: Wed, 20 Nov 2019 23:12:36 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
Message-ID: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>


New submission from Zoran Simic <zsimic at netflix.com>:

This code snippet exposes a small edge case in lib2to3, where syntactically invalid code is generated:

data = [1, 2, 3, 4, 5]
x = filter(lambda x: True if x > 2 else False, data)
print(x)


lib2to3 transforms 2nd line above to:
x = [x for x in data if True if x > 2 else False]


which is invalid (would be OK with parentheses after 1st 'if')

Admittedly, the original code here is more complex that it should be ('True if foo else False' being equivalent to just 'foo'), but walked into this in "the real world" and wanted to report it.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 357112
nosy: Zoran Simic
priority: normal
severity: normal
status: open
title: lib2to3 generates invalid code with filter and ternary operator
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Wed Nov 20 18:17:11 2019
From: report at bugs.python.org (Emiliano Heyns)
Date: Wed, 20 Nov 2019 23:17:11 +0000
Subject: [issue17582] xml.etree.ElementTree does not preserve whitespaces in
 attributes
In-Reply-To: <1364660794.69.0.883579635559.issue17582@psf.upfronthosting.co.za>
Message-ID: <1574291831.5.0.74820376695.issue17582@roundup.psfhosted.org>


Emiliano Heyns <emiliano.heyns at iris-advies.com> added the comment:

I don't see newlines currently preserved in attributes:

   elem = ET.parse(StringIO('<test a="   \nab\n    "/>')).getroot()
   print(ET.tostring(elem))

----------
components:  -XML
nosy: +Emiliano Heyns
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17582>
_______________________________________

From report at bugs.python.org  Wed Nov 20 19:17:06 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 00:17:06 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1574295426.48.0.00458417602552.issue38823@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e5d1f734db135e284af8e8868e7ccc85355952b9 by Miss Islington (bot) (Brandt Bucher) in branch 'master':
bpo-38823: Clean up _xxtestfuzz initialization. (GH-17216)
https://github.com/python/cpython/commit/e5d1f734db135e284af8e8868e7ccc85355952b9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Wed Nov 20 19:26:01 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Nov 2019 00:26:01 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574295961.75.0.361207230066.issue37228@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

(Provisionally marking this as a security-related deferred blocker issue for backporting)

----------
nosy: +ned.deily
priority: normal -> deferred blocker
type: behavior -> security
versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 19:26:57 2019
From: report at bugs.python.org (Galen Han)
Date: Thu, 21 Nov 2019 00:26:57 +0000
Subject: [issue36054] On Linux,
 os.count() should read cgroup cpu.shares and cpu.cfs (CPU count
 inside docker container)
In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org>
Message-ID: <1574296017.79.0.711156584182.issue36054@roundup.psfhosted.org>


Change by Galen Han <galenhan96 at gmail.com>:


----------
nosy: +Galen Han

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36054>
_______________________________________

From report at bugs.python.org  Wed Nov 20 19:27:56 2019
From: report at bugs.python.org (Lisa Roach)
Date: Thu, 21 Nov 2019 00:27:56 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1574296076.88.0.611216571448.issue38857@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:


New changeset 046442d02bcc6e848e71e93e47f6cde9e279e993 by Lisa Roach (Jason Fried) in branch 'master':
bpo-38857: AsyncMock fix for awaitable values and StopIteration fix [3.8] (GH-17269)
https://github.com/python/cpython/commit/046442d02bcc6e848e71e93e47f6cde9e279e993


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Wed Nov 20 19:34:16 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 21 Nov 2019 00:34:16 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574296456.4.0.0092391183829.issue38021@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +16795
pull_request: https://github.com/python/cpython/pull/17303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Wed Nov 20 19:38:41 2019
From: report at bugs.python.org (Lisa Roach)
Date: Thu, 21 Nov 2019 00:38:41 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1574296721.52.0.38380269142.issue38857@roundup.psfhosted.org>


Change by Lisa Roach <lisaroach14 at gmail.com>:


----------
pull_requests: +16796
pull_request: https://github.com/python/cpython/pull/17304

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Wed Nov 20 20:13:22 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Nov 2019 01:13:22 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574298802.03.0.341328556556.issue38021@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

PEP 425 tags are now in the Python Packaging Authority realm.  People from there should also be reviewing this issue and the new PR.  CC-ing Brett and Nick for guidance.

Also, assuming the feature is approved, I don't think it would be appropriate to backport to 3.7 (considering where 3.7 is in its life cycle).  It may be appropriate to make an exception for 3.8 since it is still early in its life.

----------
nosy: +brett.cannon, ncoghlan
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Wed Nov 20 20:14:06 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Nov 2019 01:14:06 +0000
Subject: [issue38872] Document exec symbol for codeop.compile_command
Message-ID: <1574298846.26.0.835938077059.issue38872@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

codeop.compile_command accepts 'exec' as a symbol, but it is not documented.  

Opening this bug report for an issue initially reported in PR3179.

----------
assignee: docs at python
components: Documentation
messages: 357118
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: Document exec symbol for codeop.compile_command
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38872>
_______________________________________

From report at bugs.python.org  Wed Nov 20 20:49:19 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 01:49:19 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
In-Reply-To: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>
Message-ID: <1574300959.68.0.580881785009.issue36277@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9391f6c3ef24f7962c534c42ccb792debdbef509 by Miss Islington (bot) (Dave Nguyen) in branch 'master':
bpo-36277: Add document for pdb debug and retval commands (GH-12872)
https://github.com/python/cpython/commit/9391f6c3ef24f7962c534c42ccb792debdbef509


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Wed Nov 20 20:49:28 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 01:49:28 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
In-Reply-To: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>
Message-ID: <1574300968.77.0.754635794881.issue36277@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16797
pull_request: https://github.com/python/cpython/pull/17308

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Wed Nov 20 20:49:37 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 01:49:37 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
In-Reply-To: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>
Message-ID: <1574300977.8.0.345225815151.issue36277@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16798
pull_request: https://github.com/python/cpython/pull/17309

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Wed Nov 20 20:52:41 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Nov 2019 01:52:41 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
In-Reply-To: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>
Message-ID: <1574301161.81.0.849184137859.issue36277@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@Antony.Lee, thank you for the report, @remi.lapeyre, thank you for the research, and @dvnguyen, thank you for the PR.

----------
nosy: +cheryl.sabella
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Wed Nov 20 20:56:30 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 01:56:30 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
In-Reply-To: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>
Message-ID: <1574301390.07.0.0848771920941.issue36277@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d5d41d39366214c9628b2680fa18fb8d085bcdbc by Miss Islington (bot) in branch '3.8':
bpo-36277: Add document for pdb debug and retval commands (GH-12872)
https://github.com/python/cpython/commit/d5d41d39366214c9628b2680fa18fb8d085bcdbc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Wed Nov 20 20:56:47 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 01:56:47 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
In-Reply-To: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>
Message-ID: <1574301407.43.0.73547261595.issue36277@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 97c301bfc5ea278c32dc5fabe425d8981ec5d3b1 by Miss Islington (bot) in branch '3.7':
bpo-36277: Add document for pdb debug and retval commands (GH-12872)
https://github.com/python/cpython/commit/97c301bfc5ea278c32dc5fabe425d8981ec5d3b1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Wed Nov 20 21:19:24 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 21 Nov 2019 02:19:24 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574302764.89.0.680095253636.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I'd like to point out that it is also documented completely wrong up to this point in time and thus people who chose True are most likely to be unaware of the actual consequences. A user's explicit choice based on misinformation is not really demonstrating intent to shoot oneself in the foot.

That's why I'm in favor of making the internal change from `SO_REUSEADDR` to `SO_REUSEPORT` (as Nathaniel suggested) and raising a warning for an explicit `reuse_address=True` (as Antoine suggested). If someone has a genuine need for using SO_REUSEADDR, they can do so manually.

This will patch the issue without any maintenance cost to users that didn't explicitly pass `reuse_address=True`, and raise a warning if they did pass it. The majority of users seem to have done did the former, which would make sense. Compare the following GitHub code search results:

All usage of `loop.create_datagram_endpoint`: https://github.com/search?q=%22loop.create_datagram_endpoint%22&type=Code (~3,500 Python results)

Usage of `loop.create_datagram_endpoint` + `reuse_address=True`: https://github.com/search?q=%22loop.create_datagram_endpoint%22+%22reuse_address%3DTrue%22&type=Code (~650 Python results)

Note: the second set of results contains some false positives due to usage of `reuse_address=True` for something else in the same code file. So, the actual number is likely less.

> I'm still attached to the idea that in 3.10 reuse_address and reuse_port are both removed

IIUC, there's only a security concern with the usage of `SO_REUSEADDR`, not `SO_REUSEPORT`. So there's no need at all to remove or deprecate the `reuse_port` parameter. 

> (Provisionally marking this as a security-related deferred blocker issue for backporting)

Thanks, Ned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 21:33:30 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 21 Nov 2019 02:33:30 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574303610.97.0.862169096697.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> My preference for create_datagram_endpoint() would be:

> - make the "reuse_address" parameter a no-op, and raise an error when "reuse_address=True" is passed

> - do that in 3.8 as well

This solution would more elegant, but my concern is that it will leave open a substantial security concern for versions 3.5, 3.6, and 3.7 if we only applied that to 3.8 and 3.9. Although Nathaniel's suggestion would ultimately make the `reuse_address` parameter fairly meaningless (essentially converting it into an alias for `reuse_port`), it would fix the security issue while still maintaining backwards compatibility for most users, allowing us to backport it all the way back to 3.5.

Perhaps this could lead to a deprecation warning or error, and then an eventual removal of `reuse_address`, but I think that's more of a long term concern for 3.9+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 21:37:22 2019
From: report at bugs.python.org (Sarah Harvey)
Date: Thu, 21 Nov 2019 02:37:22 +0000
Subject: [issue38873] find_library for libcrypto and libssl on Catalina
 returns the unversioned library
Message-ID: <1574303842.17.0.619288709802.issue38873@roundup.psfhosted.org>


New submission from Sarah Harvey <s at shh.sh>:

I've been tracking this through a bunch of different projects now. With the release of Mac OS X Catalina, libcrypto.dylib is a dummy library that causes an automatic segfault, to prevent upstream software from relying on it.

However a large amount of software makes use of ctypes find_library() which will return the path to the unversioned library.

It would be nice if we could specify "find the latest version" or similar so that we don't have to manually munge in a version, especially for strongly cross-platform libraries such as oscrypto.

I've filed a similar bug here https://github.com/wbond/oscrypto/issues/35 where it's very clear how it manifests itself.

----------
components: ctypes
messages: 357125
nosy: worldwise001
priority: normal
severity: normal
status: open
title: find_library for libcrypto and libssl on Catalina returns the unversioned library
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38873>
_______________________________________

From report at bugs.python.org  Wed Nov 20 21:39:28 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 21 Nov 2019 02:39:28 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574303968.68.0.0856788745668.issue37228@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> My preference for create_datagram_endpoint() would be:

> - make the "reuse_address" parameter a no-op, and raise an error when "reuse_address=True" is passed

> - do that in 3.8 as well

Yeah, I like this prposal; we can apply this to all Python's from 3.5 to 3.8.  With a proper documentation update this should be OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 22:00:19 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 21 Nov 2019 03:00:19 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574305219.54.0.981513788041.issue37228@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 22:15:17 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 21 Nov 2019 03:15:17 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574306117.51.0.188460351369.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Yeah, I like this prposal; we can apply this to all Python's from 3.5 to 3.8.  With a proper documentation update this should be OK.

Oh in that case, would you like me to close or modify GH-17311? I didn't think you'd approve of making the more extensive changes all the way back to 3.5.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 22:16:10 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 21 Nov 2019 03:16:10 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574306170.36.0.383008258939.issue37228@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 22:18:54 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 21 Nov 2019 03:18:54 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574306334.47.0.442858344897.issue37228@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Oh in that case, would you like me to close or modify GH-17311? I didn't think you'd approve of making the more extensive changes all the way back to 3.5.

After reading the comments here I think Antoine's solution makes sense. But... let's wait a bit to see what other people say.  My comment is just a single +1; maybe Andrew, Nathaniel, or Guido have arguments against it.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Nov 20 22:25:54 2019
From: report at bugs.python.org (Junyeong Jeong)
Date: Thu, 21 Nov 2019 03:25:54 +0000
Subject: [issue38874] asyncio.Queue: putting items out of order when it is full
Message-ID: <1574306754.82.0.07273997342.issue38874@roundup.psfhosted.org>


New submission from Junyeong Jeong <rhdxmr at gmail.com>:

Hi

The python document says that asyncio.Queue is FIFO queue. But it is not true
when the queue is full and multi tasks are putting items into it
simultaneously. I know the document does not explicitly mention that
asyncio.Queue is multi producer queue, but also there does not exist any note
that it may be corrupt if used by multi producers.

I found the below scenario happens when the asyncio.Queue is full and multi
tasks are putting into it simultaneously. Let me explain this.

When a queue is full, putters are awaiting here: https://github.com/python/cpython/blob/d67279147ace3b63187e5d75a15c345264f39e85/Lib/asyncio/queues.py#L125

And the first of them is waken up here: https://github.com/python/cpython/blob/d67279147ace3b63187e5d75a15c345264f39e85/Lib/asyncio/queues.py#L188

Before the first putter hands over the control of execution, new putter
calls the .put() method so the queue is not full at this point that it calls
.put_nowait() immediately here: https://github.com/python/cpython/blob/d67279147ace3b63187e5d75a15c345264f39e85/Lib/asyncio/queues.py#L140

If this happens the new putter puts earlier than other awaiting putters.

I hope the queue gets fixed to work correctly in this case.

Thanks,

  Junyeong

----------
components: asyncio
messages: 357129
nosy: asvetlov, esrse, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Queue: putting items out of order when it is full
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38874>
_______________________________________

From report at bugs.python.org  Wed Nov 20 22:36:30 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 21 Nov 2019 03:36:30 +0000
Subject: [issue38874] asyncio.Queue: putting items out of order when it is full
In-Reply-To: <1574306754.82.0.07273997342.issue38874@roundup.psfhosted.org>
Message-ID: <1574307390.52.0.784558427485.issue38874@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

The items that haven't finished the put aren't actually "in" the queue yet, so I don't see how non-FIFO order of insertion violates any FIFO guarantees for the contents of the queue; until the items are actually "in", they're not sequenced for the purposes of when they come "out". Mandating such a guarantee effectively means orchestrating a queue with a real maxsize equal to the configured maxsize plus the total number of coroutines competing to put items into it.

The guarantee is still being met here; once an item is put, it will be "get"-ed after anything that finished put-ing before it, and before anything that finished put-ing after it.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38874>
_______________________________________

From report at bugs.python.org  Thu Nov 21 00:50:05 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Nov 2019 05:50:05 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1574306334.47.0.442858344897.issue37228@roundup.psfhosted.org>
Message-ID: <CAP7+vJKPrCADoWD3OLsDRKiTjNLp1FRe+it_GH+3RZ6MsEvuhw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

(Don't wait for me, I am preoccupied with other things this week.)

----------
title: UDP sockets created by create_datagram_endpoint() allow by default  multiple processes to bind the same port -> UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Nov 21 00:59:06 2019
From: report at bugs.python.org (Junyeong Jeong)
Date: Thu, 21 Nov 2019 05:59:06 +0000
Subject: [issue38874] asyncio.Queue: putting items out of order when it is full
In-Reply-To: <1574306754.82.0.07273997342.issue38874@roundup.psfhosted.org>
Message-ID: <1574315946.55.0.839298137192.issue38874@roundup.psfhosted.org>


Junyeong Jeong <rhdxmr at gmail.com> added the comment:

> The items that haven't finished the put aren't actually "in" the queue yet, so I don't see how non-FIFO order of insertion violates any FIFO guarantees for the contents of the queue; until the items are actually "in", they're not sequenced for the purposes of when they come "out". Mandating such a guarantee effectively means orchestrating a queue with a real maxsize equal to the configured maxsize plus the total number of coroutines competing to put items into it.

Your explanation is correct technically. But without enough explanation, this
behavior can confuse many users.

For instance it happens to put data into asyncio.Queue at asyncio protocol
callbacks by creating new task. This logic will work nicely for a long time but
in the corner case the queue gets full and at the point of view of a consumer
the data come out from the queue are out of order.

IMHO, it would be better to add some note into the document, describing what
FIFO means in regard to asyncio.Queue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38874>
_______________________________________

From report at bugs.python.org  Thu Nov 21 01:13:18 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 21 Nov 2019 06:13:18 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1574316798.03.0.876854960625.issue38871@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I can reproduce on the latest master branch.

./python Tools/scripts/2to3 2.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Refactored 2.py
--- 2.py	(original)
+++ 2.py	(refactored)
@@ -1,3 +1,3 @@
 data = [1, 2, 3, 4, 5]
-x = filter(lambda x: True if x > 2 else False, data)
+x = [x for x in data if True if x > 2 else False]
 print(x)
RefactoringTool: Files that need to be modified:
RefactoringTool: 2.py

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Thu Nov 21 01:38:27 2019
From: report at bugs.python.org (Siwon Kang)
Date: Thu, 21 Nov 2019 06:38:27 +0000
Subject: [issue38863] http.server is_cgi() does not correctly separate dir
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574318307.35.0.0780114580123.issue38863@roundup.psfhosted.org>


Change by Siwon Kang <kkangshawn at gmail.com>:


----------
pull_requests: +16800
pull_request: https://github.com/python/cpython/pull/17312

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Thu Nov 21 01:40:44 2019
From: report at bugs.python.org (Siwon Kang)
Date: Thu, 21 Nov 2019 06:40:44 +0000
Subject: [issue38863] http.server is_cgi() does not correctly separate dir
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574318444.65.0.116902073397.issue38863@roundup.psfhosted.org>


Change by Siwon Kang <kkangshawn at gmail.com>:


----------
pull_requests:  -16785

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Thu Nov 21 01:53:01 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 21 Nov 2019 06:53:01 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574319181.57.0.264877140074.issue38688@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

PR-17098 basically reverts https://bugs.python.org/issue33695. Not good. =) 
I think we can simply consume the iterator immediately as in:

    def copytree(src, ...):
        with os.scandir(src) as itr:
            entries = list(itr)
        return _copytree(entries=entries, ...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Thu Nov 21 02:02:34 2019
From: report at bugs.python.org (Siwon Kang)
Date: Thu, 21 Nov 2019 07:02:34 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574319754.93.0.717728776025.issue38863@roundup.psfhosted.org>


Siwon Kang <kkangshawn at gmail.com> added the comment:

Hi Donghee,
Since you said this is not a bug, I changed the title describing this is a matter of improvement.

For your comment, I would say sorry first that I have made you confused. My mention about apache is just to give you an example for the other module that does similar thing(HTTP request handler with cgi support). I would never say the Python server shall support the sub-directory parsing for cgi scripts because apache does but I am saying good is good.

>> Yes, IMHO, but this code is related to the http.server.CGIHTTPRequestHandler.
This code looks like to be executed on the http.server.CGIHTTPRequestHandler not the apache server.

So you may see the PR changes the CGIHTTPRequestHandler class. Please refer to the code.

>> According to docs,
This defaults to ['/cgi-bin', '/htbin'] and describes directories to treat as containing CGI scripts.

This is the one I was looking at. As described, I added '/sub/dir/cgi-bin' into the cgi_directories expecting it to be treated the directory is for CGI scripts but the CGIHTTPRequestHandler does not process it. That is the reason for this issue report. Again, there is no note that restrict the path in cgi_directories shall be a single depth, so I think this will definitely give a benefit to handle the multi-level directories just like https://bugs.python.org/issue21323 enables processing the sub directories of /cgi-bin.
Does this make sense to you now?

----------
title: http.server is_cgi() does not correctly separate dir -> Improve is_cgi() in http.server
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Thu Nov 21 02:13:41 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 21 Nov 2019 07:13:41 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574320421.75.0.649291813566.issue38863@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Thanks, Siwon Kang, I now understood what you want to say.
I left some comments on your PR 17312.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Thu Nov 21 02:20:56 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 21 Nov 2019 07:20:56 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574320856.83.0.171598692748.issue38863@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@martin.panter, @asvetlov

I add the core developers who looks like to be experts on this module.
Can you follow up on Siwon's PR?

Thanks for your understanding.

----------
nosy: +asvetlov, martin.panter
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Thu Nov 21 02:48:21 2019
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 21 Nov 2019 07:48:21 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574322501.23.0.227267255627.issue38870@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

After PR 17302 is accepted, I'll work on refactorings including a precedence algorithm to find when to parentheses.

----------
nosy: +Batuhan Taskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Thu Nov 21 02:52:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 07:52:02 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574322722.77.0.086207911845.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5dcc06f6e0d7b5d6589085692b86c63e35e2325e by Victor Stinner in branch 'master':
bpo-38858: Allocate small integers on the heap (GH-17301)
https://github.com/python/cpython/commit/5dcc06f6e0d7b5d6589085692b86c63e35e2325e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Thu Nov 21 02:52:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 07:52:54 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574322774.2.0.769938523394.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-38858: Allocate small integers on the heap (GH-17301)

I associated this change to this issue because I had troubles when I tried to call _PyLong_Fini() in subinterpreters. I'm now trying to have different small integers per interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Thu Nov 21 03:03:36 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Thu, 21 Nov 2019 08:03:36 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574323416.35.0.814017988442.issue38688@roundup.psfhosted.org>


Bruno P. Kinoshita <brunodepaulak at yahoo.com.br> added the comment:

Hi Giampaolo,

I think it is more or less the same as the previous code, which was using os.list to return a list in memory. My first tentative fix was:

    def copytree(src, ...):
        entries = os.list(src)
        return _copytree(entries=entries, ...)

But the previous PR also altered _copytree to use the return of os.scandir DirEntry's, so the change above results in AttributeError: 'str' object has no attribute 'name'.

Would be better to avoid using iterator to populate a list, and also using the DirEntry in _copytree, and just stick with the previous code with (i.e. os.listdir() and a single copytree method as before)? Or if you think we should go with your suggestion, I'm good with it as well - especially as it'd be a much simpler PR :)

Thanks
Bruno

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Thu Nov 21 03:10:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 08:10:36 +0000
Subject: [issue38875] test_capi: test_trashcan_python_class1() and
 test_trashcan_python_class2() take one minute on my laptop
Message-ID: <1574323835.96.0.743188820296.issue38875@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

bpo-35983 added new tests to test_capi: test_capi now takes 1 minute 31 seconds :-( Previously, test_capi only took 9.5 seconds!

commit 351c67416ba4451eb3928fa0b2e933c2f25df1a3
Author: Jeroen Demeyer <J.Demeyer at UGent.be>
Date:   Fri May 10 19:21:11 2019 +0200

    bpo-35983: skip trashcan for subclasses (GH-11841)
    
    Add new trashcan macros to deal with a double deallocation that could occur when the `tp_dealloc` of a subclass calls the `tp_dealloc` of a base class and that base class uses the trashc
an mechanism.
    
    Patch by Jeroen Demeyer.

Attached PR modify these two tests to require the "cpu" resource. So by default, tests are not run and test_capi takes again 9.5 seconds instead of 1 min 30 sec.

Note: Travis CI runs the test suite using -uall,-cpu.

----------
components: Tests
messages: 357142
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_capi: test_trashcan_python_class1() and test_trashcan_python_class2() take one minute on my laptop
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38875>
_______________________________________

From report at bugs.python.org  Thu Nov 21 03:12:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 08:12:35 +0000
Subject: [issue38875] test_capi: test_trashcan_python_class1() and
 test_trashcan_python_class2() take one minute on my laptop
In-Reply-To: <1574323835.96.0.743188820296.issue38875@roundup.psfhosted.org>
Message-ID: <1574323955.89.0.979297321665.issue38875@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38875>
_______________________________________

From report at bugs.python.org  Thu Nov 21 03:16:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 08:16:20 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574324180.15.0.516645031898.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16802
pull_request: https://github.com/python/cpython/pull/17315

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Thu Nov 21 03:47:18 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 21 Nov 2019 08:47:18 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574326038.85.0.654908964649.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

So after trying a few different implementations, I don't think the proposal to simply change `SO_REUSEADDR` -> `SO_REUSEPORT` will work, due to Windows incompatibility (based on the results from Azure Pipelines). `SO_REUSEADDR` is supported on Windows, but not `SO_REUSEPORT`. 

So, if we essentially make the `reuse_address` parameter an alias for `reuse_port`, it will lead to some rather confusing errors for Windows users that are explicitly passing `reuse_address=True` for `create_datagram_endpoint()`. I don't think having incompatibility with Windows users is a viable option.

As a result, I will make the modifications to GH-17311 to implement Antoine's proposal. I'm not a huge fan of the user maintenance cost that it will cause for those who are currently passing `reuse_address=True` in 3.5+. But IMO, that's a lot better than leaving open a significant security vulnerability for older supported versions of Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Nov 21 03:56:37 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Nov 2019 08:56:37 +0000
Subject: [issue38873] find_library for libcrypto and libssl on Catalina
 returns the unversioned library
In-Reply-To: <1574303842.17.0.619288709802.issue38873@roundup.psfhosted.org>
Message-ID: <1574326597.0.0.233578001891.issue38873@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

How would having a "find the latest version" help here?  The point is Apple does not want you to use *any* version of libcrypto in /usr/lib: they are there only for old versions of third-party apps that were linked to a specific then-current version of the system libcrypto with a specific ABI.  For libssl and libcrypto, Apple has been saying for many releases you need to supply your own versions; they haven't been supplying the header files for them in the SDKs for several releases and now this.  If an app *is* trying to use an old version (which it shouldn't!), it does need to munge a specific version.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38873>
_______________________________________

From report at bugs.python.org  Thu Nov 21 04:00:39 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 21 Nov 2019 09:00:39 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574326839.57.0.959133956371.issue37228@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

I was assuming we'd only do this on Linux, since that's where the bug is... though now that you mention it the Windows behavior is probably wonky too.

SO_REUSEADDR and SO_REUSEPORT have different semantics on all three of Windows/BSD/Linux. A higher-level interface like asyncio doesn't necessarily want to map its kwargs directly to non-portable low-level options like this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Nov 21 04:37:33 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 21 Nov 2019 09:37:33 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574329053.75.0.504146813904.issue38688@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

The speedup introduced in issue33695 is mostly because the number of os.stat() syscall was reduced from 6 to 1 per file (both by using scandir() and because stat() results are cached and passed around between function calls). As such, even if we immediately consume scandir() iterator I believe it won't have a meaningful impact in terms of speed. FWIW issue33695 has a benchmark script attached (but it's not very stable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:05:06 2019
From: report at bugs.python.org (Jackson Riley)
Date: Thu, 21 Nov 2019 10:05:06 +0000
Subject: [issue38866] test_pyclbr replace asyncore
In-Reply-To: <1574270826.5.0.92652602871.issue38866@roundup.psfhosted.org>
Message-ID: <1574330706.57.0.935387117545.issue38866@roundup.psfhosted.org>


Change by Jackson Riley <jacriley at cisco.com>:


----------
pull_requests: +16803
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17316

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38866>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:06:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 10:06:22 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1574330782.08.0.991895793382.issue33387@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Mark merged his PR 6641 but forgot to mention bpo-33387:

commit fee552669f21ca294f57fe0df826945edc779090
Author: Mark Shannon <mark at hotpy.org>
Date:   Thu Nov 21 09:11:43 2019 +0000

    Produce cleaner bytecode for 'with' and 'async with' by generating separate code for normal and exceptional paths. (#6641)
    
    Remove BEGIN_FINALLY, END_FINALLY, CALL_FINALLY and POP_FINALLY bytecodes. Implement finally blocks by code duplication.
    Reimplement frame.lineno setter using line numbers rather than bytecode offsets.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:07:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 10:07:05 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1574330825.19.0.570458981742.issue33387@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The new doc seems to use Python version 3.8, but the change was merged into master which is the future Python 3.9, no?

 .. opcode:: RERAISE 

     Re-raises the exception currently on top of the stack. 

     .. versionadded:: 3.8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:14:39 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Thu, 21 Nov 2019 10:14:39 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574331279.6.0.311062640533.issue38688@roundup.psfhosted.org>


Bruno P. Kinoshita <brunodepaulak at yahoo.com.br> added the comment:

I really liked that improvement, and didn't think it needed to be removed. That's why the PR reverts it partially. I think the os.stat improvements were in the other methods changed, and should not be changed in my PR - unless I changed it by accident.

So with the current PR for this issue, or with your suggested patch, both should have similar performance I think. (I hadn't seen that script to measure performance, thanks.)

I am happy if we revert partially, or if we build the fix on top of the current code consuming the iterator. Should I update the PR with your suggested fix then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:15:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 10:15:44 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574331344.57.0.351133659581.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue, the change introduced a reference leak :-( Example:

$ ./python -m test -R 3:3 test_atexit -m test.test_atexit.SubinterpreterTest.test_callbacks_leak
0:00:00 load avg: 1.12 Run tests sequentially
0:00:00 load avg: 1.12 [1/1] test_atexit
beginning 6 repetitions
123456
......
test_atexit leaked [3988, 3986, 3988] references, sum=11962
test_atexit leaked [940, 939, 940] memory blocks, sum=2819
test_atexit failed

== Tests result: FAILURE ==

1 test failed:
    test_atexit

Total duration: 466 ms
Tests result: FAILURE


It seems like each _testcapi.run_in_subinterp("pass") call leaks 3988 references.

I tried tracemalloc to see where the memory allocation are done, but tracemalloc reports a single Python line: the _testcapi.run_in_subinterp() call...

I tried to follow the increase of references using a watchpoint in gdb on _Py_RefTotal, but it takes a lot of time to follow each Py_INCREF/Py_DECREF knowning that we are talking aobut around 4,000 references.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:17:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 10:17:00 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574331420.8.0.674198841181.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Even if the test is simplified to the following code, it does still leak:

    def test_callbacks_leak(self):
        _testcapi.run_in_subinterp("pass")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:17:06 2019
From: report at bugs.python.org (PCManticore)
Date: Thu, 21 Nov 2019 10:17:06 +0000
Subject: [issue38526] zipfile.Path has the wrong method name
In-Reply-To: <1571485638.73.0.512747413003.issue38526@roundup.psfhosted.org>
Message-ID: <1574331426.83.0.201492939567.issue38526@roundup.psfhosted.org>


Change by PCManticore <pcmanticore at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38526>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:22:35 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 21 Nov 2019 10:22:35 +0000
Subject: [issue38852] test_recursion_limit in test_threading crashes with
 SIGSEGV on android
In-Reply-To: <1574193737.03.0.937540674169.issue38852@roundup.psfhosted.org>
Message-ID: <1574331755.23.0.255800598509.issue38852@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The crash occurs only on debug builds.

See the FreeBSD related issue #37906.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38852>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:23:28 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 21 Nov 2019 10:23:28 +0000
Subject: [issue37906] FreeBSD: test_threading: test_recursion_limit() crash
 with SIGSEGV and create a coredump
In-Reply-To: <1566391523.37.0.328762522638.issue37906@roundup.psfhosted.org>
Message-ID: <1574331808.46.0.0969057585803.issue37906@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

See the android related issue #38852.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37906>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:26:32 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 21 Nov 2019 10:26:32 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574331992.72.0.497021488852.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I was assuming we'd only do this on Linux, since that's where the bug is... though now that you mention it the Windows behavior is probably wonky too.

Yeah, but I'm not confident that the bug is exclusive to Linux. From what I've seen, it's a fairly common trend for security vulnerabilities on Linux to also be applicable to Windows in some way, especially for similar low-level OS APIs. So unless we're confident that the issue is exclusive to Linux, I think it would be safer/better in the long term to apply the change platform independently.

In the short term, it will likely be a minor inconvenience and maintenance cost to users explicitly passing `reuse_address=True`. But, I think it's worthwhile in this particular case, especially since the majority of users don't seem to be doing that (based on my earlier search results).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:31:23 2019
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 21 Nov 2019 10:31:23 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1574332283.56.0.577591897506.issue33387@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +16805
pull_request: https://github.com/python/cpython/pull/17318

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:32:28 2019
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 21 Nov 2019 10:32:28 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1574332348.62.0.378643173868.issue33387@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Thanks for noticing.
https://github.com/python/cpython/pull/17318

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:33:52 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 21 Nov 2019 10:33:52 +0000
Subject: [issue38859] AsyncMock says it raises StopIteration but that is
 Impossible
In-Reply-To: <1574208869.25.0.189658973106.issue38859@roundup.psfhosted.org>
Message-ID: <1574332432.34.0.354111905849.issue38859@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38859>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:38:36 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 21 Nov 2019 10:38:36 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574332716.23.0.0449696519762.issue38688@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

PR-17098 as it stands re-introduces some stat() syscall. I suggest to just consume the iterator: it's a small change and it should fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Thu Nov 21 05:49:41 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Thu, 21 Nov 2019 10:49:41 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574333381.31.0.994084954915.issue38688@roundup.psfhosted.org>


Bruno P. Kinoshita <brunodepaulak at yahoo.com.br> added the comment:

Done. Rebased on master too, and edited commit message & GH PR title. Thanks Giampaolo!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Thu Nov 21 06:08:53 2019
From: report at bugs.python.org (Callum Ward)
Date: Thu, 21 Nov 2019 11:08:53 +0000
Subject: [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1574334533.08.0.0521368669095.issue29275@roundup.psfhosted.org>


Callum Ward <wards.callum at gmail.com> added the comment:

I'd like to work on this issue. I'll come up with a PR today.

----------
nosy: +callumquick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29275>
_______________________________________

From report at bugs.python.org  Thu Nov 21 06:22:59 2019
From: report at bugs.python.org (Linus Pithan)
Date: Thu, 21 Nov 2019 11:22:59 +0000
Subject: [issue38876] pickle is raising KeyError insteat of
 pickle.UnpicklingError under certain conditions
Message-ID: <1574335379.18.0.441188503497.issue38876@roundup.psfhosted.org>


New submission from Linus Pithan <linus.pithan at gmail.com>:

When unpickling fails one would expect a pickle.UnpicklingError exception or at least a PickleError. However, when trying

pickle.loads(b"jens:")

it fails with KeyError: 980643429 which is not the wanted behaviour.

----------
components: Library (Lib)
messages: 357159
nosy: Linus Pithan
priority: normal
severity: normal
status: open
title: pickle is raising KeyError insteat of pickle.UnpicklingError under certain conditions
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38876>
_______________________________________

From report at bugs.python.org  Thu Nov 21 06:26:37 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 21 Nov 2019 11:26:37 +0000
Subject: [issue38876] pickle is raising KeyError insteat of
 pickle.UnpicklingError under certain conditions
In-Reply-To: <1574335379.18.0.441188503497.issue38876@roundup.psfhosted.org>
Message-ID: <1574335597.19.0.950535014609.issue38876@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya, alexandre.vassalotti
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38876>
_______________________________________

From report at bugs.python.org  Thu Nov 21 06:47:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 11:47:38 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574336858.41.0.786668168307.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> test_atexit leaked [3988, 3986, 3988] references, sum=11962

The following patch fix it:

diff --git a/Python/pylifecycle.c b/Python/pylifecycle.c
index 7591f069b4..f088ef0bce 100644
--- a/Python/pylifecycle.c
+++ b/Python/pylifecycle.c
@@ -1210,6 +1210,15 @@ finalize_interp_clear(PyThreadState *tstate)
 {
     int is_main_interp = _Py_IsMainInterpreter(tstate);
 
+    _PyImport_Cleanup(tstate);
+
+    /* Explicitly break a reference cycle between the encodings module and XXX */
+    PyInterpreterState *interp = tstate->interp;
+    Py_CLEAR(interp->codec_search_path);
+    Py_CLEAR(interp->codec_search_cache);
+    Py_CLEAR(interp->codec_error_registry);
+    _PyGC_CollectNoFail();
+
     /* Clear interpreter state and all thread states */
     PyInterpreterState_Clear(tstate->interp);
 
@@ -1640,7 +1649,6 @@ Py_EndInterpreter(PyThreadState *tstate)
         Py_FatalError("Py_EndInterpreter: not the last thread");
     }
 
-    _PyImport_Cleanup(tstate);
     finalize_interp_clear(tstate);
     finalize_interp_delete(tstate);
 }



Py_NewInterpreter() indirectly calls "import encodings" which calls codecs.register(search_function). This encodings function is stored in interp->codec_search_path and so keeps encodings module dict alive.

_PyImport_Cleanup() removes the last reference to the encodings *module*, but the module deallocator function (module_dealloc()) doesn't clear the dict: it only removes its strong reference to it ("Py_XDECREF(m->md_dict);").

interp->codec_search_path is cleared by PyInterpreterState_Clear() which is called by Py_EndInterpreter(). But it is not enough to clear some objets. I'm not sure if encodings module dict is still alive at this point, but it seems like at least the sys module dict is still alive.

I can push my workaround which manually "break a reference cycle" (really? which one?), but I may be interested to dig into this issue to check if we cannot find a better design.

_PyImport_Cleanup() and _PyModule_Clear() functions are fragile. They implement smart heuristics to attempt to keep Python functional as long as possible *and* try to clear everything. The intent is to be able to log warnings and exceptions during the Python shutdown, for example.

The problem is that the heuristic keeps some objects alive longer than expected. For example, I would expect that _PyImport_Cleanup() not only calls sys.modules.clear(), but also clears the dict of each module (module.__dict__.clear()). It doesn't, and I'm not sure why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Thu Nov 21 06:54:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 11:54:07 +0000
Subject: [issue38875] test_capi: test_trashcan_python_class1() and
 test_trashcan_python_class2() take one minute on my laptop
In-Reply-To: <1574323835.96.0.743188820296.issue38875@roundup.psfhosted.org>
Message-ID: <1574337247.06.0.958804266829.issue38875@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0127bb1c5c3286f87e284ff6083133bfdcfd5a4f by Victor Stinner in branch 'master':
bpo-38875: test_capi: trashcan tests require cpu resource (GH-17314)
https://github.com/python/cpython/commit/0127bb1c5c3286f87e284ff6083133bfdcfd5a4f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38875>
_______________________________________

From report at bugs.python.org  Thu Nov 21 06:54:28 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 11:54:28 +0000
Subject: [issue38875] test_capi: test_trashcan_python_class1() and
 test_trashcan_python_class2() take one minute on my laptop
In-Reply-To: <1574323835.96.0.743188820296.issue38875@roundup.psfhosted.org>
Message-ID: <1574337268.37.0.543042362047.issue38875@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16806
pull_request: https://github.com/python/cpython/pull/17319

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38875>
_______________________________________

From report at bugs.python.org  Thu Nov 21 06:54:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 11:54:57 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574337297.65.0.223917440983.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3ab479a2d1959923c9ab80c227dd1f39720b4e2d by Victor Stinner in branch 'master':
bpo-38692: Skip test_posix.test_pidfd_open() on EPERM (GH-17290)
https://github.com/python/cpython/commit/3ab479a2d1959923c9ab80c227dd1f39720b4e2d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Thu Nov 21 06:56:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 11:56:41 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574337401.31.0.784180363409.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I pushed my "Skip test_posix.test_pidfd_open() on EPERM" change just for practical reasons. We can hope that Linux sandboxes will shortly be updated to allow pidfd_open() syscall. It should be safe for most use cases ;-) I close again the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Thu Nov 21 07:11:48 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 12:11:48 +0000
Subject: [issue38875] test_capi: test_trashcan_python_class1() and
 test_trashcan_python_class2() take one minute on my laptop
In-Reply-To: <1574323835.96.0.743188820296.issue38875@roundup.psfhosted.org>
Message-ID: <1574338308.0.0.0708185881558.issue38875@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 767b42633bb7ac39dd6743d8dd7f5b5cc122acea by Miss Islington (bot) in branch '3.8':
bpo-38875: test_capi: trashcan tests require cpu resource (GH-17314)
https://github.com/python/cpython/commit/767b42633bb7ac39dd6743d8dd7f5b5cc122acea


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38875>
_______________________________________

From report at bugs.python.org  Thu Nov 21 07:15:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 12:15:10 +0000
Subject: [issue38875] test_capi: test_trashcan_python_class1() and
 test_trashcan_python_class2() take one minute on my laptop
In-Reply-To: <1574323835.96.0.743188820296.issue38875@roundup.psfhosted.org>
Message-ID: <1574338510.63.0.0973634413417.issue38875@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38875>
_______________________________________

From report at bugs.python.org  Thu Nov 21 07:50:43 2019
From: report at bugs.python.org (Damien LEFEVRE)
Date: Thu, 21 Nov 2019 12:50:43 +0000
Subject: [issue38680] PyGILState_Release does not release gil correctly,
 resulting in deadlock
In-Reply-To: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>
Message-ID: <1574340643.75.0.486953257135.issue38680@roundup.psfhosted.org>


Damien LEFEVRE <lefevre.da at gmail.com> added the comment:

Here is a code example reproducing the issue.

----------
Added file: https://bugs.python.org/file48728/interpreterlock.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________

From report at bugs.python.org  Thu Nov 21 08:00:10 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 21 Nov 2019 13:00:10 +0000
Subject: [issue38874] asyncio.Queue: putting items out of order when it is full
In-Reply-To: <1574306754.82.0.07273997342.issue38874@roundup.psfhosted.org>
Message-ID: <1574341210.76.0.165521200417.issue38874@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I still don't understand the problem.
If the queue is full new items still are added in the order of `await q.put()` calls.
If there are multiple producers the order of adding items into the queue is still the order of `q.put()`.

Do you have a code example that demonstrates the opposite behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38874>
_______________________________________

From report at bugs.python.org  Thu Nov 21 08:08:15 2019
From: report at bugs.python.org (PCManticore)
Date: Thu, 21 Nov 2019 13:08:15 +0000
Subject: [issue38876] pickle is raising KeyError insteat of
 pickle.UnpicklingError under certain conditions
In-Reply-To: <1574335379.18.0.441188503497.issue38876@roundup.psfhosted.org>
Message-ID: <1574341695.04.0.506533374591.issue38876@roundup.psfhosted.org>


PCManticore <pcmanticore at gmail.com> added the comment:

It seems there are a couple of places in `_pickle.c` where we favour a `KeyError` instead of `UnpicklingError` such as https://github.com/python/cpython/blob/master/Modules/_pickle.c#L6178. From a quick debugging it seems it originates in `load_long_binget`. 

Ideally those places should return `UnpicklingError` instead, not sure why a `KeyError` was preferred. Happy to submit a patch if that's a change that makes sense.

----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38876>
_______________________________________

From report at bugs.python.org  Thu Nov 21 08:28:49 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Thu, 21 Nov 2019 13:28:49 +0000
Subject: [issue38877] Python 3.9 build fails under Debian 9.11
Message-ID: <1574342929.28.0.219657775235.issue38877@roundup.psfhosted.org>


New submission from Florian Dahlitz <f2dahlitz at freenet.de>:

Today, I tried to build Python 3.9 from source, which failed. Building it without optimizations enabled fails due to an Segmentation fault (output_without.txt) and building with optimizations fails with a profile-opt error (output.txt).

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux bullseye/sid
Release:	9.11
Codename:	stretch

----------
components: Build
files: output.txt
messages: 357168
nosy: DahlitzFlorian
priority: normal
severity: normal
status: open
title: Python 3.9 build fails under Debian 9.11
type: compile error
versions: Python 3.9
Added file: https://bugs.python.org/file48729/output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38877>
_______________________________________

From report at bugs.python.org  Thu Nov 21 08:29:43 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Thu, 21 Nov 2019 13:29:43 +0000
Subject: [issue38877] Python 3.9 build fails under Debian 9.11
In-Reply-To: <1574342929.28.0.219657775235.issue38877@roundup.psfhosted.org>
Message-ID: <1574342983.83.0.366622405866.issue38877@roundup.psfhosted.org>


Change by Florian Dahlitz <f2dahlitz at freenet.de>:


Added file: https://bugs.python.org/file48730/output_without.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38877>
_______________________________________

From report at bugs.python.org  Thu Nov 21 08:48:29 2019
From: report at bugs.python.org (Phil Connell)
Date: Thu, 21 Nov 2019 13:48:29 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1574344109.21.0.479934626407.issue33608@roundup.psfhosted.org>


Phil Connell <pconnell at gmail.com> added the comment:

Based on Victor's info from https://bugs.python.org/issue36114#msg337090 I believe the crash is essentially what's reproduced in the attached program.

>From the root of a (built) cpython clone run:

gcc -c -o fini_crash.o -IInclude -I. fini_crash.c && gcc -o fini_crash fini_crash.o libpython3.9.a -lcrypt -lpthread -ldl -lutil -lm && ./fini_crash

The output should be:

MAIN: allow other thread to execute                                                                                    
OTHER: acquired GIL                                                                                                    
OTHER: released GIL                                                                                                    
MAIN: interpreter finalized
OTHER: attempt to acquire GIL...crash!
[1]    266749 segmentation fault (core dumped)  ./fini_crash

And running it through valgrind:

$ valgrind --suppressions=Misc/valgrind-python.supp fini_crash                                                                                                                 -- COMMAND -- 13:4[12/5973]
==266836== Memcheck, a memory error detector
==266836== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==266836== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==266836== Command: fini_crash                    
==266836==                                            
MAIN: allow other thread to execute                       
OTHER: acquired GIL                                
OTHER: released GIL                                                                                                    
MAIN: interpreter finalized
OTHER: attempt to acquire GIL...crash!                                                                                 
==266836== Thread 2:                                                                                                   
==266836== Invalid read of size 8                                                                                      
==266836==    at 0x15607D: PyEval_RestoreThread (ceval.c:389)                                                                                                                                                                                  
==266836==    by 0x15479F: evil_main (in /home/phconnel/dev/cpython/fini_crash)
==266836==    by 0x48B94CE: start_thread (in /usr/lib/libpthread-2.30.so)
==266836==    by 0x4B232D2: clone (in /usr/lib/libc-2.30.so)
==266836==  Address 0x4d17270 is 16 bytes inside a block of size 264 free'd
==266836==    at 0x48399AB: free (vg_replace_malloc.c:540)
==266836==    by 0x1773FF: tstate_delete_common (pystate.c:829)
==266836==    by 0x1773FF: _PyThreadState_Delete (pystate.c:848)
==266836==    by 0x1773FF: zapthreads (pystate.c:311)
==266836==    by 0x1773FF: PyInterpreterState_Delete (pystate.c:321)
==266836==    by 0x174920: finalize_interp_delete (pylifecycle.c:1242)
==266836==    by 0x174920: Py_FinalizeEx.part.0 (pylifecycle.c:1400)
==266836==    by 0x15487B: main (in /home/phconnel/dev/cpython/fini_crash)
==266836==  Block was alloc'd at
==266836==    at 0x483877F: malloc (vg_replace_malloc.c:309)
==266836==    by 0x178D7C: new_threadstate (pystate.c:557)
==266836==    by 0x178D7C: PyThreadState_New (pystate.c:629)
==266836==    by 0x178D7C: PyGILState_Ensure (pystate.c:1288)
==266836==    by 0x154759: evil_main (in /home/phconnel/dev/cpython/fini_crash)
==266836==    by 0x48B94CE: start_thread (in /usr/lib/libpthread-2.30.so)
==266836==    by 0x4B232D2: clone (in /usr/lib/libc-2.30.so)
==266836== 
==266836== Invalid read of size 8
==266836==    at 0x156081: PyEval_RestoreThread (ceval.c:389)
==266836==    by 0x15479F: evil_main (in /home/phconnel/dev/cpython/fini_crash)
==266836==    by 0x48B94CE: start_thread (in /usr/lib/libpthread-2.30.so)
==266836==    by 0x4B232D2: clone (in /usr/lib/libc-2.30.so)
==266836==  Address 0x4c3a0f0 is 16 bytes inside a block of size 2,960 free'd
==266836==    at 0x48399AB: free (vg_replace_malloc.c:540)
==266836==    by 0x174920: finalize_interp_delete (pylifecycle.c:1242)
==266836==    by 0x174920: Py_FinalizeEx.part.0 (pylifecycle.c:1400)
==266836==    by 0x15487B: main (in /home/phconnel/dev/cpython/fini_crash)
==266836==  Block was alloc'd at
==266836==    at 0x483877F: malloc (vg_replace_malloc.c:309)
==266836==    by 0x177153: PyInterpreterState_New (pystate.c:205)
==266836==    by 0x1732BF: pycore_create_interpreter (pylifecycle.c:526)
==266836==    by 0x1732BF: pyinit_config.constprop.0 (pylifecycle.c:695)
==266836==    by 0x1766B7: pyinit_core (pylifecycle.c:879)
==266836==    by 0x1766B7: Py_InitializeFromConfig (pylifecycle.c:1055)
==266836==    by 0x1766B7: Py_InitializeEx (pylifecycle.c:1093)
==266836==    by 0x154801: main (in /home/phconnel/dev/cpython/fini_crash)
==266836==

----------
Added file: https://bugs.python.org/file48731/fini_crash.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Thu Nov 21 08:55:58 2019
From: report at bugs.python.org (Phil Connell)
Date: Thu, 21 Nov 2019 13:55:58 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1574344558.04.0.161892905653.issue33608@roundup.psfhosted.org>


Phil Connell <pconnell at gmail.com> added the comment:

Just to summarise, I'm fairly sure this is exactly what Victor saw: a daemon thread attempts to reacquire the GIL via Py_END_ALLOW_THREADS after interpreter finalisation. Obviously the threadstate pointer held by the thread is then invalid...so we crash.

So I see basically two options:

1. Don't (always) free threadstate structures in Py_Finalize, and figure out a way to avoid leaking them (if Python is re-initialized in the same process).

2. Ban this behaviour entirely, e.g. have Py_Finalize fail if there are live threads with threadstate objects.

The discussion so far assumes that we should support this, i.e. #1. Any thoughts on that? (I'll have a think about whether this is actually doable!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Thu Nov 21 08:59:27 2019
From: report at bugs.python.org (Callum Ward)
Date: Thu, 21 Nov 2019 13:59:27 +0000
Subject: [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1574344767.92.0.413920404243.issue29275@roundup.psfhosted.org>


Change by Callum Ward <wards.callum at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29275>
_______________________________________

From report at bugs.python.org  Thu Nov 21 09:31:26 2019
From: report at bugs.python.org (Svetlana Vodianova)
Date: Thu, 21 Nov 2019 14:31:26 +0000
Subject: [issue38868] Shutil cannot delete a folder that contains an .ini file
In-Reply-To: <1574280283.41.0.914167266294.issue38868@roundup.psfhosted.org>
Message-ID: <1574346686.36.0.143069097664.issue38868@roundup.psfhosted.org>


Svetlana Vodianova <svetlana.vodianova69 at gmx.com> added the comment:

What is the system error code (winerror) of the PermissionError?

PermissionError: [WinError 5] Access is denied


Note: Please ignore my first post (msg357097) describing the problem, I made a few mistakes that might be confusing. msg357099 better describes my problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38868>
_______________________________________

From report at bugs.python.org  Thu Nov 21 09:47:56 2019
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 21 Nov 2019 14:47:56 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1574347676.06.0.51340451278.issue33387@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 82f897bf8f72d09f537054d64a94e645ad23d8d6 by Mark Shannon in branch 'master':
Correct release version to 3.9 for RERAISE and WITH_EXCEPT_START bytecodes. (#17318)
https://github.com/python/cpython/commit/82f897bf8f72d09f537054d64a94e645ad23d8d6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Thu Nov 21 09:56:00 2019
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 21 Nov 2019 14:56:00 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574348160.12.0.79050595806.issue38500@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Brett,
PEP 523 makes no mention of adding a getter or setter.
Adding them is a big change to Python semantics and shouldn't, IMO, be done without a PEP that explicit states they are going to be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov 21 10:00:21 2019
From: report at bugs.python.org (Bar Harel)
Date: Thu, 21 Nov 2019 15:00:21 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
Message-ID: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>


New submission from Bar Harel <bzvi7919 at gmail.com>:

Quick and small fix.

os.PathLike.__subclasshook__ does not check if cls is PathLike as abstract classes should.

This in turn causes this bug:

    class A(PathLike):
        pass

    class B:
        def __fspath__(self):
            pass

    assert issubclass(B, A)

I will fix the bug later today and push a patch over to python/cpython on GitHub.

----------
components: Library (Lib)
messages: 357174
nosy: bar.harel
priority: normal
severity: normal
status: open
title: os.PathLike subclasshook causes subclass checks true on abstract implementation
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Thu Nov 21 10:08:05 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 21 Nov 2019 15:08:05 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574348885.87.0.572474757094.issue38870@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@gvanrossum are you OK with adding type comments support? Current version loses type comment information so if typed_ast parses this, they wont be the same in AST representation.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Thu Nov 21 10:08:06 2019
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 21 Nov 2019 15:08:06 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574348886.05.0.765635897291.issue38500@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Fabio,

Can you give me a specific example where changing the bytecode via the `__code__` attribute of a function does not work as expected?

I am assuming that adding a breakpoint on a line is equivalent to adding `breakpoint();` at the beginning of that line. If the bytecode of a function is modified dynamically, say by a decorator, then it is unclear what should be done, and it is hard to claim that any particular approach is more correct.
However, assuming that the change is well defined and keeps the mapping to the original code, then adding a breakpoint to the modified code should work just as well before or after modification.

As an example, consider http://code.activestate.com/recipes/277940-decorator-for-bindingconstants-at-compile-time/ which provides a means of converting global variable reads to constants.  In that case the order in which the decorator and breakpoint insertion are applied shouldn't matter.

I propose a new method on code objects `withCallAtLine(callable: Callable[], line:int)` which returns a new code object with calls to the given callable at the given line.
A breakpoint can then be inserted at line L in function f with `f.__code__ = f.__code__.withCallAtLine(sys.breakpoint, L)`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov 21 10:22:22 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 21 Nov 2019 15:22:22 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574349742.47.0.472073237785.issue38878@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Thu Nov 21 10:33:05 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Thu, 21 Nov 2019 15:33:05 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574350385.2.0.688155863947.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

>  A higher-level interface like asyncio doesn't necessarily want to map its kwargs directly to non-portable low-level options like this.

Also reuse_port has portability issues, the whole portability mess i s nicely summed up in: https://stackoverflow.com/questions/14388706/how-do-so-reuseaddr-and-so-reuseport-differ

And the docs say that "If the SO_REUSEPORT constant is not defined then this capability is unsupported." which is true but the converse is not - some platforms apparently do have SO_REUSEPORT defined but the option still doesn't work, resulting in a ValueError exception from create_datagram_endpoint().

So to create truly portable code, the developer who really wants to use these options has to know differences between underlying OS and kernel versions, catch errors that shouldn't happen according to docs and then try again with different options. 

This is ok for lower level APIs like socket.socket where things map 1:1 to system calls but not a good thing on higher level APIs as you point out. In my C++ projects that use these, I just have a #ifdef block for every OS and don't even try to abstract it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Nov 21 10:36:58 2019
From: report at bugs.python.org (Laurie Opperman)
Date: Thu, 21 Nov 2019 15:36:58 +0000
Subject: [issue36077] Inheritance dataclasses fields and default init statement
In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org>
Message-ID: <1574350618.1.0.824401681405.issue36077@roundup.psfhosted.org>


Change by Laurie Opperman <laurie_opperman at hotmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36077>
_______________________________________

From report at bugs.python.org  Thu Nov 21 10:39:00 2019
From: report at bugs.python.org (Laurie Opperman)
Date: Thu, 21 Nov 2019 15:39:00 +0000
Subject: [issue36077] Inheritance dataclasses fields and default init statement
In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org>
Message-ID: <1574350740.82.0.611800272222.issue36077@roundup.psfhosted.org>


Laurie Opperman <laurie_opperman at hotmail.com> added the comment:

I've added a PR implementing Daniel L's suggestion

----------
nosy: +Epic_Wink
versions: +Python 3.6 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36077>
_______________________________________

From report at bugs.python.org  Thu Nov 21 11:02:09 2019
From: report at bugs.python.org (Phil Connell)
Date: Thu, 21 Nov 2019 16:02:09 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1574352129.36.0.130563817019.issue33608@roundup.psfhosted.org>


Phil Connell <pconnell at gmail.com> added the comment:

The attached patch (wrap_threadstate.diff) is enough to stop the crash. It's a slightly dirty proof-of-concept, but equally could be the basis for a solution.

The main functional issue is that there's still a race on the Py_BLOCK_THREADS side: it's possible that the "is threadstate still valid" check can pass, but the interpreter is finalised while the daemon thread is trying to reacquire the GIL in PyEval_RestoreThread.

(The Py_UNBLOCK_THREADS side is non-racy as the GIL is held while the ts and wrapper updates are done).

----------
Added file: https://bugs.python.org/file48732/wrap_threadstate.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Thu Nov 21 11:12:32 2019
From: report at bugs.python.org (=?utf-8?b?Wm9sdMOhbiBTemF0bcOhcnk=?=)
Date: Thu, 21 Nov 2019 16:12:32 +0000
Subject: [issue38879] Reordered error checking in PyArena_New().
Message-ID: <1574352752.3.0.334420443084.issue38879@roundup.psfhosted.org>


New submission from Zolt?n Szatm?ry <szatmary.zoltan1222 at gmail.com>:

Put "arena->a_cur = arena->a_head;" after the error checking of "arena->a_objects = PyList_New(0);". It's more optimal, even if it can't be measured.

----------
hgrepos: 386
messages: 357180
nosy: Zotyamester
priority: normal
pull_requests: 16809
severity: normal
status: open
title: Reordered error checking in PyArena_New().

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38879>
_______________________________________

From report at bugs.python.org  Thu Nov 21 11:12:54 2019
From: report at bugs.python.org (=?utf-8?b?Wm9sdMOhbiBTemF0bcOhcnk=?=)
Date: Thu, 21 Nov 2019 16:12:54 +0000
Subject: [issue38879] Reordered error checking in PyArena_New().
In-Reply-To: <1574352752.3.0.334420443084.issue38879@roundup.psfhosted.org>
Message-ID: <1574352774.44.0.313348441173.issue38879@roundup.psfhosted.org>


Change by Zolt?n Szatm?ry <szatmary.zoltan1222 at gmail.com>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38879>
_______________________________________

From report at bugs.python.org  Thu Nov 21 11:14:53 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Thu, 21 Nov 2019 16:14:53 +0000
Subject: [issue38880] Subinterpreters: List interpreters associated with a
 channel end
Message-ID: <1574352893.51.0.220552171167.issue38880@roundup.psfhosted.org>


New submission from Lewis Gaul <lewis.gaul at gmail.com>:

The public interpreters API being implemented for PEP 554 requires the ability to list interpreters associated with channel ends. This functionality needs adding in the internal subinterpreters module.

See https://github.com/ericsnowcurrently/multi-core-python/issues/52 and https://www.python.org/dev/peps/pep-0554/#api-for-sharing-data.

----------
messages: 357181
nosy: Lewis Gaul, eric.snow, nanjekyejoannah
priority: normal
severity: normal
status: open
title: Subinterpreters: List interpreters associated with a channel end
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38880>
_______________________________________

From report at bugs.python.org  Thu Nov 21 11:26:55 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Thu, 21 Nov 2019 16:26:55 +0000
Subject: [issue38880] Subinterpreters: List interpreters associated with a
 channel end
In-Reply-To: <1574352893.51.0.220552171167.issue38880@roundup.psfhosted.org>
Message-ID: <1574353615.23.0.410606250213.issue38880@roundup.psfhosted.org>


Change by Lewis Gaul <lewis.gaul at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38880>
_______________________________________

From report at bugs.python.org  Thu Nov 21 11:34:43 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 21 Nov 2019 16:34:43 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1574354083.86.0.783674223678.issue36264@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

Was pathlib forgotten here? Pathlib.home() is documented to return the same as expanduser("~") but it still prefers HOME instead of USERPROFILE.

Note that this change has some effect on cygwin/mingw environments which all set HOME and now potentially lead to programs no longer being able to find their config files. Not that I disagree with this change, just that it seems a bit rushed to me.

----------
nosy: +lazka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:01:22 2019
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 21 Nov 2019 17:01:22 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574355682.12.0.794122024827.issue38500@roundup.psfhosted.org>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

@Mark

First you have to explain to me how you envision changing the method code reliably in the debugger... 

Import hooks don't work (they'd break with something as simple as the code below)

def method():
   a = 10

mod = reload(old_mod)
old_mod.method.__code__ = mod.method.__code__

using the tracing also doesn't work (it's too late to change the code)

Note: consider the reload just an example, not the only use case (say, the user could pickle code objects to remote execution and the debugger should still work).

Also, consider you have to change the bytecode of methods which are only internal to a function (and thus can't be accessed from the outside).

Then, if you have a reliable way to do it, how do you keep track of those code objects to reapply the patching when breakpoints change? What if it adds a breakpoint to a new method, how do you locate it? Creating strong references to methods isn't an option because it would prevent things from being garbage collected (and you'd have to track all objects containing code objects for it to be reliable).

As a note, pydevd does have some support for hot-reloading, but there are too many corner-cases and it doesn't work 100% for live coding (it's an unsolved problem is Python) -- and I can't really envision it working for regular breakpoints as there are too many corner cases to handle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:25:14 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 17:25:14 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1574357114.12.0.93124900455.issue37838@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16811
pull_request: https://github.com/python/cpython/pull/17324

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:25:22 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 17:25:22 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1574357122.36.0.876275937518.issue37838@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16812
pull_request: https://github.com/python/cpython/pull/17325

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:25:23 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 21 Nov 2019 17:25:23 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1574357123.89.0.194656757924.issue37838@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 0aca3a3a1e68b4ca2d334ab5255dfc267719096e by Ivan Levkivskyi (benedwards14) in branch 'master':
bpo-37838: get_type_hints for wrapped functions with forward reference (GH-17126)
https://github.com/python/cpython/commit/0aca3a3a1e68b4ca2d334ab5255dfc267719096e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:35:22 2019
From: report at bugs.python.org (Iza Romanowska)
Date: Thu, 21 Nov 2019 17:35:22 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
Message-ID: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>


New submission from Iza Romanowska <izaromanowska at gmail.com>:

Hi, 
When zero weights are given, the last element of a sequence is always chosen. Example: 

hits= []
for i in range(100):
    hits.append(random.choices(["A","B","C","D"], [0, 0, 0, 0])[0])
print (set(hits))

>> {'D'}

I guess that most users would expect that in case of zero weights it will default into a random.choice behaviour and select one option at random since this is what happens in cases when all weights are equal. Alternatively, it should return an empty array if the assumption was that all choices have a zero probability of being selected. Either way, if it is consistently choosing one option, this may be potentially difficult to spot in situations when a sequence of weights all equal to zero only happen sporadically.

----------
components: Library (Lib)
messages: 357185
nosy: IRomanowska
priority: normal
severity: normal
status: open
title: unexpected behaviour of random.choices with zero weights
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:39:45 2019
From: report at bugs.python.org (Daniel Johnson)
Date: Thu, 21 Nov 2019 17:39:45 +0000
Subject: [issue38651] Add WolfSSL support
In-Reply-To: <1572467995.9.0.965883938595.issue38651@roundup.psfhosted.org>
Message-ID: <1574357985.79.0.916912457969.issue38651@roundup.psfhosted.org>


Daniel Johnson <djwirecat at gmail.com> added the comment:

Thank you for the replied. I understand completely and I don't think it would be simple patches to try and use the compatibility layer. I have discovered that the WolfSSL compatibility layer doesn't support the full OpenSSL API.

However, I have found that I can build Python without OpenSSL and then use the Python API that WolfSSL provides and that gets us 90% of the way there. I have decided to pursue that instead of trying to add WolfSSL support directly into Python.

I'm going to close this issue for now.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38651>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:43:20 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 17:43:20 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1574358200.33.0.118502061639.issue37838@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 30e5bd8471d7531d051796c01e8ede01ade883dc by Miss Islington (bot) in branch '3.7':
bpo-37838: get_type_hints for wrapped functions with forward reference (GH-17126)
https://github.com/python/cpython/commit/30e5bd8471d7531d051796c01e8ede01ade883dc


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:43:46 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 17:43:46 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1574358226.22.0.838424420884.issue37838@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9458c5c42bbe5fb6ef2393c9ee66f012a2c13ca3 by Miss Islington (bot) in branch '3.8':
bpo-37838: get_type_hints for wrapped functions with forward reference (GH-17126)
https://github.com/python/cpython/commit/9458c5c42bbe5fb6ef2393c9ee66f012a2c13ca3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:47:39 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 21 Nov 2019 17:47:39 +0000
Subject: [issue37838] typing.get_type_hints not working with
 forward-declaration and decorated functions
In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org>
Message-ID: <1574358459.0.0.294481939497.issue37838@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37838>
_______________________________________

From report at bugs.python.org  Thu Nov 21 12:48:39 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Nov 2019 17:48:39 +0000
Subject: [issue38877] Python 3.9 build fails under Debian 9.11
In-Reply-To: <1574342929.28.0.219657775235.issue38877@roundup.psfhosted.org>
Message-ID: <1574358519.54.0.188108579902.issue38877@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

What ./configure options did you use?  Did you do a make clean or equivalent between the two build attempts?  If you used --enable-shared, try without it.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38877>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:14:36 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 21 Nov 2019 18:14:36 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1574360076.26.0.263416952681.issue38857@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset b2744c1be73f5af0d2dc4b952389efc90c8de94e by Andrew Svetlov (Lisa Roach) in branch '3.8':
[3.8] bpo-38857: AsyncMock fix for awaitable values and StopIteration fix [3.8] (GH-17269) (#17304)
https://github.com/python/cpython/commit/b2744c1be73f5af0d2dc4b952389efc90c8de94e


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:16:58 2019
From: report at bugs.python.org (Lisa Roach)
Date: Thu, 21 Nov 2019 18:16:58 +0000
Subject: [issue38859] AsyncMock says it raises StopIteration but that is
 Impossible
In-Reply-To: <1574208869.25.0.189658973106.issue38859@roundup.psfhosted.org>
Message-ID: <1574360218.53.0.22837001021.issue38859@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

PR merged, thanks Jason!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38859>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:17:34 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Nov 2019 18:17:34 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1574360254.48.0.769362321571.issue36264@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Was pathlib forgotten here? Pathlib.home() is documented to return the same as expanduser("~") but it still prefers HOME instead of USERPROFILE.

Yes, it was forgotten (why doesn't it just use expanduser?). We should file a new bug for that.

> Note that this change has some effect on cygwin/mingw environments which all set HOME and now potentially lead to programs no longer being able to find their config files.

Firstly these are not supported environments, so it's not "rushed" for us to not preemptively consider them (though we'll happily merge most PRs that fix them without impacting supported environments).

And I thought the idea was that they'd use posixpath as os.path rather than ntpath? Cygwin in particular, which provides the full environment. MinGW is a bit lighter to be closer to normal Windows behaviour, which would suggest that using the Windows variables is preferable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:17:51 2019
From: report at bugs.python.org (Lisa Roach)
Date: Thu, 21 Nov 2019 18:17:51 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1574360271.35.0.730388833381.issue38857@roundup.psfhosted.org>


Change by Lisa Roach <lisaroach14 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:31:13 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Thu, 21 Nov 2019 18:31:13 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1574361073.77.0.607085575816.issue36225@roundup.psfhosted.org>


Lewis Gaul <lewis.gaul at gmail.com> added the comment:

I've put together a test along the lines of what Nick suggested, see the attached patch. Running this hits the Fatal 'remaining subinterpreters' error as expected:

```
   > ./Programs/_testembed test_bpo36225
--- Pass 0 ---
interp 0 <0x1A561A0>, thread state <0x1A56DD0>: id(modules) = 139707107673104
interp 1 <0x1A9D050>, thread state <0x1A87620>: id(modules) = 139707106987472
interp 2 <0x1B02210>, thread state <0x1AEC320>: id(modules) = 139706981531088
interp 0 <0x1A561A0>, thread state <0x1A56DD0>: id(modules) = 139707107673104
interp 3 <0x1B53740>, thread state <0x1AFD980>: id(modules) = 139706980408304
interp 4 <0x1BA3390>, thread state <0x1B3C7A0>: id(modules) = 139706979780944
interp 0 <0x1A561A0>, thread state <0x1A56DD0>: id(modules) = 139707107673104
Fatal Python error: PyInterpreterState_Delete: remaining subinterpreters
Python runtime state: finalizing (tstate=0x1a56dd0)

Aborted
```

I'm happy to look a bit further into the fix for this - Eric's pointers in this thread look useful to get started. @nanjekyejoannah did you get anywhere with this?

----------
keywords: +patch
nosy: +LewisGaul
Added file: https://bugs.python.org/file48733/finalise-subinterps-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:36:10 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 21 Nov 2019 18:36:10 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1574361370.42.0.988083144505.issue36264@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

> Was pathlib forgotten here? Pathlib.home() is documented to return
> the same as expanduser("~") but it still prefers HOME instead of
> USERPROFILE.
> 
> Yes, it was forgotten (why doesn't it just use expanduser?). We
> should file a new bug for that.

I'll file one.

> > Note that this change has some effect on cygwin/mingw environments
> which all set HOME and now potentially lead to programs no longer
> being able to find their config files.
> 
> Firstly these are not supported environments, so it's not "rushed"
> for us to not preemptively consider them (though we'll happily merge
> most PRs that fix them without impacting supported environments).

Yeah, you're right, sorry, my comment wasn't appropriate.

> And I thought the idea was that they'd use posixpath as os.path
> rather than ntpath? Cygwin in particular, which provides the full
> environment. MinGW is a bit lighter to be closer to normal Windows
> behaviour, which would suggest that using the Windows variables is
> preferable.

I meant executing Python scripts with official Python in bash on Windows which sets HOME. But I just checked with "git for Windows" and it sets HOME to USERPROFILE anyway, so that might only affect cygwin/msys2 which have their own user dir.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:41:21 2019
From: report at bugs.python.org (Marc Culler)
Date: Thu, 21 Nov 2019 18:41:21 +0000
Subject: [issue38882] IDLE should not make the about dialog be a transient of
 the withdrawn root window
Message-ID: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>


New submission from Marc Culler <culler at math.uic.edu>:

The soon-to-be-released Tcl/Tk 8.6.10 includes some changes to the macOS
port which cause the wm transient command to behave in the way that the
Tk manual says it should:

  "A transient window will mirror state changes in the master and
   inherit the state of the master when initially mapped."

This means that a transient of a withdrawn window will be withdrawn.  In
the macOS version of IDLE the about dialog is assigned as a transient
of the root window which is withdrawn, so the dialog does not appear on
the screen.  Consequently, activating the about menu will cause IDLE
to become unresponsive as it waits for an offscreen window to be closed.

Deleting line 28 in aboutDialog.py:

        self.transient(parent)

makes the about dialog behave normally.

----------
assignee: terry.reedy
components: IDLE
messages: 357195
nosy: culler, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE should not make the about dialog be a transient of the withdrawn root window
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:45:12 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 21 Nov 2019 18:45:12 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
Message-ID: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

In issue36264 os.path.expanduser() was changed to no longer use the HOME environment variable on Windows.

There are two more ways in the stdlib to get the user directory, pathlib.Path.home() and pathlib.Path.expanduser() which internally use gethomedir() which still uses the HOME environment variable:

https://github.com/python/cpython/blob/0aca3a3a1e68b4ca2d334ab5255dfc267719096e/Lib/pathlib.py#L255

Since they are documented to work the same as os.path.expanduser() they should be changed to no longer use HOME as well.

----------
components: Library (Lib)
messages: 357196
nosy: lazka
priority: normal
severity: normal
status: open
title: Path.home() should ignore HOME env var like os.path.expanduser()
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:45:40 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 21 Nov 2019 18:45:40 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1574361940.84.0.700435687635.issue36264@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

I've filed issue38883

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:52:36 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 21 Nov 2019 18:52:36 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1574362356.12.0.167814675009.issue38883@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya, steve.dower
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:54:50 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 21 Nov 2019 18:54:50 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1574362490.61.0.833882818154.issue38883@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Thu Nov 21 13:54:56 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 21 Nov 2019 18:54:56 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1574362496.16.0.901002238779.issue38883@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:11:54 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 19:11:54 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
Message-ID: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>


New submission from Valentyn Tymofieiev <valentyn at google.com>:

Attached import_module_not_found.py consistently fails for me on Python 3.7.5 and earlier Python 3 versions that I have tried with 

  File "/usr/lib/python3.7/threading.py", line 926, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "import_module_not_found.py", line 8, in t2
    return __import__("tensorflow.estimator", level=0)
ModuleNotFoundError: No module named 'tensorflow.estimator

Threads in this example finish successfully if executed sequentially.

I have not tried higher versions of Python, but I cannot reproduce this on Python 2.7. 

Is this an expected behavior?

Thank you.

----------
files: import_module_not_found.py
messages: 357198
nosy: Valentyn Tymofieiev
priority: normal
severity: normal
status: open
title: __import__ is not thread-safe on Python 3
versions: Python 3.7
Added file: https://bugs.python.org/file48734/import_module_not_found.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:13:24 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 19:13:24 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574363604.21.0.603074797183.issue38884@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

Attached import_deadlock.py fails with   

...
File "<frozen importlib._bootstrap>", line 980, in _find_and_load
  File "<frozen importlib._bootstrap>", line 149, in __enter__
  File "<frozen importlib._bootstrap>", line 94, in acquire
_frozen_importlib._DeadlockError: deadlock detected by _ModuleLock('tensorflow_transform.tf_metadata.metadata_io')

under the same conditions.

----------
Added file: https://bugs.python.org/file48735/import_deadlock.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:24:33 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 19:24:33 +0000
Subject: [issue34572] C unpickling bypasses import thread safety
In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za>
Message-ID: <1574364273.58.0.56328529288.issue34572@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

While investigating[1], I observe that certain unpickling operations, for example, Unpickler.find_class, remain not thread-safe in Python 3.7.5 and earlier versions that I tried. I have not tried 3.8, but cannot reproduce this error on Python 2. 

For example, attached find_class_deadlock.py which consistently fails with a deadlock on Python 3.7.5.

I opened https://bugs.python.org/issue38884, which may be causing these errors, since the failure mode is similar, and in at least some codepaths, find_class seems to be calling __import__ [2].

[1] https://issues.apache.org/jira/browse/BEAM-8651
[2] https://github.com/python/cpython/blob/4ffc569b47bef9f95e443f3c56f7e7e32cb440c0/Lib/pickle.py#L1426.

----------
nosy: +Valentyn Tymofieiev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34572>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:24:51 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 19:24:51 +0000
Subject: [issue34572] C unpickling bypasses import thread safety
In-Reply-To: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za>
Message-ID: <1574364291.09.0.616950117591.issue34572@roundup.psfhosted.org>


Change by Valentyn Tymofieiev <valentyn at google.com>:


Added file: https://bugs.python.org/file48736/find_class_deadlock.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34572>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:30:35 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 19:30:35 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1574364635.08.0.535619810377.issue35943@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

Thanks. Is it possible that this issue and  https://bugs.python.org/issue38884 are duplicates?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:31:56 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 19:31:56 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574364716.4.0.904468138258.issue38884@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

Possibly related: https://bugs.python.org/issue35943

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:37:08 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 19:37:08 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574365028.92.0.0963072857732.issue38021@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I'm not in a good position to review distutils stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:41:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 21 Nov 2019 19:41:12 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574365272.69.0.779424727192.issue38881@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:43:03 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 21 Nov 2019 19:43:03 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574365382.98.0.0536609220015.issue37334@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

This seems like a useful idea. I recommend to write a test implementation and play with it.


Andrew:
> I think the proposal makes the queues API more error-prone: concurrent put() and close() produces unpredictable result on get() side.

How? Can you elaborate?


Caleb:
> I'm interested in how this change would affect the pattern of shutting down a queue-processing task.

Agree, this can be useful for that.


Martin:
> Given the reactions I gather "close" is a better name for the method, so I changed it accordingly.

Not sure I like "close" since it will *cancel* all getters and putters & discard all items in the queue AND allow further operation on the queue.  The latter part is really questionable -- what's the point of losing the data in the queue and resuming it?  Seems like a mechanism for writing unreliable code, but perhaps you can give us an example where this is necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:45:15 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 19:45:15 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574365515.58.0.814605826002.issue38878@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I can't reproduce in Python 3.8.0:

>>> import os
>>> class A(os.PathLike): pass
...
>>> class B:
...     def __fspath__(self): pass
...
>>> issubclass(B, A)
True

Did you check against an older version of Python?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:49:42 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 19:49:42 +0000
Subject: [issue38885] Have os.PathLike inherit from typing.Protocol
Message-ID: <1574365782.08.0.502784993713.issue38885@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

Since os.PathLike explicitly defines a a protocol, it would make sense to have it inherit from typing.Protocol instead of abc.ABC.

----------
components: Library (Lib)
messages: 357206
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Have os.PathLike inherit from typing.Protocol
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38885>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:50:07 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 19:50:07 +0000
Subject: [issue38885] Have os.PathLike inherit from typing.Protocol
In-Reply-To: <1574365782.08.0.502784993713.issue38885@roundup.psfhosted.org>
Message-ID: <1574365807.72.0.351012602173.issue38885@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Closing as importing 'typing' in 'os' is probably too much and would impact start-up time.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38885>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:55:38 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Thu, 21 Nov 2019 19:55:38 +0000
Subject: [issue38721] modulefinder should use import hooks properly
In-Reply-To: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>
Message-ID: <1574366138.77.0.580304996874.issue38721@roundup.psfhosted.org>


Change by Dominic Littlewood <11dlittlewood at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Thu Nov 21 14:57:18 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 19:57:18 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574366238.21.0.277727463019.issue38500@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@Mark

> PEP 523 makes no mention of adding a getter or setter.
> Adding them is a big change to Python semantics and shouldn't, IMO, be done without a PEP that explicit states they are going to be added.

Adding getters or setters for something that was previously doable that we accidentally took away from users is not an expansion of semantics; it's fixing a backwards-compatibility break in a way that lets us keep the goal of making PyInterpreterState opaque.

I'm considering this issue at a stalemate and so I'm going to loop in python-dev to help settle this. If that still locks up then we can bring this to the steering council.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:00:51 2019
From: report at bugs.python.org (Bar Harel)
Date: Thu, 21 Nov 2019 20:00:51 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574365515.58.0.814605826002.issue38878@roundup.psfhosted.org>
Message-ID: <CAMsGuy=ONZagW_WWxkG1=8eWYbAB+GXTyiTUyFDWBiwnTakKEw@mail.gmail.com>


Bar Harel <bzvi7919 at gmail.com> added the comment:

Hey Brett, that's exactly the bug. It's supposed to be False ofc.

On Thu, Nov 21, 2019, 9:45 PM Brett Cannon <report at bugs.python.org> wrote:

>
> Brett Cannon <brett at python.org> added the comment:
>
> I can't reproduce in Python 3.8.0:
>
> >>> import os
> >>> class A(os.PathLike): pass
> ...
> >>> class B:
> ...     def __fspath__(self): pass
> ...
> >>> issubclass(B, A)
> True
>
> Did you check against an older version of Python?
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38878>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:01:41 2019
From: report at bugs.python.org (Raphael Dussin)
Date: Thu, 21 Nov 2019 20:01:41 +0000
Subject: [issue38886] permissions too restrictive in zipfile.writestr
Message-ID: <1574366501.85.0.0231007396061.issue38886@roundup.psfhosted.org>


New submission from Raphael Dussin <raphael.dussin at gmail.com>:

zipfile.writestr write with permissions 600 by default and there is no way to override permissions. This can be an issue when writing zip archive of data one want to share (e.g. zarr zipstore, see https://github.com/zarr-developers/zarr-python/pull/517)


Proposed fix in upcoming PR is to add the desired permission as an optional arg.

----------
components: Library (Lib)
messages: 357210
nosy: rdussin
priority: normal
severity: normal
status: open
title: permissions too restrictive in zipfile.writestr
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38886>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:02:32 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 21 Nov 2019 20:02:32 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574366552.24.0.218367366938.issue37334@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

1. Suppose we have 2 concurrent producers, a single queue and a consumer.
2. The first producer puts several items into the queue and then calls q.close()
3. The second producer also puts several items. It doesn't matter the second producer closes the queue at the end or not.
4. The consumer gets items from the queue and prints them.

What items are printed and what are canceled/skipped? With the proposed PR it depends on timings of putting and getting data items and the queue size. 
The output can vary from zero to all pushed data.
That's why I think that the idea is not reliable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:05:29 2019
From: report at bugs.python.org (Raphael Dussin)
Date: Thu, 21 Nov 2019 20:05:29 +0000
Subject: [issue38886] permissions too restrictive in zipfile.writestr
In-Reply-To: <1574366501.85.0.0231007396061.issue38886@roundup.psfhosted.org>
Message-ID: <1574366729.28.0.716078466274.issue38886@roundup.psfhosted.org>


Change by Raphael Dussin <raphael.dussin at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38886>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:07:00 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 20:07:00 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574366820.74.0.0605739087785.issue38500@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Posted https://mail.python.org/archives/list/python-dev at python.org/thread/4UZJYAZL3NHRAGN5WAMJC4IHAHEXF3QF/ to see if anyone else wants to weigh in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:11:53 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 20:11:53 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574367113.8.0.702253313793.issue38884@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:16:36 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 20:16:36 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574367396.44.0.939686678294.issue38878@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Ah, your `assert` call threw me since it does succeed so it isn't acting as a test case.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:20:18 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 20:20:18 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574367618.76.0.29858409711.issue38884@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Can you test this with a package that isn't tensorflow (e.g. something else in the stdlib or something created manually; basically a smaller reproducer)? It's hard to diagnose if this is really Python or not without a smaller reproducer as tensorflow might be doing some things behind the scenes that would break this due to it being an extension module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:42:01 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 21 Nov 2019 20:42:01 +0000
Subject: [issue38721] modulefinder should use import hooks properly
In-Reply-To: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>
Message-ID: <1574368921.75.0.941543346357.issue38721@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I'm not sure what you mean when you say "modulefinder currently will detect modules imported by a script dynamically by running the script"... modulefinder is completely static, no?

I also think that changing sys.path like this is a bad idea (I tried this in an earlier PR and was told to remove it and rework my solution). We lose thread-safety, and it has effects far outside of the scope of modulefinder (i.e. the hooks we call could cache it or something, and break later imports). If changing sys.path is the only way to accomplish this (still not exactly sure what), I doubt it will be accepted. It seems like this PR does a lot of unnecessary refactoring too, on first glance.

With that said, adding support for hooks should be fairly straightforward by just manually walking down sys.path/meta_path/path_hooks in _find_module... maybe.

----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Thu Nov 21 15:44:15 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 21 Nov 2019 20:44:15 +0000
Subject: [issue38721] modulefinder should use import hooks properly
In-Reply-To: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>
Message-ID: <1574369055.05.0.0296428326641.issue38721@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

See prior discussion on this here:

https://github.com/python/cpython/pull/11787#discussion_r256442282

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:00:42 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 21:00:42 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574370042.92.0.695731438456.issue38870@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:00:37 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 21:00:37 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1574370037.12.0.830917013786.issue38883@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:17:31 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 21 Nov 2019 21:17:31 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574371051.22.0.681641597824.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> some platforms apparently do have SO_REUSEPORT defined but the option still doesn't work, resulting in a ValueError exception from create_datagram_endpoint().

Are you aware of what currently supported platforms have SO_REUSEPORT defined where the *reuse_port* parameter doesn't actually work? This would be quite helpful to know. 

AFAIK, it's available and supported on the majority of Unix platforms (such as Linux 3.9+, MacOS and BSD). On Windows, SO_REUSEPORT is undefined.

Also, at the very least, the ValueError exception would occur is highly informative and specific:

raise ValueError('reuse_port not supported by socket module, '
                             'SO_REUSEPORT defined but not implemented.')

> I just have a #ifdef block for every OS and don't even try to abstract it.

The main issue with this approach for our purposes is that we don't directly support every single available platform, as making the code specific to an OS incurs a long-term maintenance cost. See https://www.python.org/dev/peps/pep-0011/ for more details. Indirect patches are fine, but we only add platform-specific code if it is officially supported: 

"Patches which add platform-specific code such as the name of a specific platform to the configure script will generally not be accepted without the platform having official support."

IIUC, this applies to any code that explicitly defines the name of a specific platform. Official support not only involves us having someone with commit privileges that will provide it, but also a buildbot in place (or provided) and having the OS *version* supported upstream. For example, I think Linux kernel versions prior to 3.9 would fall under the category of "unsupported", since they are not supported upstream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:23:19 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 21 Nov 2019 21:23:19 +0000
Subject: [issue38526] zipfile.Path has the wrong method name
In-Reply-To: <1571485638.73.0.512747413003.issue38526@roundup.psfhosted.org>
Message-ID: <1574371399.95.0.31109144291.issue38526@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 65444cf7fe84d8ca1f9b51c7f5992210751e08bb by Jason R. Coombs (Claudiu Popa) in branch 'master':
bpo-38526: Fix zipfile.Path method name to be the correct one (#17317)
https://github.com/python/cpython/commit/65444cf7fe84d8ca1f9b51c7f5992210751e08bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38526>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:28:22 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Thu, 21 Nov 2019 21:28:22 +0000
Subject: [issue38721] modulefinder should use import hooks properly
In-Reply-To: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>
Message-ID: <1574371702.16.0.455762675253.issue38721@roundup.psfhosted.org>


Dominic Littlewood <11dlittlewood at gmail.com> added the comment:

You are correct about modulefinder being static. I read "run_script" and thought it was running a script, but it turns out I was being silly.

I shall correct the sys.path issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:33:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 21:33:07 +0000
Subject: [issue38887] test_asyncio: test_pipe_handle() failed on AMD64
 Windows7 SP1 3.x
Message-ID: <1574371987.32.0.39878951325.issue38887@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

https://buildbot.python.org/all/#/builders/40/builds/3465

ERROR: test_pipe_handle (test.test_asyncio.test_windows_utils.PipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_windows_utils.py", line 78, in test_pipe_handle
    raise RuntimeError('expected ERROR_INVALID_HANDLE')
RuntimeError: expected ERROR_INVALID_HANDLE

----------
components: Tests
messages: 357220
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_pipe_handle() failed on AMD64 Windows7 SP1 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38887>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:34:38 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 21:34:38 +0000
Subject: [issue38526] zipfile.Path has the wrong method name
In-Reply-To: <1571485638.73.0.512747413003.issue38526@roundup.psfhosted.org>
Message-ID: <1574372078.03.0.402669233446.issue38526@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16816
pull_request: https://github.com/python/cpython/pull/17329

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38526>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:41:26 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Nov 2019 21:41:26 +0000
Subject: [issue38526] zipfile.Path has the wrong method name
In-Reply-To: <1571485638.73.0.512747413003.issue38526@roundup.psfhosted.org>
Message-ID: <1574372486.25.0.359136147818.issue38526@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 107ed88cde3ae6f1cb01ae75575ea0f92c138464 by Miss Islington (bot) in branch '3.8':
bpo-38526: Fix zipfile.Path method name to be the correct one (GH-17317)
https://github.com/python/cpython/commit/107ed88cde3ae6f1cb01ae75575ea0f92c138464


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38526>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:43:43 2019
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Thu, 21 Nov 2019 21:43:43 +0000
Subject: [issue38888] Popen should use pidfd_create to implement a non-busy
 wait
Message-ID: <1574372623.22.0.938109009233.issue38888@roundup.psfhosted.org>


New submission from ????? ???????? <dpb at corrigendum.ru>:

Popen.wait(timeout) is currently implemented on Unix-like systems using a busy wait, since the waitpid system call doesn't have a timeout argument.

On Linux, it's now possible to do better than that. You can create a PID file descriptor using pidfd_create and poll that descriptor with the specified timeout. Popen.wait should make use of that.

----------
components: Library (Lib)
messages: 357222
nosy: SpecLad
priority: normal
severity: normal
status: open
title: Popen should use pidfd_create to implement a non-busy wait
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38888>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:46:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 21:46:25 +0000
Subject: [issue38888] Popen should use pidfd_create to implement a non-busy
 wait
In-Reply-To: <1574372623.22.0.938109009233.issue38888@roundup.psfhosted.org>
Message-ID: <1574372785.23.0.503149746058.issue38888@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

os.pidfd_open() was added to Python 3.9. Do you mean pidfd_open()?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38888>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:46:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 21:46:39 +0000
Subject: [issue38888] Popen should use pidfd_create to implement a non-busy
 wait
In-Reply-To: <1574372623.22.0.938109009233.issue38888@roundup.psfhosted.org>
Message-ID: <1574372799.31.0.00071077886696.issue38888@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +benjamin.peterson, gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38888>
_______________________________________

From report at bugs.python.org  Thu Nov 21 16:47:26 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 21 Nov 2019 21:47:26 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1574372846.14.0.48285940225.issue16576@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 91c15a542cb780377dcde8fc17ba93111bc1d1cf by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-16576: Add checks for bitfields passed by value to functions. (GH-17097) (GH-17224)
https://github.com/python/cpython/commit/91c15a542cb780377dcde8fc17ba93111bc1d1cf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:20:50 2019
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Thu, 21 Nov 2019 22:20:50 +0000
Subject: [issue38888] Popen should use pidfd_open to implement a non-busy wait
In-Reply-To: <1574372623.22.0.938109009233.issue38888@roundup.psfhosted.org>
Message-ID: <1574374850.83.0.953139262446.issue38888@roundup.psfhosted.org>


????? ???????? <dpb at corrigendum.ru> added the comment:

Right, of course. I keep confusing it with timerfd_create.

----------
title: Popen should use pidfd_create to implement a non-busy wait -> Popen should use pidfd_open to implement a non-busy wait

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38888>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:23:42 2019
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Thu, 21 Nov 2019 22:23:42 +0000
Subject: [issue38765] `ast.AST._attributes` is used by `ast.dump()` but not
 documented
In-Reply-To: <1573482663.72.0.733055997415.issue38765@roundup.psfhosted.org>
Message-ID: <1574375022.08.0.889750371912.issue38765@roundup.psfhosted.org>


Pekka Kl?rck <pekka.klarck at gmail.com> added the comment:

I'd say `_attributes` is already exposed as defining it in your own node affects many of the functions in the ast module. For example, `ast.dump(node, include_attributes=True)` makes no sense otherwise.

Whatever was the reason for the leading underscore must be the same reason that added the underscore to `_fields`. That attribute is already documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38765>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:30:19 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 22:30:19 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574375419.11.0.244568790212.issue38884@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

Attaching a minimal repro with simple project hierarchy.

----------
nosy:  -brett.cannon, eric.snow, ncoghlan
Added file: https://bugs.python.org/file48737/issue38884.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:31:34 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 22:31:34 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574375494.81.0.801831977044.issue38884@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

Repro: unpack issue38884.zip
python input_deadlock.py

(fails on Python 3.7, but not on 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:32:55 2019
From: report at bugs.python.org (Sebastian Szwarc)
Date: Thu, 21 Nov 2019 22:32:55 +0000
Subject: [issue38889] Segmentation fault when using EPF Importer
Message-ID: <1574375575.02.0.850008732882.issue38889@roundup.psfhosted.org>


New submission from Sebastian Szwarc <seba.szwarc at gmail.com>:

Python 2.7 on Ubuntu 18.04 LTS is not in latest version.

Both version 2.7.14 and 15 RC1 bringing segmentation fault error.
Code is the same and previously there was no error.
COde is EPFImporter.py tool written by Apple to handle importing of their database dumps.

----------
components: Interpreter Core
messages: 357229
nosy: Sebastian Szwarc
priority: normal
severity: normal
status: open
title: Segmentation fault when using EPF Importer
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38889>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:33:02 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 22:33:02 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574375582.06.0.938310260904.issue38884@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

input_deadlock.py in issue38884.zip has a left-over comment:
# Requires pip install tensorflow==2.0.0 tensorflow-transform==0.15.0 
Please ignore that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:33:24 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 21 Nov 2019 22:33:24 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1574375604.33.0.626016553896.issue16576@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:35:11 2019
From: report at bugs.python.org (Sebastian Szwarc)
Date: Thu, 21 Nov 2019 22:35:11 +0000
Subject: [issue38889] Segmentation fault when using EPF Importer
In-Reply-To: <1574375575.02.0.850008732882.issue38889@roundup.psfhosted.org>
Message-ID: <1574375711.98.0.268501721437.issue38889@roundup.psfhosted.org>


Sebastian Szwarc <seba.szwarc at gmail.com> added the comment:

PYTHONFAULTHANDLER=1 python EPFImporter_debug.py incremental/*
2019-11-21 23:34:09,787 [INFO]: Beginning import for the following directories:
    incremental/itunes20191120
    incremental/pricing20191120
2019-11-21 23:34:09,787 [INFO]: Importing files in incremental/itunes20191120
2019-11-21 23:34:09,788 [INFO]: Starting import of /home/sebastian/appromocje/incremental/itunes20191120...
2019-11-21 23:34:09,813 [INFO]: Beginning incremental ingest of epf_artist_video (31664 records)
Fatal Python error: Segmentation fault

Current thread 0x00007f51058df740 <python> (most recent call first):
  File "/home/sebastian/appromocje/EPFIngester.py", line 206 in ingestIncremental
  File "/home/sebastian/appromocje/EPFIngester.py", line 111 in ingest
  File "EPFImporter_debug.py", line 222 in doImport
  File "EPFImporter_debug.py", line 437 in main
  File "EPFImporter_debug.py", line 454 in <module>
Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38889>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:38:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 22:38:25 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574375905.91.0.311129826406.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16817
pull_request: https://github.com/python/cpython/pull/17330

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:45:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 22:45:46 +0000
Subject: [issue38889] Segmentation fault when using EPF Importer
In-Reply-To: <1574375575.02.0.850008732882.issue38889@roundup.psfhosted.org>
Message-ID: <1574376346.32.0.779449540252.issue38889@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It looks like a bug in EPF Importer: in ingestIncremental(), line 206 of EPFIngester.py.

I don't think that it's a bug in Python. I suggest to clos ethe issue.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38889>
_______________________________________

From report at bugs.python.org  Thu Nov 21 17:49:58 2019
From: report at bugs.python.org (Sebastian Szwarc)
Date: Thu, 21 Nov 2019 22:49:58 +0000
Subject: [issue38889] Segmentation fault when using EPF Importer
In-Reply-To: <1574376346.32.0.779449540252.issue38889@roundup.psfhosted.org>
Message-ID: <CAM4yeEZX1ncNo6k_Mvdi3-MYwy-z+pm9XJqhZdw4uXcFFsf3YQ@mail.gmail.com>


Sebastian Szwarc <seba.szwarc at gmail.com> added the comment:

Previous python version didnt do segmentation fault.
Code is the same as before and it worked fine previously ergo code is
correct and this is python interpreter issue

On Thu, Nov 21, 2019 at 11:45 PM STINNER Victor <report at bugs.python.org> wrote:
>
>
> STINNER Victor <vstinner at python.org> added the comment:
>
> It looks like a bug in EPF Importer: in ingestIncremental(), line 206 of EPFIngester.py.
>
> I don't think that it's a bug in Python. I suggest to clos ethe issue.
>
> ----------
> nosy: +vstinner
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38889>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38889>
_______________________________________

From report at bugs.python.org  Thu Nov 21 18:01:41 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 23:01:41 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574377301.59.0.468029130488.issue38884@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

The behavior changes between Python 3.2 (no deadlock) and Python 3.3 (deadlock). Deadlock also reproducible on Python 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 18:13:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 23:13:49 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574378029.04.0.346730295916.issue36854@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16818
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17331

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Thu Nov 21 18:17:06 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Thu, 21 Nov 2019 23:17:06 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1574378226.94.0.768261503738.issue36225@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Am abit swamped and sick atm. You can go on and submit a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Thu Nov 21 18:21:15 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Nov 2019 23:21:15 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574378475.77.0.0389092120583.issue38021@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Brett, sorry I wasn't more explicit about my concerns here. I added you and Nick to this issue and to its PR not primarily to do do code review but because I think it brings up issues that I believe haven't been dealt with before in our evolving environment and may need guidance from the Steering Council and the PyPA, both of which you two have been involved in. The PR is about defining new platform tags, something which has potential impact across both CPython development (it can affect how Python itself is built) and across the packaging realm (as any packaging tool like, presumably, pip and wheel and others are potentially affected).  This also is relevant to recent discussions about the roles of PyPA and CPython development.  Because it has the portential to impact and require changes across the board, we need to make sure that proposed changes like this get adequate review and consensus across the board.  I'm not exactly sure how that should work so I think it's something that is worth clarifying.  AIX is already a supported platform, at least on best effort basis thanks in large part to the efforts of non-core developers like Michael here (and thank you, Michael). So, in this case, the impact is probably most on the PyPA side so I think there needs to be their explicit involvement.  But, for example, there is a risk of a similar PR adding new platform support without adequate review which could have a major long-term impact on CPython maintenance and support (and such things have happened in the past).  Perhaps we need to formulate an explicit policy about approval of changes to cpython that affect platform support and thus packaging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Thu Nov 21 19:04:10 2019
From: report at bugs.python.org (Shane Harvey)
Date: Fri, 22 Nov 2019 00:04:10 +0000
Subject: [issue38890] A subprocess.Popen created with
 creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
Message-ID: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>


New submission from Shane Harvey <shnhrv at gmail.com>:

In https://bugs.python.org/issue26741 Popen was changed to emit a ResourceWarning in __del__ if the process is still running. However, when running a daemon/detached process it is completely valid to delete a Popen object before the process is complete.

On Windows, a daemon process can be created by using the DETACHED_PROCESS option, eg:
import subprocess

DETACHED_PROCESS = getattr(subprocess, 'DETACHED_PROCESS', 0x00000008)
popen = subprocess.Popen(args, creationflags=DETACHED_PROCESS)
print('Running daemon process: ', popen.pid)
del popen

Unfortunately, the above will emit the warning:
C:\python\Python37\lib\subprocess.py:839: ResourceWarning: subprocess 840 is still running
  ResourceWarning, source=self)
Running daemon process:  3212

This makes it complicated to run a daemon process without emitting the resource warning. The best solution I've got is to manually set the Popen.returncode to circumvent the warning, ie:

popen = subprocess.Popen(args, creationflags=DETACHED_PROCESS)
print('Running daemon process: ', popen.pid)
# Set the returncode to avoid erroneous warning:
# "ResourceWarning: subprocess XXX is still running".
popen.returncode = 0
del popen


Running the attached script on Windows only one warning is emitted:
$ python.exe -Wall test_daemon_win.py
C:\python\Python37\lib\subprocess.py:839: ResourceWarning: subprocess 3584 is still running
  ResourceWarning, source=self)
Running daemon process:  3584
Running daemon process:  1012

I propose that Popen should not raise the resource warning when the creationFlags includes DETACHED_PROCESS.

----------
components: Library (Lib)
files: test_daemon_win.py
messages: 357237
nosy: ShaneHarvey
priority: normal
severity: normal
status: open
title: A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48738/test_daemon_win.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38890>
_______________________________________

From report at bugs.python.org  Thu Nov 21 19:22:47 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 22 Nov 2019 00:22:47 +0000
Subject: [issue38889] Segmentation fault when using EPF Importer
In-Reply-To: <1574375575.02.0.850008732882.issue38889@roundup.psfhosted.org>
Message-ID: <1574382167.79.0.251461203791.issue38889@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree this doesn't look like a python bug.

However, if the original poster can reproduce it with a short example with no third party code, we could take another look. If so, please re-open this issue.

And just because the code worked on a different version of python doesn't mean there's no bug in the code. I've written plenty of code where errors were exposed in my code when updating python.

----------
nosy: +eric.smith
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38889>
_______________________________________

From report at bugs.python.org  Thu Nov 21 19:35:34 2019
From: report at bugs.python.org (SAKCHAI SUKWISET)
Date: Fri, 22 Nov 2019 00:35:34 +0000
Subject: [issue24995] better exception message when an unsupported object is
 passed to `async for` (pep 492)
In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za>
Message-ID: <1574382934.86.0.364970942707.issue24995@roundup.psfhosted.org>


Change by SAKCHAI SUKWISET <colorpunk168 at gmail.com>:


----------
components: +2to3 (2.x to 3.x conversion tool)
type: enhancement -> resource usage
versions: +Python 2.7, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48739/TransactionHistory-79b28f7d5748ad20cb8afb107f00330adbcd6d81.csv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24995>
_______________________________________

From report at bugs.python.org  Thu Nov 21 21:31:14 2019
From: report at bugs.python.org (Jake Northey)
Date: Fri, 22 Nov 2019 02:31:14 +0000
Subject: [issue38891] ShareableList read and write access is O(N),
 should be O(1)
Message-ID: <1574389874.92.0.425732905902.issue38891@roundup.psfhosted.org>


New submission from Jake Northey <janorthey at connamara.com>:

For an illustration of the performance implications of the __getitem__ and __setitem__ implementation, see the article below.
https://medium.com/@rvprasad/performance-of-system-v-style-shared-memory-support-in-python-3-8-d7a7d1b1fb96

The issue appears to be due to the summing of ShareableList item sizes to generate an offset for the requested item.  Perhaps an offset-based index could be created in which the allocation sizes could be constructed by comparing two offets.

----------
components: Library (Lib)
messages: 357239
nosy: Jake Northey, davin
priority: normal
severity: normal
status: open
title: ShareableList read and write access is O(N), should be O(1)
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38891>
_______________________________________

From report at bugs.python.org  Thu Nov 21 21:32:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Nov 2019 02:32:59 +0000
Subject: [issue38892] Audit Hook doc typos and confusion
Message-ID: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Some suggestions for
https://docs.python.org/3.9/c-api/sys.html#c.PySys_AddAuditHook
https://docs.python.org/3.9/library/sys.html#sys.addaudithook

"Adds to the collection of active auditing hooks"
"Adds the callable hook to the collection of active auditing hooks"

Change 'Adds' to 'Add' or maybe 'Append' (see near below).
Insert 'the callable hook' in PySys version.
Change 'collection' to 'sequence' or 'list' (and change verb to 'append') since order is important.

PySys version:

I think the 'userData' explanation should be closer to the top.  

Grammar: "Functions in the runtime and standard library that raise events include the details in each function?s documentation and listed in the audit events table." is not a proper sentence.  Its 'skeleton' is "Functions ... include the details ... and listed ... .  

Either change 'include the details' to 'are detailed' and 'listed' to 'are listed' or split into two sentences:

"Functions in the runtime and standard library that raise events are  listed in the audit events table.  Details are in each function?s documentation.

Both, again:

"raises a auditing event".  'a' should be  'an'.  To me, this is slightly confusing because Python raises exceptions, but auditing events are not exceptions and do not normally abort execution.  Perhaps "This call is a 'sys.addaudithook' event with no arguments that triggers an audit call."


https://docs.python.org/3.9/c-api/sys.html#c.PySys_Audit
https://docs.python.org/3.9/library/sys.html#sys.audit

Change 'Raises' to 'Raise'.


https://docs.python.org/3.8/library/audit_events.html

On pydev, Steve said "(though some won't be raised until 3.8.1... we should probably mark those, or at least update that page to warn that events may have been added over time)."

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 357240
nosy: christian.heimes, docs at python, steve.dower, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Audit Hook doc typos and confusion
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38892>
_______________________________________

From report at bugs.python.org  Thu Nov 21 21:45:26 2019
From: report at bugs.python.org (Bernie Hackett)
Date: Fri, 22 Nov 2019 02:45:26 +0000
Subject: [issue38890] A subprocess.Popen created with
 creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
In-Reply-To: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>
Message-ID: <1574390726.75.0.723865313755.issue38890@roundup.psfhosted.org>


Change by Bernie Hackett <bernie.hackett at gmail.com>:


----------
nosy: +behackett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38890>
_______________________________________

From report at bugs.python.org  Thu Nov 21 22:08:51 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Fri, 22 Nov 2019 03:08:51 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574392131.39.0.280666584827.issue38884@roundup.psfhosted.org>


Change by Valentyn Tymofieiev <valentyn at google.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Thu Nov 21 23:22:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Nov 2019 04:22:21 +0000
Subject: [issue38882] IDLE should not make the about dialog be a transient of
 the withdrawn root window
In-Reply-To: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>
Message-ID: <1574396541.75.0.968163143642.issue38882@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The NMT doc adds "A transient window always appears in front of its parent." and I believe that this is why we use it and why I would not want to unconditionally delete the calls without thorough testing on both Linux and Windows.

IDLE calls this function for configdialog, its config-key subdialog, all query, search, and textview windows, help-about, and the IDLE-help doc window.  I believe in all cases the parent is normally an editor-base window.  There are also the tk/inter color and save dialogs.  The same may be true for them, but ultimately all should be tested both with menu clicks and hot keys.

Configdialog and about-IDLE are special in that their menu entries are transferred to the 'IDLE' submenu that macOS adds to the app menu.  So macosx.py has event handlers that make root the parent.  Both of these popup, on my Macbook, to the right of the centerline.  From what you say, at least these two should have conditional transient calls.

For reasons I don't understand (obsolete history?), there is also a mac-specific root-parent event handler for IDLE-help, even though that is left on the Help submenu, and popup up on top the the current window.

I can only test on my Macbook with installed Python (3.7.5, 3.8.0) and tk 8.6.9.  Are all tk versions earlier than 8.6.10 the same?

----------
components: +macOS
nosy: +ned.deily, ronaldoussoren, taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Thu Nov 21 23:25:29 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Nov 2019 04:25:29 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574396729.38.0.384881766408.issue38881@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> When zero weights are given, the last element of a sequence 
> is always chosen.

Given non-sensical input, that behavior is as reasonable as any other (fwiw, the same is also observed with all negative weights, even if the negative weights are unequal).

The documentation currently says, "weights are assumed to be non-negative."  Perhaps it should say, "weights are assumed to be non-negative and have at least one positive weight."

----------
assignee:  -> rhettinger
components: +Documentation -Library (Lib)
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Thu Nov 21 23:25:49 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Nov 2019 04:25:49 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574396749.25.0.133419778156.issue38881@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Thu Nov 21 23:37:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Nov 2019 04:37:23 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574397443.46.0.567210046499.issue38881@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Alternatively, we could raise an exception if the weight total isn't positive.  Am not sure that has any real worth, but it could be done with only a small additional cost to the critical path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Thu Nov 21 23:50:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 22 Nov 2019 04:50:14 +0000
Subject: [issue38526] zipfile.Path has the wrong method name
In-Reply-To: <1571485638.73.0.512747413003.issue38526@roundup.psfhosted.org>
Message-ID: <1574398214.82.0.392793991117.issue38526@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing as fixed since PRs are merged. Thanks Alex for the report and @Claudiu.Popa for the patch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38526>
_______________________________________

From report at bugs.python.org  Thu Nov 21 23:53:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 22 Nov 2019 04:53:03 +0000
Subject: [issue24995] better exception message when an unsupported object is
 passed to `async for` (pep 492)
In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za>
Message-ID: <1574398383.34.0.190250663209.issue24995@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components:  -2to3 (2.x to 3.x conversion tool)
type: resource usage -> enhancement
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24995>
_______________________________________

From report at bugs.python.org  Thu Nov 21 23:52:02 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 22 Nov 2019 04:52:02 +0000
Subject: [issue24995] better exception message when an unsupported object is
 passed to `async for` (pep 492)
In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za>
Message-ID: <1574398322.43.0.929655350145.issue24995@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


Removed file: https://bugs.python.org/file48739/TransactionHistory-79b28f7d5748ad20cb8afb107f00330adbcd6d81.csv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24995>
_______________________________________

From report at bugs.python.org  Fri Nov 22 00:53:23 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 22 Nov 2019 05:53:23 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574402003.79.0.51333229398.issue38500@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 01:29:28 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 22 Nov 2019 06:29:28 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574404168.7.0.465582271436.issue38500@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

+1 to re-exposing a way to do PEP-523.

PEP-523 added a public API, we unintentionally hid it behind the mask of Py_BUILD_CORE_MODULE in 3.8.  We shouldn't remove PEP-523's abilities without a deprecation cycle.  But given the use cases tend to be "deep" knowledge places that can adapt to API change and version checks, I think re-exposing it without the need for Py_BUILD_CORE_MODULE is reasonable.

Are you proposing this for 3.8.1?

Or is 3.8 burned for this 3.6 & 3.7 feature :sadface: (but we know how to work around it - so if our RM says it is, we'll deal) and re-exposing in some manner it only happens in 3.9?

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 01:35:20 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 22 Nov 2019 06:35:20 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1574404520.02.0.0558825800454.issue33387@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

sweet! =)

----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Fri Nov 22 01:43:48 2019
From: report at bugs.python.org (Junyeong Jeong)
Date: Fri, 22 Nov 2019 06:43:48 +0000
Subject: [issue38874] asyncio.Queue: putting items out of order when it is full
In-Reply-To: <1574306754.82.0.07273997342.issue38874@roundup.psfhosted.org>
Message-ID: <1574405028.72.0.244646997372.issue38874@roundup.psfhosted.org>


Junyeong Jeong <rhdxmr at gmail.com> added the comment:

Thanks for having an interest in this issue.

I thought asyncio.Queue guarantees the order of items as .put called after I
read the code. But it does not.

I attach poc code here.
In my machine, this program prints this message and exits.
$ python poc-oooput.py
num=1, last_read_num=0
num=33, last_read_num=1
Traceback (most recent call last):
  File "poc-oooput.py", line 47, in <module>
    asyncio.run(main())
  File "/home/esrse/.pyenv/versions/3.7.3/lib/python3.7/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "/home/esrse/.pyenv/versions/3.7.3/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
    return future.result()
  File "poc-oooput.py", line 44, in main
    await stream.read()
  File "poc-oooput.py", line 20, in read
    assert num == self._last_read_num + 1
AssertionError

This shows you that the 33rd item is put before the 2nd item.

----------
Added file: https://bugs.python.org/file48740/poc-oooput.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38874>
_______________________________________

From report at bugs.python.org  Fri Nov 22 02:19:30 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 22 Nov 2019 07:19:30 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574407170.83.0.372653418103.issue38863@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +Rhodri James, ethan.furman -corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Fri Nov 22 02:37:25 2019
From: report at bugs.python.org (Leif Middelschulte)
Date: Fri, 22 Nov 2019 07:37:25 +0000
Subject: [issue38893] broken container/selinux integration
Message-ID: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>


New submission from Leif Middelschulte <leif.middelschulte at gmail.com>:

It seems Python does not necessarily determine that it is running inside a container correctly.

This leads to broken/unexpected behavior when trying to copy files across filesytems using `copy2`.
This directly affects Python3 inside the official `fedora:latest` image.

Steps to reproduce the issue can be found here:
https://github.com/containers/container-selinux/issues/81

https://bugs.python.org/issue26328 *might* be related too.

----------
components: IO
messages: 357248
nosy: Leif Middelschulte
priority: normal
severity: normal
status: open
title: broken container/selinux integration
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Fri Nov 22 02:47:18 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Nov 2019 07:47:18 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574408838.46.0.489695537661.issue38881@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Fri Nov 22 02:50:54 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 22 Nov 2019 07:50:54 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574409054.93.0.237581487054.issue38021@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

a) - thanks Ned, for the kind words.

b) - the proposed (change to the tag) is "AIX.VRTL.YYWW.SZ".
"AIX" - in caps, to distinguish from current tag starting as "aix"
VRTL - 4 digit number, one digit for Version, one digit as Revision, and two digits for Technology Level
YYWW - builddata with two digits for year (7 becomes 07) and two digits for week of year.
SZ - 32, or 64 bit size of executable (or pointer).

The builddate is crucial as system updates are possible, in oslevel -s terms, from 6100-09-11-1810 to 7100-05-02-1810 but not from 6100-09-12-1846 to 7100-05-02-1810. Using the proposed PEP425 tag the VRTL-YYWW numbers here would be: 6109-1810, 6109-1846 and 7105-1810.

The build-date of the executable is essential, as it specifies the lowest date of any AIX release that it is supported on. This is something CPython must provide, as it does for other platforms, in the form of sysconfig.get_config_var("AIX_BUILDDATE"). The VRTL values of the executable are already available via sysconfig.get_config_var("BUILD_GNU_TYPE") while SZ is typically determined from sys.maxsize.

Happy to answer additional questions - and write additional .rst documentation as desired.

e.g., an

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Fri Nov 22 02:53:55 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Nov 2019 07:53:55 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1574409235.2.0.675993242198.issue38893@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

>From the Github bug:

copy2() fails while copying extended attributes.

# python3
Python 3.7.4 (default, Aug 12 2019, 14:45:07) 
[GCC 9.1.1 20190605 (Red Hat 9.1.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2('/tmp/some_file', '/relabel_bug/failure')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.7/shutil.py", line 267, in copy2
    copystat(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib64/python3.7/shutil.py", line 209, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/lib64/python3.7/shutil.py", line 165, in _copyxattr
    os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
PermissionError: [Errno 13] Permission denied: '/relabel_bug/failure'

The setxattr() fail is blocked SELinux:
type=AVC msg=audit(1573815617.682:1332): avc:  denied  { relabelto } for  pid=3157530 comm="python3" name="failure" dev="loop1" ino=12 scontext=system_u:system_r:container_t:s0:c552,c859 tcontext=system_u:object_r:fusefs_t:s0 tclass=file permissive=0


Could you please provide name and value of the setxattr() call? I bet it's trying to setxattr 'security.selinux' extended file attribute.

----------
nosy: +christian.heimes
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Fri Nov 22 03:00:57 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 22 Nov 2019 08:00:57 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574409657.14.0.91576869081.issue22367@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thanks for the update to the PR

FYI One AIX bot seems to be having support issues atm (and stays red), but the other one turned green again. :smile:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 22 03:05:46 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 22 Nov 2019 08:05:46 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574409946.48.0.553121625815.issue22367@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

p.s. the new PR also needs to be backported for the 3.8 bots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 22 03:06:02 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Fri, 22 Nov 2019 08:06:02 +0000
Subject: [issue38877] Python 3.9 build fails under Debian 9.11
In-Reply-To: <1574342929.28.0.219657775235.issue38877@roundup.psfhosted.org>
Message-ID: <1574409962.05.0.542728247734.issue38877@roundup.psfhosted.org>


Florian Dahlitz <f2dahlitz at freenet.de> added the comment:

My commands were as follows:

$ ./configure
$ make &> output_without.txt
$ ./configure --enable-optimizations
$ make &> output.txt

Doing a make clean before each make resolved the issue. Thanks Ned!
I searched through the README.md on GitHub and found a note about make clean. However, the Developer's Guide at python.org doesn't mention it in the Quick References. Should it be added?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38877>
_______________________________________

From report at bugs.python.org  Fri Nov 22 03:11:43 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 22 Nov 2019 08:11:43 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574410303.27.0.24622059086.issue22367@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> p.s. the new PR also needs to be backported for the 3.8 bots.

PR 17252 and PR 17253 are backporting patches.
And they are ready to be merged :)

Thank you for the following up on this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:13:10 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 09:13:10 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574413990.82.0.230925964387.issue38863@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 91daa9d7224626dad4bb820924c01b3438ca6e3f by Miss Islington (bot) (Siwon Kang) in branch 'master':
bpo-38863: Improve is_cgi() in http.server (GH-17312)
https://github.com/python/cpython/commit/91daa9d7224626dad4bb820924c01b3438ca6e3f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:14:33 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 22 Nov 2019 09:14:33 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1574414073.03.0.394867788478.issue38863@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38863>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:15:04 2019
From: report at bugs.python.org (Iza Romanowska)
Date: Fri, 22 Nov 2019 09:15:04 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574414104.81.0.295238897869.issue38881@roundup.psfhosted.org>


Iza Romanowska <izaromanowska at gmail.com> added the comment:

Dear Raymond, 

I understand that passing all zero weights may look nonsensical but random.choices is an implementation of the roulette wheel which is widely used across different scientific disciplines and the situation of passing all zeros is completely plausible. 

In genetics:
A genome may consist of a set of genes none of which increases fitness thus their relative probability of being copied over other genes is all zero. 

In political sciences or cultural evolution:
A voter may hate all parties (ie. their individual preference for any one party is zero). An agent may happen to have no preference for either of the options. 

In engineering: 
All solutions may carry zero increase in performance. 

You are absolutely right that negative weights make no sense (how can you choose option A with a -10% chance. But a 0% chance is entirely possible. 

I consulted with colleagues working in other languages and it looks that the default for roulette wheel with zero weights is choosing at random. 
This should probably be consulted with a mathematician who knows the definition of the algorithm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:21:49 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Nov 2019 09:21:49 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574414509.52.0.840164905112.issue38870@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> @gvanrossum are you OK with adding type comments support? Current version loses type comment information so if typed_ast parses this, they wont be the same in AST representation.

Good catch, definitely do that!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:28:37 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 22 Nov 2019 09:28:37 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574414917.61.0.289887552462.issue38881@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

IIUC, there was a similar discussion on negative weights and all weights being zero to raise ValueError at https://bugs.python.org/issue18844#msg196252

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:33:42 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Nov 2019 09:33:42 +0000
Subject: [issue24995] better exception message when an unsupported object is
 passed to `async for` (pep 492)
In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za>
Message-ID: <1574415222.19.0.458268795772.issue24995@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Do what you think is best.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24995>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:33:49 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Nov 2019 09:33:49 +0000
Subject: [issue24995] better exception message when an unsupported object is
 passed to `async for` (pep 492)
In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za>
Message-ID: <1574415229.53.0.046268113206.issue24995@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24995>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:42:16 2019
From: report at bugs.python.org (Paul Moore)
Date: Fri, 22 Nov 2019 09:42:16 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574415736.34.0.914530277604.issue38021@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

PyPA member here - if this PR is defining new compatibility tags, I would have expected it to need discussion as a revision to PEP 425, much like the manylinux efforts did. (It may actually be a closer parallel with MacOS, which didn't have a tagging PEP - I'm not sure how that would relate here, but as MacOS is a much more mainstream platform I'd be inclined to err on the side of caution and look for AIX to be explicitly covered in the tag specs).

I thought that was something that had been discussed on the Pip tracker, but maybe the implications weren't clear (I don't really understand the AIX scheme, so I'm relying on someone else, probably Michael, to propose something that could be added to PEP 425 and to lead/guide the discussion).

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:45:31 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 22 Nov 2019 09:45:31 +0000
Subject: [issue38891] ShareableList read and write access is O(N),
 should be O(1)
In-Reply-To: <1574389874.92.0.425732905902.issue38891@roundup.psfhosted.org>
Message-ID: <1574415931.51.0.986821728948.issue38891@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

IMHO,

1. replace self._allocated_bytes to self._sum_allocated_bytes
2. initialize self._sum_allocated_bytes at the __init__ time.
2. if self._allocated_bytes is needed, calculate from _sum_allocated_bytes it will take O(1)

If the suggestion is accepted, I'd like to work on this issue.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38891>
_______________________________________

From report at bugs.python.org  Fri Nov 22 04:58:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 09:58:03 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574416683.91.0.6948547337.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 310e2d25170a88ef03f6fd31efcc899fe062da2c by Victor Stinner in branch 'master':
bpo-36854: Fix refleak in subinterpreter (GH-17331)
https://github.com/python/cpython/commit/310e2d25170a88ef03f6fd31efcc899fe062da2c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 05:00:59 2019
From: report at bugs.python.org (PCManticore)
Date: Fri, 22 Nov 2019 10:00:59 +0000
Subject: [issue38876] pickle is raising KeyError insteat of
 pickle.UnpicklingError under certain conditions
In-Reply-To: <1574335379.18.0.441188503497.issue38876@roundup.psfhosted.org>
Message-ID: <1574416859.38.0.249506475632.issue38876@roundup.psfhosted.org>


Change by PCManticore <pcmanticore at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38876>
_______________________________________

From report at bugs.python.org  Fri Nov 22 05:23:05 2019
From: report at bugs.python.org (Bar Harel)
Date: Fri, 22 Nov 2019 10:23:05 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574418185.15.0.106866244299.issue38878@roundup.psfhosted.org>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
keywords: +patch
pull_requests: +16820
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17336

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Fri Nov 22 05:30:21 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 22 Nov 2019 10:30:21 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574418621.57.0.923782062799.issue22367@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

And the other AIX bot has been repaired, and is running green as well!

:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 22 05:33:44 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 22 Nov 2019 10:33:44 +0000
Subject: [issue38852] test_recursion_limit in test_threading crashes with
 SIGSEGV on android
In-Reply-To: <1574193737.03.0.937540674169.issue38852@roundup.psfhosted.org>
Message-ID: <1574418824.05.0.233695130562.issue38852@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38852>
_______________________________________

From report at bugs.python.org  Fri Nov 22 05:35:37 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Nov 2019 10:35:37 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574418937.46.0.326181452479.issue38881@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

xtreak, the other discussion isn't similar at all.  The OP is proposing that weights all equal to zero be a well-defined way to specify an equiprobable selection.  That is a completely new proposal which is easy to implement, but doesn't make much sense to me.  

The current concept is that the weights express an odds ratio where a zero weight means that an event has no chance of being selected.  This view implies that if all weights are zero, the result is undefined (or an error).

Iza, it seems to me that the provided examples are conflating a zero incremental preference with a zero chance of occurrence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Fri Nov 22 05:36:36 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 22 Nov 2019 10:36:36 +0000
Subject: [issue38852] test_recursion_limit in test_threading crashes with
 SIGSEGV on android
In-Reply-To: <1574193737.03.0.937540674169.issue38852@roundup.psfhosted.org>
Message-ID: <1574418996.3.0.483991988661.issue38852@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Using test and try with _thread.stack_size(new_size), the pthread stack sizes must be set to the following minimums to prevent stack overflow and get a RecursionError:
  * debug builds:    7 Mb
  * no-debug builds: 1 Mb

The default stack size for the main thread does not need to be changed as test test_exceptions.ExceptionTests.testInfiniteRecursion is ok for both build types.

PR 17337 sets the thread stack size to 8 Mb for debug builds on android platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38852>
_______________________________________

From report at bugs.python.org  Fri Nov 22 06:12:11 2019
From: report at bugs.python.org (Socob)
Date: Fri, 22 Nov 2019 11:12:11 +0000
Subject: [issue17639] symlinking .py files creates unexpected sys.path
In-Reply-To: <1365154146.05.0.401345898234.issue17639@psf.upfronthosting.co.za>
Message-ID: <1574421131.99.0.324591836256.issue17639@roundup.psfhosted.org>


Change by Socob <206a8535 at opayq.com>:


----------
nosy: +Socob

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17639>
_______________________________________

From report at bugs.python.org  Fri Nov 22 06:18:30 2019
From: report at bugs.python.org (Iza Romanowska)
Date: Fri, 22 Nov 2019 11:18:30 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574421510.45.0.168411303692.issue38881@roundup.psfhosted.org>


Iza Romanowska <izaromanowska at gmail.com> added the comment:

Hi, 

Many thanks for engaging with this. 
I agree that we should very clearly separate negative weights from zero weights. A negative number is illegal and that's the end of it. However, a zero weight is not illegal, e.g., [0, 0, 0, 0.1] is a legal sequence to pass as weight. 

Raymond, I agree with you that this is conflating incremental preference with zero chance of occurring. From a standard user perspective, if the [0, 0, 0, 0.1] sequence is passed as weights the first three options have a zero probability of selection thus that interpretation (even if in your opinion erroneous) is very likely to happen for most of the users. 

I think we all agree that an output that always chooses the last element of the sequence is not ok. We differ in opinion as to what should happen instead: raising an error or returning a value at random. My arguments for the latter are: 
 - this seems to be the standard for other programming languages (I've checked for R and NetLogo but this should be confirmed by others);
 - a weight sequence [1, 1, 1, 1] is equivalent to [10, 10, 10, 10] so if we don't want to make [0, 0, 0, 0] 'a special case' it should give the same behaviour (equal probability);
 - when a weight sequence is not provided (i.e., there are no odds given) a random selection is made. One can argue that the odds [,,,,] are similar to [0, 0, 0, 0 ]. Perhaps the zero weights option could be pushed into the if-loop of no weights? 

I see the logic of the second solution, i.e., raising an error. It may make it more difficult to catch the issue for those doing simulations but at least it's not giving a wrong result. 
 
As mentioned this is a key algorithm for many scientific applications with predominantly non-computer science users like myself. So please do take into consideration that it will be often used naively. 

Many thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Fri Nov 22 06:27:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 11:27:56 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574422076.87.0.173813935434.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3d4833488a173c16446c3f94f58f05e2d13c5dee by Victor Stinner in branch 'master':
bpo-38858: Call _PyUnicode_Fini() in Py_EndInterpreter() (GH-17330)
https://github.com/python/cpython/commit/3d4833488a173c16446c3f94f58f05e2d13c5dee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 06:30:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 11:30:13 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574422213.34.0.116900514187.issue36854@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16822
pull_request: https://github.com/python/cpython/pull/17338

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 06:36:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 11:36:32 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574422592.79.0.14841371745.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset 310e2d25170a88ef03f6fd31efcc899fe062da2c by Victor Stinner in branch 'master':
> bpo-36854: Fix refleak in subinterpreter (GH-17331)

I'm not fully happy with this solution, but at least, it allows me to move on to the next tasks to implement subinterpreters like PR 17315 (bpo-38858: Small integer per interpreter).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 06:49:21 2019
From: report at bugs.python.org (Martin Teichmann)
Date: Fri, 22 Nov 2019 11:49:21 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574423360.99.0.509899222443.issue37334@roundup.psfhosted.org>


Martin Teichmann <martin.teichmann at gmail.com> added the comment:

Hi Andrew,

I still don't get your point. First, this is an extension to the asyncio library, so concurrency is not an issue. And sure, if you call random methods of an object without any reason the outcome won't be anything useful, why, in your example, should the one task call close at all?

There is, however, a strong use case: If you have many producers but just one consumer and the consumer stops consuming, it should cancel all producers waiting on the queue. The same way, if you have one producer but many consumers, once the single producer stops producing, it should cancel all waiting consumers. In these situations, the outcome is very clear.

Whether it should be possible to "resurrect" a closed/cancelled queue I don't care much, as I neither see a use case in doing so nor a compelling argument why it should be artificially prohibited. So I simply went for the most simple code.

The proposed code does something very simple, something a user can grasp. That is IMHO a better protection for users than some code trying to artificially stop users from harming themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Fri Nov 22 07:30:23 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 22 Nov 2019 12:30:23 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574425823.85.0.639651650972.issue38692@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Thank you very much for the commit "Skip test_posix.test_pidfd_open() on EPERM"! I can confirm it makes test_posix pass inside a systemd-nspawn container on Arch Linux. On the other hand, I found that tests were broken as both systemd libseccomp on Arch Linux were out-dated. With recently-pushed systemd 243.162-2 and locally-updated libseccomp 2.4.2, os.pidfd_open() works fine. Apparently [1] and [2] are relevant fixes.

By the way, upgrading systemd and libseccomp also fixes test_signal.PidfdSignalTest [3], which is added two days ago [4].

[1] https://github.com/systemd/systemd-stable/commit/51ea58a04b1851b31a14dfa7eec76254f5ddef16
[2] https://github.com/seccomp/libseccomp/commit/be65b26b67099be2b2b4890d736dbd1ad15adf36
[3] https://github.com/python/cpython/pull/17290#issuecomment-556869679
[4] https://bugs.python.org/issue38712

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Fri Nov 22 07:37:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 22 Nov 2019 12:37:17 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1574426237.76.0.516784947784.issue24084@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24084>
_______________________________________

From report at bugs.python.org  Fri Nov 22 07:39:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 12:39:13 +0000
Subject: [issue38692] add a pidfd child process watcher
In-Reply-To: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>
Message-ID: <1574426353.01.0.823199295907.issue38692@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I can confirm it makes test_posix pass inside a systemd-nspawn container on Arch Linux.

Great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38692>
_______________________________________

From report at bugs.python.org  Fri Nov 22 07:39:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 12:39:54 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574426394.51.0.284956897502.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 84c36c152a2bdf98f9cc7ce0e1db98e1f442a05e by Victor Stinner in branch '3.8':
bpo-36854: Fix reference counter in PyInit__testcapi() (GH-17338)
https://github.com/python/cpython/commit/84c36c152a2bdf98f9cc7ce0e1db98e1f442a05e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 07:39:56 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 12:39:56 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574426396.22.0.187134873991.issue36854@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16823
pull_request: https://github.com/python/cpython/pull/17339

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 07:52:03 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 22 Nov 2019 12:52:03 +0000
Subject: [issue38866] test_pyclbr replace asyncore
In-Reply-To: <1574270826.5.0.92652602871.issue38866@roundup.psfhosted.org>
Message-ID: <1574427123.33.0.832374254.issue38866@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 138e7bbb0a5ed44bdd54605e8c58c8f3d3865321 by Inada Naoki (jacksonriley) in branch 'master':
bpo-38866: Remove asyncore from test_pyclbr.py (GH-17316)
https://github.com/python/cpython/commit/138e7bbb0a5ed44bdd54605e8c58c8f3d3865321


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38866>
_______________________________________

From report at bugs.python.org  Fri Nov 22 07:57:02 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 12:57:02 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574427422.71.0.321782438345.issue36854@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bff525566469021949910deec84e837306b79886 by Miss Islington (bot) in branch '3.7':
bpo-36854: Fix reference counter in PyInit__testcapi() (GH-17338)
https://github.com/python/cpython/commit/bff525566469021949910deec84e837306b79886


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 08:00:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 13:00:23 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574427623.01.0.0727605853437.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close again the issue ;-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 08:05:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 13:05:40 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574427940.79.0.767593906559.issue38500@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16824
pull_request: https://github.com/python/cpython/pull/17340

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 08:12:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 13:12:21 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574428341.61.0.970680871286.issue38500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote PR 17340 to add Add PyInterpreterState_GetEvalFrameFunc() and PyInterpreterState_SetEvalFrameFunc() functions.

Since the PEP 523 has been approved, for me, these functions must be public, not private. My implementation adds these functions to Include/cpython/pystate.h: "non-portable" API specific to CPython (exclude from the limited C API).

PyInterpreterState_GetEvalFrameFunc() is needed if you want to inject a "hook" and not really replaced the whole function. For example, execute code before or after the call. I guess that PyCharm debugger works like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 08:27:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 13:27:01 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574429221.23.0.0493584512536.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I introduced a workaround to a reference leak in bpo-36854 because _PyImport_Cleanup() doesn't clear modules dictionary in some cases:
https://bugs.python.org/issue36854#msg357160

Maybe _PyImport_Cleanup() should be enhanced to ensure that the dictionary of all modules is cleared when the function exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 08:28:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 13:28:55 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1574429335.52.0.177447038114.issue33387@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Can this issue be closed now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Fri Nov 22 08:33:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 13:33:24 +0000
Subject: [issue36732] Windows: test_asyncio: test_huge_content_recvinto()
 fails randomly with ProactorEventLoop
In-Reply-To: <1556264661.54.0.31283754406.issue36732@roundup.psfhosted.org>
Message-ID: <1574429604.58.0.390831411658.issue36732@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Windows7 SP1 3.x:
https://buildbot.python.org/all/#/builders/40/builds/3470

ERROR: test_huge_content_recvinto (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests)
...
ERROR: test_huge_content (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36732>
_______________________________________

From report at bugs.python.org  Fri Nov 22 08:39:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 13:39:33 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574429973.39.0.278030664967.issue38500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

New question: if we add a public API to Python 3.8.1, would it make sense to directly change eval_frame type to add a new "tstate" parameter? See bpo-38818 for the rationale.

I already proposed a change for the master branch: https://github.com/python/cpython/pull/17187

Maybe I should combine PR 17340 (add PyInterpreterState_SetEvalFrameFunc()) with PR 17187 (add tstate parameter).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 08:56:11 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Nov 2019 13:56:11 +0000
Subject: [issue17639] symlinking .py files creates unexpected sys.path
In-Reply-To: <1574421132.03.0.115154305615.issue17639@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+HYS=FxxM80PpMkGJCLc0LVC+rGLXtXvd6-8=W-trjVw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

It is quite intentional that symlinks are followed for the purpose of
computing sys. argv[0] and sys.path.
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17639>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:06:07 2019
From: report at bugs.python.org (Thierry Parmentelat)
Date: Fri, 22 Nov 2019 14:06:07 +0000
Subject: [issue38894] Path.glob() sometimes misses files that match
Message-ID: <1574431567.77.0.580808736749.issue38894@roundup.psfhosted.org>


New submission from Thierry Parmentelat <thierry.parmentelat at inria.fr>:

I have observed this on a linux box running fedora29

$ python3 --version
Python 3.7.5
$ uname -a
Linux faraday.inria.fr 5.3.11-100.fc29.x86_64 #1 SMP Tue Nov 12 20:41:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/fedora-release
Fedora release 29 (Twenty Nine)

============ steps to reproduce:

This assumes that /root is not readable by lambda users

----- as root:

# mkdir /tmp/foo
# cd /tmp/foo
# touch a b d e
# ln -s /root/anywhere c

# ls -l
total 0
-rw-r--r-- 1 root root  0 Nov 22 14:51 a
-rw-r--r-- 1 root root  0 Nov 22 14:51 b
lrwxrwxrwx 1 root root 14 Nov 22 14:53 c -> /root/anywhere
-rw-r--r-- 1 root root  0 Nov 22 14:51 d
-rw-r--r-- 1 root root  0 Nov 22 14:51 e


----- as a lambda user:

we can see all files

$ ls -l /tmp/foo
total 0
-rw-r--r-- 1 root root  0 Nov 22 14:51 a
-rw-r--r-- 1 root root  0 Nov 22 14:51 b
lrwxrwxrwx 1 root root 14 Nov 22 14:53 c -> /root/anywhere
-rw-r--r-- 1 root root  0 Nov 22 14:51 d
-rw-r--r-- 1 root root  0 Nov 22 14:51 e

and with glob.glob() too

In [1]: import glob

In [2]: for filename in glob.glob("/tmp/foo/*"):
   ...:     print(filename)
   ...:
/tmp/foo/c
/tmp/foo/e
/tmp/foo/d
/tmp/foo/b
/tmp/foo/a


BUT Path.glob() is not working as expected

In [3]: from pathlib import Path

In [4]: for filename in Path("/tmp/foo/").glob("*"):
   ...:     print(filename)
   ...:



----- If I now I go back as root and remove the problematic file in /tmp/foo

# rm /tmp/foo/c


----- and try again as a lambda user

In [5]: for filename in Path("/tmp/foo/").glob("*"):
   ...:     print(filename)
   ...:
/tmp/foo/e
/tmp/foo/d
/tmp/foo/b
/tmp/foo/a


============ discussion

in my case in a real application I was getting *some* files - not an empty list like here. 

I ran strace on that real application
it's fairly clear from that output that the odd symlink is causing the scanning of all files to break instead of continuing (see snip below)
of course the order in which files are read from the disk will impact the behaviour, that's why I created the symlink last, that might need to be changed to reproduce successfully in another setup



============ strace extract

<snip>
getdents64(3, /* 189 entries */, 32768) = 8640
getdents64(3, /* 0 entries */, 32768)   = 0
close(3)                                = 0
stat("/var/lib/rhubarbe-images/centos.ndz", {st_mode=S_IFREG|0644, st_size=1002438656, ...}) = 0
stat("/var/lib/rhubarbe-images/oai-enb.ndz", {st_mode=S_IFREG|0644, st_size=2840592384, ...}) = 0
<snip>
stat("/var/lib/rhubarbe-images/ubuntu-floodlight.ndz", {st_mode=S_IFREG|0644, st_size=2559574016, ...}) = 0
stat("/var/lib/rhubarbe-images/ndnsim.ndz", {st_mode=S_IFREG|0644, st_size=4153409536, ...}) = 0

==> that's the line about the broken symlink in my real app
stat("/var/lib/rhubarbe-images/push-to-preplab.sh", 0x7ffd3ac4a140) = -1 EACCES (Permission denied)
==> and here it stops scanning files while there are still quite a lot to be dealt with

write(1, "/var/lib/rhubarbe-images/fedora-"..., 82/var/lib/rhubarbe-images/fedora-31.ndz
/var/lib/rhubarbe-images/fedora-31-ssh.ndz
) = 82
rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fc583705e70}, {sa_handler=0x7fc583936f10, sa_mask=[], \
sa_flags=SA_RESTORER, sa_restorer=0x7fc583705e70}, 8) = 0
sigaltstack(NULL, {ss_sp=0x560a7dac3330, ss_flags=0, ss_size=16384}) = 0
sigaltstack({ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=0}, NULL) = 0
exit_group(0)                           = ?
+++ exited with 0 +++

----------
messages: 357284
nosy: thierry.parmentelat
priority: normal
severity: normal
status: open
title: Path.glob() sometimes misses files that match
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38894>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:06:05 2019
From: report at bugs.python.org (Caleb Hattingh)
Date: Fri, 22 Nov 2019 14:06:05 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574431565.17.0.343739237401.issue37334@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

Ok, I see now. The improvement with only a single producer/consumer might be marginal, but the proposition that `queue.cancel()` might simplify the situation with multiple producers and/or consumers is more compelling.

Usually, assuming M producers and N threads (and 1 queue), one would typically stop the M producers outright, and then place N `None` values on the queue, and then each consumer shuts itself down when it receives a `None`.  It's clunky but it works. 

This from experience with threaded code, but the difference with asyncio is that we have cancellation available to us, whereas we could not cancel threads. I think this is why I've carried over my queue-idioms from threads to asyncio. So this is an interesting idea: if we introduce cancellation to queue handling, do things get better for the MxN producers and consumers design?

Rehashing, what I might expect to happen when I call `queue.cancel()` is that 

1. A CancelledError (or maybe`QueueCancelled`?) exception is raised in all producers and consumers ) - this gives a producer a chance to handle the error and do something with the waiting item that could not be `put()`
2. Items currently on the queue still get processed in the consumers before the consumers exit.

I think (1) is easy, but I expected (2) to be more tricky. You said it already works that way in your PR. I didn't believe it so I wrote a silly program to check, and it does! All pending items on the queue are still consumed by consumers even after the queue._getters futures are cancelled.  

So yes, both (1) and (2) appear to work.

> As for the "why don't I just cancel the task?", well, if you know it. There may be many consumer or producer tasks waiting for their turn. Sure, you can keep a list of all those tasks. But that's exactly the point of the proposed change: the Queue already knows all the waiting tasks, no need to keep another list up-to-date!

Finally - while I think the MxN producers/consumers case might be simplified by this, it's worth noting that usually in shutdown, *all* the currently-pending tasks are cancelled anyway. And as I said before, in an MxN queue scenario, one might place N `None` values on the queue, and then just send `CancelledError` to everything anyway (consumers will ignore the cancellation and just wait for the `None`s to exit). This works well.  

Thus, if `queue.cancel()` were available to me right now, the primary difference as I see it would be that during shutdown, instead of placing N `None` values on the queue, I would instead call `queue.cancel()`. I agree that's a bit neater.  (It however will still necessary to absorb CancelledError in the consumers, e.g. what is raised by `asyncio.run()` during shutdown, so that's unchanged).

I agree with Yury that I don't like `queue.close`. "Cancel" seems better after all.

I disagree with Yury that items are discarded - I checked that already-present items on the queue will still be consumed by consumers, before the `queue.close` cancellation is actually raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:14:19 2019
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 22 Nov 2019 14:14:19 +0000
Subject: [issue17639] symlinking .py files creates unexpected sys.path
In-Reply-To: <1365154146.05.0.401345898234.issue17639@psf.upfronthosting.co.za>
Message-ID: <1574432059.06.0.718484464651.issue17639@roundup.psfhosted.org>


Kristj?n Valur J?nsson <sweskman at gmail.com> added the comment:

So you have already stated, and this issue is six years old now.

While I no longer have a stake in this, I'd just like to reiterate that IMHO it breaks several good practices of architecture, particularly that of separation of roles.

The abstraction called symbolic links is the domain of the filesystem.  An application should accept the image that the filesystem offers, not try to second-guess the intent of an operator by arbitrarily, and unexpectedly, unrolling that abstraction.

While you present a use case, I argue that it isn't, and shouldn't be, the domain of the application to intervene in an essentially shell specific, and operator specific process of collecting his favorite shortcuts in a folder.  For that particular use case, a more sensible way would be for the user to simply create shell shortcuts, even aliases, for his favorite python scripts.  This behaviour is basically taking over what should be the role of the shell.  I'm unable to think of another program doing this sort of thin.

I suppose that now, with the reworked startup process, it would be simpler to actually document this rather unexpected behaviour, and possibly provide a flag to override it.  I know that I some spent time on this and came away rather stumped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17639>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:15:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 14:15:40 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574432140.25.0.922750598447.issue22367@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c3cd0de9ec7ab54186cebef5b2edfd098f7ae387 by Victor Stinner (Miss Islington (bot)) in branch '3.8':
bpo-22367: Update test_fcntl.py for spawn process mode (GH-17154) (GH-17252)
https://github.com/python/cpython/commit/c3cd0de9ec7ab54186cebef5b2edfd098f7ae387


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:15:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 14:15:46 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1574432146.05.0.0426187880235.issue22367@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d4d79209e69d52ea4c047545c6c60c3ba75f15f4 by Victor Stinner (Miss Islington (bot)) in branch '3.7':
bpo-22367: Update test_fcntl.py for spawn process mode (GH-17154) (GH-17253)
https://github.com/python/cpython/commit/d4d79209e69d52ea4c047545c6c60c3ba75f15f4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:19:22 2019
From: report at bugs.python.org (Thierry Parmentelat)
Date: Fri, 22 Nov 2019 14:19:22 +0000
Subject: [issue38894] Path.glob() sometimes misses files that match
In-Reply-To: <1574431567.77.0.580808736749.issue38894@roundup.psfhosted.org>
Message-ID: <1574432362.16.0.281012021767.issue38894@roundup.psfhosted.org>


Thierry Parmentelat <thierry.parmentelat at inria.fr> added the comment:

to clarify, when I said 'lambda user' I mean regular, non-root user that has no permission to read in /root

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38894>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:19:57 2019
From: report at bugs.python.org (Marc Culler)
Date: Fri, 22 Nov 2019 14:19:57 +0000
Subject: [issue38882] IDLE should not make the about dialog be a transient of
 the withdrawn root window
In-Reply-To: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>
Message-ID: <1574432397.55.0.0459423382182.issue38882@roundup.psfhosted.org>


Marc Culler <marc.culler at gmail.com> added the comment:

It definitely makes sense for an on-screen window to have a transient
dialog.  With a little care (see "messages boxes" in the widget demo)
on the mac the transient can be a "sheet" that opens from the top of
the master window.  It even makes sense for an iconified window to have
a transient since the window manager still controls iconified windows.
But a withdrawn window, with no icon (and no listing in the mac Window 
menu) is beyond the user's control.  The really deadly combination is
when a transient of a withdrawn window (so the transient is withdrawn)
also has a grab on mouse and keyboard events.  That one should be
avoided.  It is not clear to me why Tk allows it. I believe it should
be avoided on all platforms, since withdrawn windows are supposed to
be completely removed from the window manager and only known to Tk.
But testing is needed, of course.

I don't know the full history.  I know there were changes between 8.6.9
and 8.6.10 needed to bring the mac port to its current state where it
passes all of the Tk regression tests. (That is not the case with unix
at the moment and I know there are many issues with iconified and
withdrawn windows in Gnome 3 due to changes in window manager behavior
which have not been fully incorporated into Tk.) I suspect there were
many prior releases with no changes to this behavior on the mac.

PS The formerly soon-to-be-released 8.6.10 has now been released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:22:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 14:22:18 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574432537.99.0.686943260925.issue38804@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1b779bfb8593739b11cbb988ef82a883ec9d077e by Victor Stinner (bcaller) in branch 'master':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157)
https://github.com/python/cpython/commit/1b779bfb8593739b11cbb988ef82a883ec9d077e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:23:13 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 14:23:13 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574432593.95.0.105835503786.issue38804@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16825
pull_request: https://github.com/python/cpython/pull/17341

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:23:57 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 14:23:57 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574432637.06.0.0910174134277.issue38804@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16826
pull_request: https://github.com/python/cpython/pull/17342

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:24:57 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 14:24:57 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574432697.54.0.636576920863.issue38804@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16827
pull_request: https://github.com/python/cpython/pull/17343

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:28:37 2019
From: report at bugs.python.org (Marc Culler)
Date: Fri, 22 Nov 2019 14:28:37 +0000
Subject: [issue38882] IDLE should not make the about dialog be a transient of
 the withdrawn root window
In-Reply-To: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>
Message-ID: <1574432917.25.0.104227058361.issue38882@roundup.psfhosted.org>


Marc Culler <marc.culler at gmail.com> added the comment:

I should have mentioned that I did not see the IDLE hang with Python 3,
only with Python 2.7.  So I changed the Version in the ticket.

----------
versions: +Python 3.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:31:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 14:31:18 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574433078.23.0.733039779225.issue38804@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16828
pull_request: https://github.com/python/cpython/pull/17344

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:36:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 14:36:26 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574433386.64.0.132178679525.issue38804@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16829
pull_request: https://github.com/python/cpython/pull/17345

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:42:13 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 14:42:13 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574433733.29.0.099137577229.issue38804@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a1e1be4c4969c7c20c8c958e5ab5279ae6a66a16 by Miss Islington (bot) in branch '3.8':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157)
https://github.com/python/cpython/commit/a1e1be4c4969c7c20c8c958e5ab5279ae6a66a16


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:42:17 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 14:42:17 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574433737.41.0.959569574316.issue38804@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cb6085138a845f8324adc011b65754acc2086cc0 by Miss Islington (bot) in branch '3.7':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157)
https://github.com/python/cpython/commit/cb6085138a845f8324adc011b65754acc2086cc0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:45:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 14:45:54 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574433954.76.0.886125682105.issue38804@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm now tracking this vulnerability at:
https://python-security.readthedocs.io/vuln/cookiejar-redos.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 09:55:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 14:55:25 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574434525.74.0.0709132386638.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16830
pull_request: https://github.com/python/cpython/pull/17346

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 10:05:46 2019
From: report at bugs.python.org (=?utf-8?q?Jukka_V=C3=A4is=C3=A4nen?=)
Date: Fri, 22 Nov 2019 15:05:46 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574435146.41.0.0553315225316.issue37228@roundup.psfhosted.org>


Jukka V?is?nen <vaizki at vaizki.fi> added the comment:

> Are you aware of what currently supported platforms have SO_REUSEPORT defined where the *reuse_port* parameter doesn't actually work? This would be quite helpful to know. 

This was reported by a partner that was working porting our code to Android but might be fixed current Android API levels. I cannot test this myself.

> .. we don't directly support every single available platform, as making the code specific to an OS incurs a long-term maintenance cost

Fully agree, part of the reason why I was suggesting getting rid of reuse_address and reuse_port completely on this higher level API. 

But I'm happy with Antoine's proposal which effectively kills the reuse_address parameter, just suggesting we also kill reuse_port as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Fri Nov 22 10:08:47 2019
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 22 Nov 2019 15:08:47 +0000
Subject: [issue38748] 32 bit ctypes stdcall callback fails to restore stack
 pointer
In-Reply-To: <1573232254.38.0.286098798289.issue38748@roundup.psfhosted.org>
Message-ID: <1574435327.27.0.443639915149.issue38748@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38748>
_______________________________________

From report at bugs.python.org  Fri Nov 22 10:19:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 15:19:18 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574435958.28.0.200125516902.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e0c9ab8e26d1648b870b80c296b2490a5e9553e5 by Victor Stinner in branch 'master':
bpo-38858: Add init_set_builtins_open() subfunction (GH-17346)
https://github.com/python/cpython/commit/e0c9ab8e26d1648b870b80c296b2490a5e9553e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 10:48:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 15:48:28 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574437708.72.0.0507209076512.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16831
pull_request: https://github.com/python/cpython/pull/17347

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 10:57:32 2019
From: report at bugs.python.org (Julian)
Date: Fri, 22 Nov 2019 15:57:32 +0000
Subject: [issue38895] performance degradation creating a mock object
Message-ID: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>


New submission from Julian <julian at hille.family>:

There seems to be a performance issue when creating a Mock() object from unittest module.
The performance difference between 3.7.x and 3.8.0 is about 7-8 times slower in 3.8

Heres the smalles sample i could generate:

Using python 3.7.5

```
python3 -m timeit -v --number=100000 --setup="from unittest.mock import Mock" "Mock()"
raw times: 2.99 sec, 2.96 sec, 3.33 sec, 2.98 sec, 2.92 sec

100000 loops, best of 5: 29.2 usec per loop
```


Using python 3.8.0
```
python3 -m timeit -v --number=100000 --setup="from unittest.mock import Mock" "Mock()"
raw times: 16.9 sec, 17 sec, 17.7 sec, 18.1 sec, 16.3 sec

100000 loops, best of 5: 163 usec per loop

```

I did not find that issue, but a co-worker.

----------
messages: 357297
nosy: julianhille
priority: normal
severity: normal
status: open
title: performance degradation creating a mock object
type: performance
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Fri Nov 22 11:10:30 2019
From: report at bugs.python.org (Julian)
Date: Fri, 22 Nov 2019 16:10:30 +0000
Subject: [issue38895] performance degradation creating a mock object (by
 factor 7-8)
In-Reply-To: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>
Message-ID: <1574439030.58.0.410702015807.issue38895@roundup.psfhosted.org>


Change by Julian <julian at hille.family>:


----------
title: performance degradation creating a mock object -> performance degradation creating a mock object (by factor 7-8)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Fri Nov 22 11:30:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 22 Nov 2019 16:30:23 +0000
Subject: [issue38895] performance degradation creating a mock object (by
 factor 7-8)
In-Reply-To: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>
Message-ID: <1574440223.31.0.272496161675.issue38895@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Fri Nov 22 11:52:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 16:52:51 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574441571.59.0.252128836153.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b00513636c9891deba4cae50217e25e8faf6c6ac by Victor Stinner in branch 'master':
bpo-38858: Add init_interp_main() subfunction (GH-17347)
https://github.com/python/cpython/commit/b00513636c9891deba4cae50217e25e8faf6c6ac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 11:57:18 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Nov 2019 16:57:18 +0000
Subject: [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1574441838.47.0.571746253507.issue29275@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 42bc60ead39c7be9f6bb7329977826e962f601eb by Benjamin Peterson (Callum Ward) in branch 'master':
closes bpo-29275: Remove Y2K reference from time module docs (GH-17321)
https://github.com/python/cpython/commit/42bc60ead39c7be9f6bb7329977826e962f601eb


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29275>
_______________________________________

From report at bugs.python.org  Fri Nov 22 11:57:27 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 16:57:27 +0000
Subject: [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1574441847.19.0.483665442722.issue29275@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16832
pull_request: https://github.com/python/cpython/pull/17348

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29275>
_______________________________________

From report at bugs.python.org  Fri Nov 22 11:57:34 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 16:57:34 +0000
Subject: [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1574441854.14.0.712995894901.issue29275@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16833
pull_request: https://github.com/python/cpython/pull/17349

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29275>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:03:07 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 17:03:07 +0000
Subject: [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1574442187.89.0.170347670959.issue29275@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c58a8116475fc9e90fe87b150cde4e535173ec1c by Miss Islington (bot) in branch '3.7':
closes bpo-29275: Remove Y2K reference from time module docs (GH-17321)
https://github.com/python/cpython/commit/c58a8116475fc9e90fe87b150cde4e535173ec1c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29275>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:03:54 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 17:03:54 +0000
Subject: [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1574442234.29.0.0321090873416.issue29275@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ca5fafc2bbda9373c9ab12b76d17614585cffc23 by Miss Islington (bot) in branch '3.8':
closes bpo-29275: Remove Y2K reference from time module docs (GH-17321)
https://github.com/python/cpython/commit/ca5fafc2bbda9373c9ab12b76d17614585cffc23


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29275>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:15:12 2019
From: report at bugs.python.org (Marc Culler)
Date: Fri, 22 Nov 2019 17:15:12 +0000
Subject: [issue38882] IDLE should not make the about dialog be a transient of
 the withdrawn root window
In-Reply-To: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>
Message-ID: <1574442912.99.0.29045429721.issue38882@roundup.psfhosted.org>


Change by Marc Culler <marc.culler at gmail.com>:


----------
versions: +Python 2.7 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:24:52 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Nov 2019 17:24:52 +0000
Subject: [issue17639] symlinking .py files creates unexpected sys.path
In-Reply-To: <1574432059.06.0.718484464651.issue17639@roundup.psfhosted.org>
Message-ID: <CAP7+vJLRHZ1Fm=fm+wH746FgTFR5WkcywycP2C5xSdUNC-bsXw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

You have a point ? I was just responding to Nick?s last message without
noticing how old it was. I?ll remove myself from the nosy list.

On Fri, Nov 22, 2019 at 15:14 Kristj?n Valur J?nsson <report at bugs.python.org>
wrote:

>
> Kristj?n Valur J?nsson <sweskman at gmail.com> added the comment:
>
> So you have already stated, and this issue is six years old now.
>
> While I no longer have a stake in this, I'd just like to reiterate that
> IMHO it breaks several good practices of architecture, particularly that of
> separation of roles.
>
> The abstraction called symbolic links is the domain of the filesystem.  An
> application should accept the image that the filesystem offers, not try to
> second-guess the intent of an operator by arbitrarily, and unexpectedly,
> unrolling that abstraction.
>
> While you present a use case, I argue that it isn't, and shouldn't be, the
> domain of the application to intervene in an essentially shell specific,
> and operator specific process of collecting his favorite shortcuts in a
> folder.  For that particular use case, a more sensible way would be for the
> user to simply create shell shortcuts, even aliases, for his favorite
> python scripts.  This behaviour is basically taking over what should be the
> role of the shell.  I'm unable to think of another program doing this sort
> of thin.
>
> I suppose that now, with the reworked startup process, it would be simpler
> to actually document this rather unexpected behaviour, and possibly provide
> a flag to override it.  I know that I some spent time on this and came away
> rather stumped.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue17639>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17639>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:29:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 17:29:00 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574443740.8.0.342308562582.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16834
pull_request: https://github.com/python/cpython/pull/17350

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:31:14 2019
From: report at bugs.python.org (Martin Teichmann)
Date: Fri, 22 Nov 2019 17:31:14 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574443874.57.0.960323538654.issue37334@roundup.psfhosted.org>


Martin Teichmann <martin.teichmann at gmail.com> added the comment:

Yes, in the one-producer-many-consumers situation on can indeed to the trick with the None. But this is just a clumsy hack, cancelling the tasks is IMHO more in line with asyncio.

In the many-producers-one-consumer scenario this does not work. The one dead consumer cannot feed back to the producers. Sure, there are still many hacks imaginable, but a closing or cancelling the queue is a very clear way of doing things.

As for the naming: I personally don't care, close() or cancel() are both fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:41:25 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 22 Nov 2019 17:41:25 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574444485.74.0.836036332835.issue38021@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

@paul.moore - thanks for the comment.

I am trying to work from both https://packaging.python.org/specifications/platform-compatibility-tags/ which describes in a few words the goals of PEP425.

As to the PEP425 itself, it does not specify what a tag looks like. Within the EPE the only description is:

The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _.

Like the platform-compatibility-tags reference says - the rational (aka requirement) 

"distributions should have a file naming convention that includes enough information to decide whether or not a particular archive is compatible with a particular implementation."

The tag I am proposing 'includes enough information'.

Further, as to the comparison of Linux and macos approaches to tags and deciding "whether or not a particular archive is compatible" AIX system architecture does not have to deal with the diversity that Linux platforms do - so it would be closer to macos approach.

Actually, deciding if a bdist is compatible or not will not be the hard part. However, I prefer to discuss that after a starting point - the platform tag itself - is achieved.

The last bit I am looking into is how, e.g., ``pip`` looks/searches pypi for candidates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:47:31 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 22 Nov 2019 17:47:31 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574444851.26.0.313400561778.issue37334@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

My point is that closing (or cancellation) should be one-way ticket.

Is there a case where continuing after stopping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:52:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 17:52:31 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574445151.83.0.309815363498.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 82c83bd907409c287a5bd0d0f4598f2c0538f34d by Victor Stinner in branch 'master':
bpo-38858: _PyImport_FixupExtensionObject() handles subinterpreters (GH-17350)
https://github.com/python/cpython/commit/82c83bd907409c287a5bd0d0f4598f2c0538f34d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:53:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 17:53:26 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574445206.66.0.398750982077.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16835
pull_request: https://github.com/python/cpython/pull/17351

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:54:20 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 22 Nov 2019 17:54:20 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574445260.76.0.101030432873.issue37334@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> 1. A CancelledError (or maybe`QueueCancelled`?) exception is raised in all producers and consumers ) - this gives a producer a chance to handle the error and do something with the waiting item that could not be `put()`

> 2. Items currently on the queue still get processed in the consumers before the consumers exit.

This (especially 2) sounds quite tricky.

Maybe we should just add a method to Queue to get the list of current consumers, of pending consumers, and pending producers?  This way users can implement whatever semantics they want (probably :wink:).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Fri Nov 22 12:58:41 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2019 17:58:41 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574445521.01.0.175558449672.issue38500@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@greg I hope this goes into 3.8.1 since it was a breaking change.

@victor if we are going to ask folks to start using a setter and getter I say we might as well get it right the first time and start taking the tstate now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:00:24 2019
From: report at bugs.python.org (Paul Moore)
Date: Fri, 22 Nov 2019 18:00:24 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574445624.2.0.255764960643.issue38021@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

What complicates the issue for AIX (and reminds me very strongly of the MacOS and manylinux situations, both of which were defined after the original tag PEP, and so contain additional insights) is the business of certain tags being compatible across multiple AIX versions.

That's something that needs to be fairly clearly specified, so that implementors and maintainers understand the design. And even more so for a niche platform like AIX, as we can't rely on a platform expert being available. (Consider for example a pip issue "this wheel says it's compatible with AIX x.y.z, my machine is AIX x.y.w which is documented as compatible, why isn't it working?")

It's possible that all of this may not have any relevance to the specific change to core Python, but it's hard to be sure of that when there's nothing other than your explanation to go on. A tagging spec would act as a clear reference to work from (even if it's basically just you writing up your knowledge, doing so would at least allow people to say "hey - I don't follow that bit, can you clarify").

To put it another way, you need somebody to sign off on this change as correct. You'll have an easier time of getting that if there's a written up spec that Python developers can refer to, without having to go back to (and understand) all of the AIX source material that it's based on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:06:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:06:23 +0000
Subject: [issue38818] Modify PyInterpreterState.eval_frame to pass tstate
 (PyThreadState)
In-Reply-To: <1573863093.89.0.126489580733.issue38818@roundup.psfhosted.org>
Message-ID: <1574445983.26.0.149850801838.issue38818@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16837
pull_request: https://github.com/python/cpython/pull/17352

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38818>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:06:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:06:23 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574445983.04.0.6257061978.issue38500@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16836
pull_request: https://github.com/python/cpython/pull/17352

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:07:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:07:36 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574446056.17.0.508234866232.issue38500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> @victor if we are going to ask folks to start using a setter and getter I say we might as well get it right the first time and start taking the tstate now.

Done: New PR 17352 combines my two other PRs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:24:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:24:59 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574447099.38.0.248942017723.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2582d46fbcf7bdf86b9cf4016850b8d155267ac6 by Victor Stinner in branch 'master':
bpo-38858: new_interpreter() reuses pycore_init_builtins() (GH-17351)
https://github.com/python/cpython/commit/2582d46fbcf7bdf86b9cf4016850b8d155267ac6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:29:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:29:58 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574447398.9.0.0562871815851.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16838
pull_request: https://github.com/python/cpython/pull/17353

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:41:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:41:13 +0000
Subject: [issue38896] Remove PyUnicode_ClearFreeList() function
Message-ID: <1574448073.52.0.15101589226.issue38896@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The PyUnicode_ClearFreeList() function does nothing since Python 3.3, since this change:

commit d63a3b8beb4a0841cb59fb3515347ccaab34b733
Author: Martin v. L?wis <martin at v.loewis.de>
Date:   Wed Sep 28 07:41:54 2011 +0200

    Implement PEP 393.

I propose attached PR to remove the function.

It seems like the function is part of the limited API and exported by PC/python3.def. But I don't see any usecase to explicitly clear the unicode freelist. Call gc.collect() to clear all free lists: no private API is needed.

----------
components: Interpreter Core
messages: 357312
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove PyUnicode_ClearFreeList() function
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38896>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:44:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:44:54 +0000
Subject: [issue38896] Remove PyUnicode_ClearFreeList() function
In-Reply-To: <1574448073.52.0.15101589226.issue38896@roundup.psfhosted.org>
Message-ID: <1574448294.13.0.0501089418003.issue38896@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also similar issue, bpo-37340 "Remove PyMethod_ClearFreeList() and PyCFunction_ClearFreeList() functions".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38896>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:45:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:45:00 +0000
Subject: [issue38896] Remove PyUnicode_ClearFreeList() function
In-Reply-To: <1574448073.52.0.15101589226.issue38896@roundup.psfhosted.org>
Message-ID: <1574448300.22.0.298404786004.issue38896@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38896>
_______________________________________

From report at bugs.python.org  Fri Nov 22 13:59:16 2019
From: report at bugs.python.org (David Coles)
Date: Fri, 22 Nov 2019 18:59:16 +0000
Subject: [issue38897] Example in socket documentation uses deprecated
 array.fromstring
Message-ID: <1574449156.01.0.686437832509.issue38897@roundup.psfhosted.org>


New submission from David Coles <coles.david at gmail.com>:

See the `recv_fds` example for `socket.recvmsg`.

This code produces a `DeprecationWarning` on current versions of Python.

https://docs.python.org/3.9/library/socket.html#socket.socket.recvmsg

----------
assignee: docs at python
components: Distutils, Documentation
messages: 357314
nosy: corona10, dcoles, docs at python, dstufft, eric.araujo
priority: normal
pull_requests: 16840
severity: normal
status: open
title: Example in socket documentation uses deprecated array.fromstring
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38897>
_______________________________________

From report at bugs.python.org  Fri Nov 22 14:19:56 2019
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 22 Nov 2019 19:19:56 +0000
Subject: [issue38868] Shutil cannot delete a folder that contains an .ini file
In-Reply-To: <1574280283.41.0.914167266294.issue38868@roundup.psfhosted.org>
Message-ID: <1574450396.94.0.375110971228.issue38868@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The directory probably has the "readonly" attribute set. The documentation includes a basic remove_readonly error handler for rmtree [1]:

    import os, stat
    import shutil
    
    def remove_readonly(func, path, _):
        "Clear the readonly bit and reattempt the removal"
        os.chmod(path, stat.S_IWRITE)
        func(path)

    shutil.rmtree(directory, onerror=remove_readonly)

That the readonly attribute prevents unlinking a directory is not particularly useful because a directory has to be empty anyway in order to unlink it. This is in contrast to the "immutable" file attribute in Linux, which prevents any modification of a directory, such as linking or unlinking files in it. Windows inherits its comparatively simplistic behavior for readonly directories from MS-DOS.

Since setting a directory as readonly is practically useless, the Windows shell reuses this attribute to indicate a customized folder [2]. If a directory is flagged readonly, the shell checks for and reads a "desktop.ini" file in it that can set a custom name, icon, tooltip, etc. Given you're copying a folder that contains a desktop.ini file, it's very likely that the readonly attribute is set. 

shutil.copytree will copy the readonly attribute to the destination directory via os.chmod. This is the only file attribute that gets copied (e.g. hidden and system aren't handled), due to a hack in the Windows CRT that conflates the readonly file attribute as a write 'permission' for chmod() and stat(). (Being readonly is an attribute of the file or directory, not a granted permission. os.access is the correct function to take both attributes and permissions into account, not os.stat.) Python inherits the CRT behavior in its own implementation of os.chmod and os.stat in Windows. It does so as an accident of history, not because it's justified.

[1] https://docs.python.org/3/library/shutil.html#rmtree-example
[2] https://docs.microsoft.com/en-us/windows/win32/shell/how-to-customize-folders-with-desktop-ini

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38868>
_______________________________________

From report at bugs.python.org  Fri Nov 22 14:41:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Nov 2019 19:41:35 +0000
Subject: [issue38882] IDLE should not make the about dialog be a transient of
 the withdrawn root window
In-Reply-To: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>
Message-ID: <1574451695.76.0.936739976096.issue38882@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ned, is our last Mac installer for 2.7 going to use tk 8.6.10?

I am extremely reluctant to touch IDLE for 2.7 since beginners are nearly all using 3.x and any mistakes are forever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Fri Nov 22 14:50:39 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Nov 2019 19:50:39 +0000
Subject: [issue38882] IDLE should not make the about dialog be a transient of
 the withdrawn root window
In-Reply-To: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>
Message-ID: <1574452239.5.0.579876349455.issue38882@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I still want to look at what happens on 3.x.

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Fri Nov 22 14:51:57 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 19:51:57 +0000
Subject: [issue38650] Add constantness to PyStructSequence_UnnamedField
In-Reply-To: <1572465703.12.0.701099038847.issue38650@roundup.psfhosted.org>
Message-ID: <1574452317.64.0.851547906349.issue38650@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I wouldn't worry about the c-analyzer stuff for now.  I plan on re-generating the file in the near future.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38650>
_______________________________________

From report at bugs.python.org  Fri Nov 22 15:02:23 2019
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 22 Nov 2019 20:02:23 +0000
Subject: [issue38855] test_unpack.py does not catch the unpacking of a set
In-Reply-To: <1574199866.94.0.505972513072.issue38855@roundup.psfhosted.org>
Message-ID: <1574452943.5.0.88273007358.issue38855@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Absent clarification from the OP (though it appears some may have been added to bpo-38853), I'm closing the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38855>
_______________________________________

From report at bugs.python.org  Fri Nov 22 15:39:37 2019
From: report at bugs.python.org (Marc Culler)
Date: Fri, 22 Nov 2019 20:39:37 +0000
Subject: [issue38882] IDLE should not make the about dialog be a transient of
 the withdrawn root window
In-Reply-To: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>
Message-ID: <1574455177.11.0.622158388618.issue38882@roundup.psfhosted.org>


Marc Culler <marc.culler at gmail.com> added the comment:

One thing to keep in mind is that Apple's release of OSX 10.14.6 caused
Tk 8.6.8 to stop working on many systems in an extremely obnoxious way.
Starting a Tk Application would trigger a segfault in Apple's WindowServer
which would then cause the user to be immediately logged out. That does
not happen with 8.6.10.  (Other types of applications were also affected.)

Here is one of many bug reports:
 https://github.com/matplotlib/matplotlib/issues/14999

Whether the crash would occur depended on which Apple hardware was used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Fri Nov 22 15:54:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 20:54:40 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1574456080.08.0.637082943993.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2ec1a1b307cc893adae4662a32e1d2e94b6908e3 by Victor Stinner in branch 'master':
bpo-38858: new_interpreter() uses pycore_init_import_warnings() (GH-17353)
https://github.com/python/cpython/commit/2ec1a1b307cc893adae4662a32e1d2e94b6908e3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Nov 22 15:58:55 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 22 Nov 2019 20:58:55 +0000
Subject: [issue38538] dictobject dictviews don't return NotImplemented for
 unrecognized types.
In-Reply-To: <1571585548.13.0.376831813762.issue38538@roundup.psfhosted.org>
Message-ID: <1574456335.55.0.898877963261.issue38538@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Let's start slowly by warning when a non-set is given to the __or__ of dictview?

I think it is just a side effect of the current implementation, not a feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38538>
_______________________________________

From report at bugs.python.org  Fri Nov 22 16:16:20 2019
From: report at bugs.python.org (zaza hohonini)
Date: Fri, 22 Nov 2019 21:16:20 +0000
Subject: [issue38898] Tkinter checkbutton switch on and off together
Message-ID: <1574457380.17.0.828287003226.issue38898@roundup.psfhosted.org>


New submission from zaza hohonini <zazahohonini at gmail.com>:

Hello,

I am running python 3.8.0 and found a problem where multiple checkbuttons get switched when I click one. From observing it looks like each first check button in a frame is linked. And each second, etc. I ran the some program in python 2.7.17 and it works as expected.

Basic program that show the problem:

import tkinter as tk

class Hello(tk.Frame):                     
    def __init__(self, parent=None):
        tk.Frame.__init__(self, parent)
        check = tk.Checkbutton(self, text='Checkbutton')
        check.pack()

root = tk.Tk()
Hello(root).pack()
Hello(root).pack()
root.mainloop()

----------
components: Tkinter
files: tkinter-checkbutton-bug.ogv
messages: 357323
nosy: zaza hohonini
priority: normal
severity: normal
status: open
title: Tkinter checkbutton switch on and off together
versions: Python 3.8
Added file: https://bugs.python.org/file48741/tkinter-checkbutton-bug.ogv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38898>
_______________________________________

From report at bugs.python.org  Fri Nov 22 16:26:20 2019
From: report at bugs.python.org (Sebastian Szwarc)
Date: Fri, 22 Nov 2019 21:26:20 +0000
Subject: [issue38889] Segmentation fault when using EPF Importer
In-Reply-To: <1574382167.79.0.251461203791.issue38889@roundup.psfhosted.org>
Message-ID: <CAM4yeEbh2_zT=d3M4LJ_+tWoxq_96WAKe7AZbpTq_=W-Z0R-zw@mail.gmail.com>


Sebastian Szwarc <seba.szwarc at gmail.com> added the comment:

I strongly disagree. Python 2.7 is 2.7 -> if some new errors appeared
after upgrading between minor version this is not expected behaviour,
and therefore it means there is error in interpreter itself.
upgrading from 2.7 to 2.7 is not the same as upgrading from swift 3 to swift 4.

And as I said in another comment - I dont understand your tendency to
"minimal example" - minimal example solves nothing because minimal !=
production.
On production there is of course 3rd party code - tool is written by
Apple and MysqlDB module by another 3rd party vendor. How can you even
expect to provide minimal example in such case?

Not to mention I got no errors in code - just SEGMENTATION FAULT which
indicates python interpreter after upgrade doing something very bad in
memory management ---> this is python issue.
Or give me solution to install specific version of 2.7 that was
available one year ago on Ubuntu.

On Fri, Nov 22, 2019 at 1:22 AM Eric V. Smith <report at bugs.python.org> wrote:
>
>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> I agree this doesn't look like a python bug.
>
> However, if the original poster can reproduce it with a short example with no third party code, we could take another look. If so, please re-open this issue.
>
> And just because the code worked on a different version of python doesn't mean there's no bug in the code. I've written plenty of code where errors were exposed in my code when updating python.
>
> ----------
> nosy: +eric.smith
> resolution:  -> third party
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38889>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38889>
_______________________________________

From report at bugs.python.org  Fri Nov 22 16:26:44 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Fri, 22 Nov 2019 21:26:44 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574458004.27.0.520306087096.issue38524@roundup.psfhosted.org>


Florian Dahlitz <f2dahlitz at freenet.de> added the comment:

It would be an honor for me to work on this issue (updating the docs) as my first CPython contribution.

----------
nosy: +DahlitzFlorian

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Fri Nov 22 16:38:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Nov 2019 21:38:13 +0000
Subject: [issue38840] incorrect __all__ list in multiprocessing.managers module
In-Reply-To: <1574115502.48.0.329816372934.issue38840@roundup.psfhosted.org>
Message-ID: <1574458693.77.0.971326176257.issue38840@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38840>
_______________________________________

From report at bugs.python.org  Fri Nov 22 16:54:48 2019
From: report at bugs.python.org (Bar Harel)
Date: Fri, 22 Nov 2019 21:54:48 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574418185.19.0.565088866029.issue38878@roundup.psfhosted.org>
Message-ID: <CAMsGuy=B39xeg_CQ7py3gzOKM1fieUu-LrWf45Bvwg_2eFaKww@mail.gmail.com>


Bar Harel <bzvi7919 at gmail.com> added the comment:

Done.

On Fri, Nov 22, 2019, 12:23 PM Bar Harel <report at bugs.python.org> wrote:

>
> Change by Bar Harel <bzvi7919 at gmail.com>:
>
>
> ----------
> keywords: +patch
> pull_requests: +16820
> stage: resolved -> patch review
> pull_request: https://github.com/python/cpython/pull/17336
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38878>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Fri Nov 22 17:00:29 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 22 Nov 2019 22:00:29 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574460029.67.0.497659538011.issue37334@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Fri Nov 22 17:09:18 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 Nov 2019 22:09:18 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574460558.7.0.266399411512.issue38804@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 0716056c49e9505041e30386dad9b2e788f67aaf by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157) (#17343)
https://github.com/python/cpython/commit/0716056c49e9505041e30386dad9b2e788f67aaf


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Fri Nov 22 17:21:47 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 22:21:47 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574461307.1.0.881765155327.issue36854@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks so much for getting this done, Victor!

> I'm not fully happy with this solution

Should we have an issue open for finding a better solution?  Are there risks with what you did that we don't want long-term?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 17:23:02 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Nov 2019 22:23:02 +0000
Subject: [issue17639] symlinking .py files creates unexpected sys.path
In-Reply-To: <1365154146.05.0.401345898234.issue17639@psf.upfronthosting.co.za>
Message-ID: <1574461382.98.0.611349902217.issue17639@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17639>
_______________________________________

From report at bugs.python.org  Fri Nov 22 17:23:33 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 22:23:33 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1574461413.72.0.500921619006.issue36854@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Did I mention that you're my hero? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Nov 22 17:28:27 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 22:28:27 +0000
Subject: [issue30060] Crash with subinterpreters and Py_NewInterpreter()
In-Reply-To: <1492020071.31.0.759008537591.issue30060@psf.upfronthosting.co.za>
Message-ID: <1574461707.08.0.460957546467.issue30060@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Victor's comment [1] on that related issue, implies that this may no longer be a problem (on 3.8).  Please check.  Thanks!


[1] https://bugs.python.org/issue17978#msg355166

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30060>
_______________________________________

From report at bugs.python.org  Fri Nov 22 17:55:35 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 22:55:35 +0000
Subject: [issue38865] Can Py_Finalize() be called if the current interpreter
 is not the main interpreter?
In-Reply-To: <1574264524.01.0.330569638863.issue38865@roundup.psfhosted.org>
Message-ID: <1574463335.92.0.321219112237.issue38865@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

tl;dr Py_Finalize() probably *should* only be allowed under the main interpreter.

As you know well, when the runtime starts we do it at first relative to a partially initialized main interpreter and the finish initialization with a fully operational main interpreter.  My expectation is that some of the global runtime state relies somehow on the main interpreter's state.  Consequently, finalization would then need to happen under the main interpreter.

The same idea applies to fork-without-exec, where we destroy all interpreters but the current one.  We now only allow os.fork() in the main interpreter.  So I'd expect the same treatement for finalization.

On the other hand, if the "main" interpreter isn't special after runtime init is done (i.e. a subinterpreter is effectively indistinguishable by nature) then it certainly would not matter which one finalizes (or is active during fork() for that matter).  On top of that, the effort we are making to identify the main interpreter (both in the code and in the docs) becomes unnecessary.

If we look at it from that angle, though, we do have cases where the main interpreter is still significant (regardless of the relationship between the main interpreter and the global runtime state).  At the very least, the main interpreter is solely responsible for some global resources, like signals.  So the main interpreter cannot go away until nothing else in the runtime relies on those resources.  I expect that we won't go down that route, which means finalization should happen only under the main interpreter.

Also keep in mind that this only matters relative to the C-API and I expect only embedders (not extensions) will be finalizing the runtime.  With PEP 554 the only case where you would run into problems is when running subinterpreters in daemon threads.  And we already know about problems with daemon threads during runtime finalization! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38865>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:04:39 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 23:04:39 +0000
Subject: [issue38865] Can Py_Finalize() be called if the current interpreter
 is not the main interpreter?
In-Reply-To: <1574264524.01.0.330569638863.issue38865@roundup.psfhosted.org>
Message-ID: <1574463879.36.0.658289694723.issue38865@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> * Is Python supposed to magically destroy the 3 interpreters?

Doesn't it?  Gah.  I guess I was thinking of PyOS_AfterFork_Child(), which calls _PyInterpreterState_DeleteExceptMain(). :/  In September there was a nice comment right above Py_FinalizeEx() saying that we do not clean up other interpreters or threads, but I haven't checked when it got removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38865>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:06:10 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 22 Nov 2019 23:06:10 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574463970.45.0.760713766732.issue38524@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Hi Florian! We'd be happy to have you do this, please go ahead.

When you have a PR ready, you're welcome to request my review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:06:05 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 23:06:05 +0000
Subject: [issue38865] Can Py_Finalize() be called if the current interpreter
 is not the main interpreter?
In-Reply-To: <1574264524.01.0.330569638863.issue38865@roundup.psfhosted.org>
Message-ID: <1574463965.25.0.821924648127.issue38865@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I could swear the topic of destroy-everything-in-PyFinalize has come up before but I don't remember anything specific.  Doing so there sure makes sense though...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38865>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:12:40 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 22 Nov 2019 23:12:40 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574464360.64.0.253167735664.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> This was reported by a partner that was working porting our code to Android but might be fixed current Android API levels. I cannot test this myself.

Thanks, it's helpful to be aware of potential incompatibilities either way. I don't think we directly support or test Android, based on https://buildbot.python.org/all/#/builders. There's some degree of _indirect_ support because Android kernels are based on Linux LTS kernels, but there are substantial differences.

> Fully agree, part of the reason why I was suggesting getting rid of reuse_address and reuse_port completely on this higher level API. 

> But I'm happy with Antoine's proposal which effectively kills the reuse_address parameter, just suggesting we also kill reuse_port as well.

Removing support for the *reuse_address* parameter can be justified with the security issue, but I don't think we have significant justification to also remove *reuse_port* in the same PR. In general, removing a parameter is not something taken lightly because of the backwards compatibility concerns. 

I think the argument for eventually deprecating *reuse_port* on the basis of it directly mapping to a low-level OS API could be worth further discussion, but that's a topic for an entirely separate issue IMO. If it is approved, it would have to go through the usual deprecation process, likely starting in 3.9 with a DeprecationWarning and a removal no sooner than 3.11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:13:39 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 22 Nov 2019 23:13:39 +0000
Subject: [issue38384] An assertion failure in test_pickle
In-Reply-To: <1570369149.47.0.841206648458.issue38384@roundup.psfhosted.org>
Message-ID: <1574464419.85.0.828476778171.issue38384@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Good catch on this, Zackery!

For anyone readying this, Serhit posted a minimal reproducer in a PR comment, and the PR now adds a test for this.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38384>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:13:54 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 22 Nov 2019 23:13:54 +0000
Subject: [issue38384] An assertion failure in test_pickle
In-Reply-To: <1570369149.47.0.841206648458.issue38384@roundup.psfhosted.org>
Message-ID: <1574464434.67.0.535039693068.issue38384@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Good catch on this, Zackery!

For anyone readying this, Serhiy posted a minimal reproducer in a PR comment, and the PR now adds a test for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38384>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:14:05 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 22 Nov 2019 23:14:05 +0000
Subject: [issue38384] An assertion failure in test_pickle
In-Reply-To: <1570369149.47.0.841206648458.issue38384@roundup.psfhosted.org>
Message-ID: <1574464445.66.0.739715137268.issue38384@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
Removed message: https://bugs.python.org/msg357336

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38384>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:18:00 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 22 Nov 2019 23:18:00 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574464680.93.0.186694107873.issue38686@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:19:19 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 22 Nov 2019 23:19:19 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574464759.22.0.382833641003.issue38686@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 14a89c47983f2fb9e7fdf33c769e622eefd3a14a by Senthil Kumaran (PypeBros) in branch 'master':
bpo-38686: fix HTTP Digest handling in request.py (#17045)
https://github.com/python/cpython/commit/14a89c47983f2fb9e7fdf33c769e622eefd3a14a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:19:20 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 23:19:20 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574464760.15.0.724308100655.issue38686@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16841
pull_request: https://github.com/python/cpython/pull/17357

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:19:25 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 23:19:25 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574464765.98.0.414590596496.issue38686@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16842
pull_request: https://github.com/python/cpython/pull/17358

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:20:10 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 22 Nov 2019 23:20:10 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574464810.0.0.578551033597.issue38686@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 3.9 -Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:20:15 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 22 Nov 2019 23:20:15 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574464815.74.0.283428254626.issue38686@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:36:41 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 23:36:41 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574465801.7.0.225452826684.issue38686@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b9e5547f5814962964c4a5bd5cd36a2af8fbf974 by Miss Islington (bot) in branch '3.8':
bpo-38686: fix HTTP Digest handling in request.py (GH-17045)
https://github.com/python/cpython/commit/b9e5547f5814962964c4a5bd5cd36a2af8fbf974


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:37:04 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Fri, 22 Nov 2019 23:37:04 +0000
Subject: [issue38721] modulefinder should use import hooks properly
In-Reply-To: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>
Message-ID: <1574465824.84.0.840553643225.issue38721@roundup.psfhosted.org>


Dominic Littlewood <11dlittlewood at gmail.com> added the comment:

In regards to the "unnecessary refactoring", here's a full list of what I've changed.

1. Previously, the module revolved around passing files and file descriptors around. Now, it uses specs. This means all the functions that used file descriptors have to be updated.

2. Due to the previous issue, several functions had to change their call signatures. The functions that called them had to change to react.

3. Packages work differently now. They do not have to have an __init__ submodule any more, so there's no need for a load_package function - it's integrated with load_module.

4. determine_parent was having trouble finding where the relative imports were relative to. I changed it to use _calc___package__, same as the import system. Half of determine_parent was deleted, because I couldn't understand how it worked and eventually worked out that there was literally no way it could ever run, so it didn't matter.

5. Modules with no __path__ attribute are not packages. Modules with a __path__ attribute of None *are* packages. Code had to be changed to reflect that. Looking back, this is possibly a pedantic enough point that these changes could be removed and hopefully nothing will go wrong.

6. fix_sys was used to update sys.path (although I have since changed it so it does not) and sys.modules. Code had to be changed to make use of it.

7. The only other thing I can think of is that I changed which modules were imported in the first few lines of modulefinder, since some had become unnecessary. (In fact types and warnings were already unnecessary, but never mind about that.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38721>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:37:41 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 22 Nov 2019 23:37:41 +0000
Subject: [issue38892] Audit Hook doc typos and confusion
In-Reply-To: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>
Message-ID: <1574465861.52.0.060948367136.issue38892@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks Terry, this is great!

Agree with everything apart from not liking "raise" - I think "raise an event" is totally fine usage, and certainly better than "triggers an audit call" (since it may not, if nobody's listening). Plus PEP 578 is full of "raise", and we're not going to go edit all of that :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38892>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:38:20 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2019 23:38:20 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574465900.65.0.615058423906.issue38878@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I just realized one problem with this is it explicitly requires subclassing the ABC while os.PathLike is supposed to represent a protocol (before typing.Protocol was a thing).

So why is it bad that in the example class B is considered a "subclass" of os.PathLike by implementing the protocol? Since it implements the expected protocol what exactly is being lost by not checking for an explicit registration or subclass?

----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:38:41 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Nov 2019 23:38:41 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574465921.78.0.467503120289.issue38686@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 07432c33a0cab9d40ec71b274ec4bca5c57ca6e9 by Miss Islington (bot) in branch '3.7':
bpo-38686: fix HTTP Digest handling in request.py (GH-17045)
https://github.com/python/cpython/commit/07432c33a0cab9d40ec71b274ec4bca5c57ca6e9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:41:40 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 Nov 2019 23:41:40 +0000
Subject: [issue38877] Python 3.9 build fails under Debian 9.11
In-Reply-To: <1574342929.28.0.219657775235.issue38877@roundup.psfhosted.org>
Message-ID: <1574466100.79.0.368802023295.issue38877@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Glad you got it working.  In general, it is probably a good idea to do a "make clean" before or after re-running ./configure in a particular build directory.   Ideally, the Makefile dependencies should detect and do the right thing automatically so that a manual "make clean" would not be necessary but, with as complicated a build system as we have, that goal might be unrealistic (PRs welcome though!). In any case adding something to the devguide steps would also be a good idea. Again, an issue and/or a PR against the devguide would be welcome (https://github.com/python/devguide).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38877>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:41:58 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 22 Nov 2019 23:41:58 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1574466118.11.0.818391457383.issue38686@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38686>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:49:58 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 22 Nov 2019 23:49:58 +0000
Subject: [issue38748] 32 bit ctypes stdcall callback fails to restore stack
 pointer
In-Reply-To: <1573232254.38.0.286098798289.issue38748@roundup.psfhosted.org>
Message-ID: <1574466598.98.0.875963974506.issue38748@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I would guess this is due to the updated libffi, and probably it's a case that is not sufficiently tested.

Adding tests is the first step. It'll probably have to enumerate many parameter types (in case there's something weird here like misaligning the double after the int and not clearing it up, as opposed to a constant 4-byte offset).

Hopefully then the issue is on our side and not part of libffi, but it could be anywhere.

----------
stage:  -> test needed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38748>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:56:40 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 23:56:40 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1574467000.22.0.0312653564635.issue37224@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:57:18 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2019 23:57:18 +0000
Subject: [issue38899] Document that virtual environment activation for fish
 should use `source`
Message-ID: <1574467038.96.0.0956850946026.issue38899@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

https://fishshell.com/docs/current/commands.html#source

----------
assignee: brett.cannon
components: Documentation
messages: 357346
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Document that virtual environment activation for fish should use `source`

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38899>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:57:36 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2019 23:57:36 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1574467056.48.0.709467268669.issue37224@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Sorry I haven't gotten back to you sooner, Kyle.  Thanks for working on this.  I'm looking at your PR right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Nov 22 18:59:57 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2019 23:59:57 +0000
Subject: [issue38899] Document that virtual environment activation for fish
 should use `source`
In-Reply-To: <1574467038.96.0.0956850946026.issue38899@roundup.psfhosted.org>
Message-ID: <1574467197.54.0.895669118911.issue38899@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38899>
_______________________________________

From report at bugs.python.org  Fri Nov 22 19:12:39 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Nov 2019 00:12:39 +0000
Subject: [issue38483] [venv] Add ~/.venvrc to change module defaults
In-Reply-To: <1571136700.53.0.3102397559.issue38483@roundup.psfhosted.org>
Message-ID: <1574467959.26.0.301777764394.issue38483@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Is this best served in the stdlib or in an external tool like how virtualenvwrapper is separate from virtualenv? While I get the convenience of not having to install another tool to do this, it does bring in some complexity that does not directly tie into the metadata required by venv to write out to pyvenv.cfg or the directories and files that it creates.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38483>
_______________________________________

From report at bugs.python.org  Fri Nov 22 19:17:20 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 23 Nov 2019 00:17:20 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1574468240.45.0.843143339135.issue37224@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

BTW, Kyle, your problem-solving approach on this is on-track.  Don't get discouraged.  This stuff is tricky. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Nov 22 19:30:36 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 23 Nov 2019 00:30:36 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1574469036.15.0.121608665969.issue37224@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thus far these are the failures we've seen:

* not running when we expect it to be running:
   * interpreters.is_running(interp)
   * interpreters.run_string(interp, ...)
   * interpreters.destroy(interp)
* can't find the interpreter even though we expect it to exist
   * interpreters.run_string(interp, ...)
* finds it running when we expect it to not be running
   * interpreters.run_string(interp, ...)

Except for the last one (which might be a separate issue), they all look like they could be explained by the same thing: the subinterpreter stopped (or went away) prematurely.  That could be related to the code in _xxsubinterpretersmodule.c or it could be the cleanup code that makes sure interpreters get cleaned up at the end of tests (e.g. running too soon).  Either way I expect the fix will be in the module code and not the tests.

Regarding "is_running()", notice that it relies almost entirely on "frame->f_executing".  That might not be enough (or maybe the behavior there changed).  That would be worth checking out.

@aeros, feel free too keep investigating.  I'd be glad to help you out.  Otherwise I'll dive into this probably next week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Nov 22 19:41:07 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 23 Nov 2019 00:41:07 +0000
Subject: [issue36876] Global C variables are a problem.
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1574469667.87.0.226954827127.issue36876@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks, Vinay!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Fri Nov 22 19:42:18 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 23 Nov 2019 00:42:18 +0000
Subject: [issue36876] Global C variables are a problem.
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1574469738.43.0.00862864187448.issue36876@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, others have been tackling this in separate issues (e.g. Victor, anyone relative to PEP 384).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Fri Nov 22 19:43:11 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 23 Nov 2019 00:43:11 +0000
Subject: [issue36876] Global C variables are a problem.
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1574469791.16.0.695347761502.issue36876@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

And I *am* still working on the c-analyzer + a test to that runs it, so we can keep from adding more globals. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Fri Nov 22 20:19:53 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 23 Nov 2019 01:19:53 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574471993.72.0.222342015059.issue38878@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> So why is it bad that in the example class B is considered a "subclass" of os.PathLike by implementing the protocol?

This is not bad, my understanding of the problem is that currently B is considered a subclass of A, while the latter should not be structural.

To give an analogy with PEP 544 (sorry, this is my favourite one :-)) consider this:

class P(Protocol):
    def some(self): ...

class C:
    def some(self): ...

Here C is obviously a "subclass" of P, but:

class Bad(P):  # <- this is _no_ a protocol, just a nominal class
    pass       # explicitly subclassing P

class Good(P, Protocol):  # <- this is a subprotocol that
    pass                  # happened to be identical to P

So here C is a "subclass" of Good, but not a "subclass" of Bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Fri Nov 22 20:30:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Nov 2019 01:30:52 +0000
Subject: [issue38896] Remove PyUnicode_ClearFreeList() function
In-Reply-To: <1574448073.52.0.15101589226.issue38896@roundup.psfhosted.org>
Message-ID: <1574472652.36.0.577107509967.issue38896@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d68b592dd67cb87c4fa862a8d3b3fd0a7d05e113 by Victor Stinner in branch 'master':
bpo-38896: Remove PyUnicode_ClearFreeList() function (GH-17354)
https://github.com/python/cpython/commit/d68b592dd67cb87c4fa862a8d3b3fd0a7d05e113


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38896>
_______________________________________

From report at bugs.python.org  Fri Nov 22 20:38:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Nov 2019 01:38:07 +0000
Subject: [issue38896] Remove PyUnicode_ClearFreeList() function
In-Reply-To: <1574448073.52.0.15101589226.issue38896@roundup.psfhosted.org>
Message-ID: <1574473087.44.0.157859235851.issue38896@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38896>
_______________________________________

From report at bugs.python.org  Fri Nov 22 20:39:00 2019
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 23 Nov 2019 01:39:00 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574473140.89.0.0228775262684.issue38878@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Just for reference/existing behavior:

>>> class A(collections.abc.Iterable): pass
...
>>> class B:
...   def __iter__(): pass
...
>>> issubclass(B, A)
False
>>> issubclass(B, collections.abc.Iterable)
True
>>> issubclass(A, collections.abc.Iterable)
True

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Fri Nov 22 21:07:22 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Nov 2019 02:07:22 +0000
Subject: [issue25872] multithreading traceback KeyError when modifying file
In-Reply-To: <1450200064.35.0.872448112145.issue25872@psf.upfronthosting.co.za>
Message-ID: <1574474842.14.0.480998105145.issue25872@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +16845
pull_request: https://github.com/python/cpython/pull/17360

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25872>
_______________________________________

From report at bugs.python.org  Fri Nov 22 21:20:43 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 23 Nov 2019 02:20:43 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574475643.22.0.0128402333882.issue38500@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
keywords: +3.8regression
nosy: +lukasz.langa
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Fri Nov 22 21:44:25 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Nov 2019 02:44:25 +0000
Subject: [issue38892] Audit Hook doc typos and confusion
In-Reply-To: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>
Message-ID: <1574477065.39.0.949630631325.issue38892@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree on consistency.  I will make a PR for you to review.

Do you think a minimal code example might help?  Running ...

import sys

def hook(name, args):
    if name.startswith('compile'):
        print(name, args)

sys.addaudithook(hook)
compile('a = 1', '<dummy>', 'exec')

# prints

compile (b'a = 1', '<dummy>')

My own interest is learning about the socket connecting an IDLE GUI process and the user code run process.  The following in the two startup files:

def hook(name, args):
    if name.startswith('socket'):
        print('I', name, args)  # I/R in the IDLE/run processes.
sys.addaudithook(hook)

results in:

I socket.gethostname ()
R socket.gethostname ()
I socket.bind (<socket.socket fd=796, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>, ('127.0.0.1', 0))
R socket.bind (<socket.socket fd=796, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>, ('127.0.0.1', 0))
R socket.connect (<socket.socket fd=816, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>, ('127.0.0.1', 62119))
I socket.__new__ (<socket.socket fd=-1, family=AddressFamily.AF_UNSPEC, type=0, proto=0>, 2, 1, 0)
R socket.__new__ (<socket.socket fd=-1, family=AddressFamily.AF_UNSPEC, type=0, proto=0>, 2, 1, 0)

To go further, I might wrap socket.socket.send/recv with functions that call sys.audit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38892>
_______________________________________

From report at bugs.python.org  Fri Nov 22 21:54:54 2019
From: report at bugs.python.org (Tim Peters)
Date: Sat, 23 Nov 2019 02:54:54 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574477694.64.0.412829222193.issue38881@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

There are a number of "obvious" properties that should obtain, given the intended meaning of weights:

- An input with weight 0 should never be returned.

- The distribution shouldn't be affected by adding a new input with weight 0.

- The distribution shouldn't be affected by removing an input with weight 0.

Especially because of the 3rd, the only sensible thing to do is to treat an input with weights all 0 much like an empty population - although, in context, ValueError would make more immediate sense for "all weights are 0" than the IndexError raised for an empty population.

Anything other than that is "too clever" by half, and I just don't believe would be of real use often enough to be worth violating the "obvious" properties above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Fri Nov 22 22:25:39 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 23 Nov 2019 03:25:39 +0000
Subject: [issue37073] clarify functions docs in IO modules and Bytes Objects
In-Reply-To: <1559027884.63.0.0963085588001.issue37073@roundup.psfhosted.org>
Message-ID: <1574479539.01.0.597857829709.issue37073@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> The function actually copies `len` bytes from string v instead of the whole string. 

"and length *len*" means it.  So it is not a bug.

If you want to rewrite it to "the first *len* bytes of", you should remove "and length *len*".

But please note that every small change will break translations.
Unless you are sure it is better than the current version, please don't change it.

> _bufferediobase_readinto_generic(link 2) which may return NULL.

It doesn't return NULL.  NULL in C means it raises the error.
And we don't document it usually.  Otherwise, almost all document has "it may raise an exception when an error happens."

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37073>
_______________________________________

From report at bugs.python.org  Fri Nov 22 22:25:51 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 23 Nov 2019 03:25:51 +0000
Subject: [issue37073] clarify functions docs in IO modules and Bytes Objects
In-Reply-To: <1559027884.63.0.0963085588001.issue37073@roundup.psfhosted.org>
Message-ID: <1574479551.55.0.316759379708.issue37073@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37073>
_______________________________________

From report at bugs.python.org  Fri Nov 22 22:27:52 2019
From: report at bugs.python.org (Cooper Lees)
Date: Sat, 23 Nov 2019 03:27:52 +0000
Subject: [issue38483] [venv] Add ~/.venvrc to change module defaults
In-Reply-To: <1571136700.53.0.3102397559.issue38483@roundup.psfhosted.org>
Message-ID: <1574479672.64.0.514859779623.issue38483@roundup.psfhosted.org>


Cooper Lees <me at cooperlees.com> added the comment:

I vote in the stdlib. This is the biggest win of venv over virtualenv The aim of this request is to allow developers to customize some of the venv defaults to make it easier to move from project to project.

To ensure a clean development environment, some days I create multiple venvs (virtual environments) a day. I treat my venv's ephemeral, and I am sure many other do too. Being able to set `--upgrade-deps` and/or other defaults via a config file just saves a few more key strokes and allows Python to be even more delightful to develop in over other languages.

In regards to you bringing up pyenv.cfg + metadata, this attacks a totally different problem. This is allowing developers to set some defaults for venv creation. It does not change any internal meta data and is just an optional optimization developers can choose to use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38483>
_______________________________________

From report at bugs.python.org  Fri Nov 22 22:29:04 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 23 Nov 2019 03:29:04 +0000
Subject: [issue38866] test_pyclbr replace asyncore
In-Reply-To: <1574270826.5.0.92652602871.issue38866@roundup.psfhosted.org>
Message-ID: <1574479744.97.0.24328259328.issue38866@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38866>
_______________________________________

From report at bugs.python.org  Fri Nov 22 22:35:57 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Nov 2019 03:35:57 +0000
Subject: [issue38892] Audit Hook doc typos and confusion
In-Reply-To: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>
Message-ID: <1574480157.88.0.685709664029.issue38892@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38892>
_______________________________________

From report at bugs.python.org  Fri Nov 22 23:06:54 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Nov 2019 04:06:54 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574482014.22.0.50834469659.issue38881@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Sat Nov 23 01:41:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Nov 2019 06:41:09 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574491269.79.0.577354280445.issue38878@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Sat Nov 23 01:46:39 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 23 Nov 2019 06:46:39 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1574491599.79.0.480341062841.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Sorry I haven't gotten back to you sooner, Kyle.  Thanks for working on this.  I'm looking at your PR right now.

> BTW, Kyle, your problem-solving approach on this is on-track.  Don't get discouraged.  This stuff is tricky. :)

No problem at all, and thank you for the words of encouragement. (:

> Regarding "is_running()", notice that it relies almost entirely on "frame->f_executing".  That might not be enough (or maybe the behavior there changed).  That would be worth checking out.

Hmm, that's an interesting point that I hadn't considered. 

> @aeros, feel free too keep investigating.  I'd be glad to help you out.  Otherwise I'll dive into this probably next week.

Sounds good, I'll do some further digging around, particularly anywhere that interacts with PyFrameObject's `f_executing` field. I think it's possible that there's a non-obvious issue with `_is_running()`, where it works correctly 99% of the time. That seems to be a significant commonality between the different areas where the intermittent failures are occurring, they all directly or indirectly call `_is_running()`.

Also, thanks again Eric for the PR review. Looking back it after Eric's analysis and having a couple of months to think it over, I don't think that GH-16293 is the correct solution. It seems unlikely that this is being caused by a lack of proper GIL acquisition, as that would likely be causing far more consistent build failures. I'm thinking that it's more likely to be an issue with either:

1) Subinterpreters occasionally disappearing due to premature cleanup (as Eric suggested)

2) _is_running() being incorrect a small percentage of the time

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Sat Nov 23 02:28:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Nov 2019 07:28:35 +0000
Subject: [issue38864] dbm: Can't open database with bytes-encoded filename
In-Reply-To: <1574262469.06.0.509781459017.issue38864@roundup.psfhosted.org>
Message-ID: <1574494115.21.0.24340032699.issue38864@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Low level functions inthe os module support both str and bytes paths (they support also path-like objects and often support open file descriptors). But high level functions support only str and maybe path-like objects. Use os.fsdecode if you need to convert  bytes path to str.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38864>
_______________________________________

From report at bugs.python.org  Sat Nov 23 02:32:39 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Nov 2019 07:32:39 +0000
Subject: [issue38899] Document that virtual environment activation for fish
 should use `source`
In-Reply-To: <1574467038.96.0.0956850946026.issue38899@roundup.psfhosted.org>
Message-ID: <1574494359.06.0.0608757124445.issue38899@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 84b1ff65609c5910b4f838adbe1ead83baae7dbf by Miss Islington (bot) (Brett Cannon) in branch 'master':
bpo-38899: virtual environment activation for fish should use `source` (GH-17359)
https://github.com/python/cpython/commit/84b1ff65609c5910b4f838adbe1ead83baae7dbf


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38899>
_______________________________________

From report at bugs.python.org  Sat Nov 23 02:58:49 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 23 Nov 2019 07:58:49 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1574495929.66.0.896643699652.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

So, I was finally able to replicate a failure in test_still_running locally, it required using a rather ridiculous number of parallel workers:

$ ./python -m test test__xxsubinterpreters -j200 -F
...
Exception in thread Thread-7:
Traceback (most recent call last):
  File "/home/aeros/repos/aeros-cpython/Lib/threading.py", line 944, in _bootstrap_inner
    self.run()
  File "/home/aeros/repos/aeros-cpython/Lib/threading.py", line 882, in run
    self._target(*self._args, **self._kwargs)
  File "/home/aeros/repos/aeros-cpython/Lib/test/test__xxsubinterpreters.py", line 51, in run
    interpreters.run_string(interp, dedent(f"""
RuntimeError: unrecognized interpreter ID 39
test test__xxsubinterpreters failed -- Traceback (most recent call last):
  File "/home/aeros/repos/aeros-cpython/Lib/test/test__xxsubinterpreters.py", line 766, in test_still_running
    interpreters.destroy(interp)
AssertionError: RuntimeError not raised
...
== Tests result: FAILURE ==

94 tests OK.

1 test failed:
    test__xxsubinterpreters

Total duration: 1 min 49 sec
Tests result: FAILURE

OS: Arch Linux x86_64
Kernel: 5.3.11
CPU: Intel i5-4460

I was able to consistently reproduce the above failure using 200 parallel workers, even without `-f`. 

I have a few different theories that I'd like to test for fixing the failure, I'll report back if any of them yield positive results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Sat Nov 23 03:01:39 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 23 Nov 2019 08:01:39 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1574496099.36.0.413650851013.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I was able to consistently reproduce the above failure using 200 parallel workers, even without `-f`. 

Oops, I didn't mean without passing `-F`, as this would result in only a single test being ran. I meant without letting it repeat multiple times, as in the test failure would consistently occur in the first batch of 200 parallel workers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Sat Nov 23 04:10:17 2019
From: report at bugs.python.org (Delgan)
Date: Sat, 23 Nov 2019 09:10:17 +0000
Subject: [issue38900] Add a glossary entry for "callable" objects
Message-ID: <1574500217.1.0.37004563113.issue38900@roundup.psfhosted.org>


New submission from Delgan <delgan.py at gmail.com>:

Hi.

Quick use case explanation about this: I would like to document my function, stating that it accepts any "callable" object and linking to a proper definition of such object.

For example, I'm already doing this when my function accepts a "file object". There exists no such type I can link to, so I link to the glossary definition: https://docs.python.org/3/glossary.html#term-file-object

I could link to the "callable()" built-in but than does not reflect well the expected *type* of the argument. For now, I define the argument as a "function" ( https://docs.python.org/3/glossary.html#term-function ) but this is too restrictive.

The definition for "callable" would be pretty straightforward, just mentioning it should implement "__call__", also linking to "emulating callable object" ( https://docs.python.org/3/reference/datamodel.html#emulating-callable-objects ) and / or the "callable()" builtin ( https://docs.python.org/3/library/functions.html#callable ).

----------
assignee: docs at python
components: Documentation
messages: 357366
nosy: Delgan, docs at python
priority: normal
severity: normal
status: open
title: Add a glossary entry for "callable" objects
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38900>
_______________________________________

From report at bugs.python.org  Sat Nov 23 04:29:43 2019
From: report at bugs.python.org (Bar Harel)
Date: Sat, 23 Nov 2019 09:29:43 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1574501383.81.0.503160973318.issue38878@roundup.psfhosted.org>


Bar Harel <bzvi7919 at gmail.com> added the comment:

A better example is this:

    class A(PathLike):
        def foo(self):
            """For all your foo needs"""

    class B:
        def __fspath__(self):
            pass

    issubclass(B, A) == True
    A().foo() # Yay, I Foo'd.
    B().foo() # oh barnacles, I should have stayed at home.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Sat Nov 23 04:32:53 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Nov 2019 09:32:53 +0000
Subject: [issue38900] Add a glossary entry for "callable" objects
In-Reply-To: <1574500217.1.0.37004563113.issue38900@roundup.psfhosted.org>
Message-ID: <1574501573.18.0.637247652823.issue38900@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1 I don't think this would be an improvement.  We already have a builtin callable() function documented, and we have the documented Callable() abstract base class, and the __call__ method is documented in the library reference.  I don't we need yet another entry describing a straight-forward concept.  Also I don't think we should litter the rest of docs with a link to a term-callable everytime we use the wordl.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38900>
_______________________________________

From report at bugs.python.org  Sat Nov 23 04:43:44 2019
From: report at bugs.python.org (Sebastian Szwarc)
Date: Sat, 23 Nov 2019 09:43:44 +0000
Subject: [issue38889] Segmentation fault when using EPF Importer
In-Reply-To: <CAM4yeEbh2_zT=d3M4LJ_+tWoxq_96WAKe7AZbpTq_=W-Z0R-zw@mail.gmail.com>
Message-ID: <CAM4yeEZp9iyHdAPgi3bF0KrVh59cejojWq6_H34NVghZwKoMvg@mail.gmail.com>


Sebastian Szwarc <seba.szwarc at gmail.com> added the comment:

If someone really want to test
The test procedure should be as follows:

Get the EPFImporter tool
https://affiliate.itunes.apple.com/resources/documentation/epfimporter/
Set up your database and put relevant login information in EPFConfig
Get the simple minimal dump from here -
https://drive.google.com/file/d/1s1VmE-7NGsUoiBjvBQ1iaalUjYSNPh9w/view?usp=sharing
try to import EPFImport.py full/*

these are only things I can provide at the moment,hope this helps
explaining a little more.

On Fri, Nov 22, 2019 at 10:26 PM Sebastian Szwarc
<report at bugs.python.org> wrote:
>
>
> Sebastian Szwarc <seba.szwarc at gmail.com> added the comment:
>
> I strongly disagree. Python 2.7 is 2.7 -> if some new errors appeared
> after upgrading between minor version this is not expected behaviour,
> and therefore it means there is error in interpreter itself.
> upgrading from 2.7 to 2.7 is not the same as upgrading from swift 3 to swift 4.
>
> And as I said in another comment - I dont understand your tendency to
> "minimal example" - minimal example solves nothing because minimal !=
> production.
> On production there is of course 3rd party code - tool is written by
> Apple and MysqlDB module by another 3rd party vendor. How can you even
> expect to provide minimal example in such case?
>
> Not to mention I got no errors in code - just SEGMENTATION FAULT which
> indicates python interpreter after upgrade doing something very bad in
> memory management ---> this is python issue.
> Or give me solution to install specific version of 2.7 that was
> available one year ago on Ubuntu.
>
> On Fri, Nov 22, 2019 at 1:22 AM Eric V. Smith <report at bugs.python.org> wrote:
> >
> >
> > Eric V. Smith <eric at trueblade.com> added the comment:
> >
> > I agree this doesn't look like a python bug.
> >
> > However, if the original poster can reproduce it with a short example with no third party code, we could take another look. If so, please re-open this issue.
> >
> > And just because the code worked on a different version of python doesn't mean there's no bug in the code. I've written plenty of code where errors were exposed in my code when updating python.
> >
> > ----------
> > nosy: +eric.smith
> > resolution:  -> third party
> > stage:  -> resolved
> > status: open -> closed
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <https://bugs.python.org/issue38889>
> > _______________________________________
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38889>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38889>
_______________________________________

From report at bugs.python.org  Sat Nov 23 04:56:18 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 23 Nov 2019 09:56:18 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574502978.66.0.433479323284.issue38881@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Either raising, or treating a zero-weight-sum as undefined behaviour and documenting that the sum of the weights should be positive sounds fine to me.

-1 on the suggestion to (deliberately, by documented design) choose at random in this case. Mathematically, this situation doesn't make sense: as Tim said, it's analogous to choosing from an empty population.

Ex: you have `nred` red balls and `nblue` blue balls in a bag. If you want to simulate drawing a single ball from the bag, then

   random.choices(["red", "blue"], [nred, nblue])

does the job. But in the case where `nred = nblue = 0`, the bag is empty and it's not possible to draw anything; in that case I'd expect an error. I definitely wouldn't expect to get either a red ball or a blue ball (with equal probability).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Sat Nov 23 05:10:40 2019
From: report at bugs.python.org (Delgan)
Date: Sat, 23 Nov 2019 10:10:40 +0000
Subject: [issue38900] Add a glossary entry for "callable" objects
In-Reply-To: <1574500217.1.0.37004563113.issue38900@roundup.psfhosted.org>
Message-ID: <1574503840.71.0.483844675416.issue38900@roundup.psfhosted.org>


Delgan <delgan.py at gmail.com> added the comment:

I agree, it's straightforward. I just thought it could be useful to have a proper definition in the official documentation.

For example, this question on StackOverflow actually received many views: https://stackoverflow.com/questions/111234/what-is-a-callable

What do you think is the best documentation entry I can link to while mentioning a "callable" type? Just the builtin "callable()"? The `collections.abc.Callable` is interesting but does not look very appropriate for basic functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38900>
_______________________________________

From report at bugs.python.org  Sat Nov 23 05:22:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Nov 2019 10:22:23 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574504543.2.0.138317757079.issue38881@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 041d8b48a2e59fa642b2c5124d78086baf74e339 by Raymond Hettinger in branch 'master':
bpo-38881: choices() raises ValueError when all weights are zero (GH-17362)
https://github.com/python/cpython/commit/041d8b48a2e59fa642b2c5124d78086baf74e339


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Sat Nov 23 05:23:11 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Nov 2019 10:23:11 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574504591.51.0.869298789102.issue38881@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the suggestions.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Sat Nov 23 05:42:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Nov 2019 10:42:23 +0000
Subject: [issue38900] Add a glossary entry for "callable" objects
In-Reply-To: <1574500217.1.0.37004563113.issue38900@roundup.psfhosted.org>
Message-ID: <1574505743.42.0.670954557012.issue38900@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I suggest linking to the built-in callable() function:  https://docs.python.org/3/library/functions.html#callable

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38900>
_______________________________________

From report at bugs.python.org  Sat Nov 23 06:03:34 2019
From: report at bugs.python.org (zaza hohonini)
Date: Sat, 23 Nov 2019 11:03:34 +0000
Subject: [issue38898] Tkinter checkbutton switch on and off together
In-Reply-To: <1574457380.17.0.828287003226.issue38898@roundup.psfhosted.org>
Message-ID: <1574507014.39.0.167871880755.issue38898@roundup.psfhosted.org>


zaza hohonini <zazahohonini at gmail.com> added the comment:

Hello,

I have done a bit of digging and found out that this behavior appeared in python version 3.6.0 alpha2. I think it is related to bpo-27025 
(https://bugs.python.org/issue27025) that changed the way that widgets are named. It is my impression that the code that determines which checkbutton should have its appearance changed has not been changed accordingly. 

I also observe that if I use variable=tk.IntVar() as additional argument to tk.Checkbutton, normal behavior is restored. This is the easiest work around.

----------
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38898>
_______________________________________

From report at bugs.python.org  Sat Nov 23 06:06:51 2019
From: report at bugs.python.org (Sanchit Khurana)
Date: Sat, 23 Nov 2019 11:06:51 +0000
Subject: [issue21063] Touch up one-line descriptions of modules for module
 index
In-Reply-To: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>
Message-ID: <1574507211.24.0.033316317311.issue21063@roundup.psfhosted.org>


Change by Sanchit Khurana <sanchitkhuranask at gmail.com>:


----------
pull_requests: +16848
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17363

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21063>
_______________________________________

From report at bugs.python.org  Sat Nov 23 07:06:43 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 23 Nov 2019 12:06:43 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574510803.58.0.372796438214.issue37334@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Lists of producers/consumers are just lists of future objects.

I don't think that we need to expose futures in high-level public API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Sat Nov 23 07:17:08 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 23 Nov 2019 12:17:08 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1574511428.22.0.682870117975.issue37228@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I support Antoine's proposal.
Let's remove the suspicious option if we cannot handle it correctly in a secured manner.
If people still want to use SO_REUSEADDR they can apply it manually, old good transp.get_extra_info("socket") is still available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Sat Nov 23 07:58:33 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 23 Nov 2019 12:58:33 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1574513913.72.0.151965328501.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> So, I was finally able to replicate a failure in test_still_running locally, it required using a rather ridiculous number of parallel workers

I forgot to mention that I was able to replicate the above failure on the latest commit to the 3.8 branch. I was _unable_ to replicate the failure on the latest commit to master, even when scaling up the number of parallel workers (the max I tested was 300 workers and ~3k iterations of test__xxsubinterpreters).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Sat Nov 23 08:38:15 2019
From: report at bugs.python.org (=?utf-8?q?Marcel_Zi=C4=99ba?=)
Date: Sat, 23 Nov 2019 13:38:15 +0000
Subject: [issue38895] performance degradation creating a mock object (by
 factor 7-8)
In-Reply-To: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>
Message-ID: <1574516295.93.0.19270105034.issue38895@roundup.psfhosted.org>


Marcel Zi?ba <marseel at gmail.com> added the comment:

I've also tested it and can confirm it.

Master branch:
raw times: 8.43 sec, 7.26 sec, 8.16 sec, 8.4 sec, 7.31 sec                                                                                                                                                                                                                                                                                                                                                                                                                                100000 loops, best of 5: 72.6 usec per loop

v3.8.0:
raw times: 13.6 sec, 11.9 sec, 11.6 sec, 11.7 sec, 12.3 sec                                                                                                                                                                                                                                                                                                                                                                                                                               100000 loops, best of 5: 116 usec per loop 

v3.7.4:
raw times: 2.55 sec, 1.9 sec, 2.7 sec, 2.42 sec, 2.17 sec                                                                                                                                                                                                                                                                                                                                                                                                                                 100000 loops, best of 5: 19 usec per loop

----------
nosy: +marseel
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Sat Nov 23 09:21:34 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Sat, 23 Nov 2019 14:21:34 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574518894.82.0.575520395361.issue38524@roundup.psfhosted.org>


Change by Florian Dahlitz <f2dahlitz at freenet.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Sat Nov 23 09:57:25 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Nov 2019 14:57:25 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574521045.66.0.958293446189.issue38021@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For folks that aren't aware, Michael and I have been discussing the AIX package tagging problem via email since his initial distutils-sig posts about it.

It's genuinely murky as fixing the AIX problem doesn't *technically* require any PEP 425 changes, as the main problem with the status quo is in the way the platform string is calculated, rather than in the way that then gets incorporated into a PEP 425 compatibility tag.

I think the subtlety I may not have cconveyed clearly though is that installers only do exact string matches on platform tags, working through a set of increasingly less specific candidates.

So if the goal is the same model that we use for Windows and Mac OS X, where the Python interpreter build defines the exact platform string that packages need to use, then all that's needed is the new platform string logic. That then places constraints on how AIX extension modules are built, but doesn't require a new PEP for installer logic changes. I think this is a good level of support to target.

There's then a further option that *would* require a new PEP: teaching installers to be more permissive in the compatibility tags they accept for AIX, based on the AIX ABI compatibility guidelines. I *don't* think that's a good idea - better to deal with that on the publication side, the way it is done for Windows and Mac OS X extensions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Sat Nov 23 10:57:13 2019
From: report at bugs.python.org (Martin Teichmann)
Date: Sat, 23 Nov 2019 15:57:13 +0000
Subject: [issue37334] Add a cancel method to asyncio Queues
In-Reply-To: <1560930108.51.0.0633177562649.issue37334@roundup.psfhosted.org>
Message-ID: <1574524633.98.0.528659452201.issue37334@roundup.psfhosted.org>


Martin Teichmann <martin.teichmann at gmail.com> added the comment:

I do not think that exposing the lists of futures does any good. I cannot come up with a semantics that could be implemented with that other than the one proposed.
Also I think that close() or cancel() is something a reader intuitively understands, while looping over a list of futures is not immediately obvious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37334>
_______________________________________

From report at bugs.python.org  Sat Nov 23 11:44:56 2019
From: report at bugs.python.org (Cooper Lees)
Date: Sat, 23 Nov 2019 16:44:56 +0000
Subject: [issue38483] [venv] Add ~/.venvrc to change module defaults
In-Reply-To: <1571136700.53.0.3102397559.issue38483@roundup.psfhosted.org>
Message-ID: <1574527496.42.0.230938542913.issue38483@roundup.psfhosted.org>


Change by Cooper Lees <me at cooperlees.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38483>
_______________________________________

From report at bugs.python.org  Sat Nov 23 12:51:21 2019
From: report at bugs.python.org (=?utf-8?q?Marcel_Zi=C4=99ba?=)
Date: Sat, 23 Nov 2019 17:51:21 +0000
Subject: [issue38895] performance degradation creating a mock object (by
 factor 7-8)
In-Reply-To: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>
Message-ID: <1574531481.11.0.48962566852.issue38895@roundup.psfhosted.org>


Marcel Zi?ba <marseel at gmail.com> added the comment:

This is the first commit I've observed slow down:

77b3b7701a34ecf6316469e05b79bb91de2addfa

Especially this part looks suspicious
https://github.com/python/cpython/commit/77b3b7701a34ecf6316469e05b79bb91de2addfa#diff-ff75b1b83c21770847ade91fa5bb2525R366

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Sat Nov 23 13:14:11 2019
From: report at bugs.python.org (Paul Moore)
Date: Sat, 23 Nov 2019 18:14:11 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574532851.19.0.71611883393.issue38021@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Thanks for the clarification, Nick. Yes, I agree that the basic "this is the tag that matches this precise CPython installation" is not the difficult part of the problem here, and if that is all that this issue is targeting, there should be no major problem.

My understanding was that Michael wanted to address the other part of the issue, that installers would somehow need to encapsulate the question of what binaries were compatible with what installations, and that, as you say, is a *much* murkier question.

If you're comfortable that the two aspects can be cleanly separated (and ideally that the second can be avoided altogether) then I'm much happier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Sat Nov 23 14:41:58 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 23 Nov 2019 19:41:58 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1574538118.67.0.251666994012.issue38871@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Dear core developers,

I 'd like to discuss fixing this issue.
IMHO, There are 2 options to fix this issue.

1. Add parenthesize when creating ListComp.
The change will be as follow:
             new = ListComp(results.get("fp").clone(),
                            results.get("fp").clone(),
                            results.get("it").clone(),
-                           results.get("xp").clone())
+                           parenthesize(results.get("xp").clone()))

But generated codes are not pretty.

2. Transform the lambda function as same as a normal function.
The only needed is removing lambda specific logics on fixer.

The generated code will be like this in this case.
x = filter(lambda x: True if x > 2 else False, data)
x = list(filter(lambda x: True if x > 2 else False, data))

Personally, I prefer the 2nd option because it's more clear.
If the proposal is accepted, I 'd like to fix this issue. 

If there are any ideas, please let me know.
Thank you always!

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Sat Nov 23 15:59:54 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Nov 2019 20:59:54 +0000
Subject: [issue38899] Document that virtual environment activation for fish
 should use `source`
In-Reply-To: <1574467038.96.0.0956850946026.issue38899@roundup.psfhosted.org>
Message-ID: <1574542794.13.0.710250261567.issue38899@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38899>
_______________________________________

From report at bugs.python.org  Sat Nov 23 17:28:34 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Nov 2019 22:28:34 +0000
Subject: [issue38901] Add a CLI flag to venv to use the pwd basename as the
 prompt
Message-ID: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

I did a Twitter poll to see if there was consistent naming of the directory people created a virtual environment into when done locally to code (the answer is no). But a common theme was people not liking that the prompt defaults to the name of the directory that the virtual environment is in and seem to prefer for it to be `os.path.basename(os.getcwd())`.

Maybe it makes sense to add a `--basename-prompt` flag to set the prompt to the current working directory's basename?

----------
components: Library (Lib)
messages: 357385
nosy: brett.cannon, vinay.sajip
priority: low
severity: normal
status: open
title: Add a CLI flag to venv to use the pwd basename as the prompt
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Sat Nov 23 17:33:02 2019
From: report at bugs.python.org (Lee Ball)
Date: Sat, 23 Nov 2019 22:33:02 +0000
Subject: [issue38902] image/webp support in mimetypes
Message-ID: <1574548382.26.0.67471558876.issue38902@roundup.psfhosted.org>


New submission from Lee Ball <lee.cat.ball at gmail.com>:

WebP is currently missing from the list of supported mimetypes.

It's an open source image format, using VP8 or VP8L for image data and RIFF for containers.

Previously, adding webp support was considered in 2011, but wasn't well supported at the time: ( https://bugs.python.org/issue11362 ). In 2019, WebP now enjoys support in major browsers and OSes. Its sister video format WebM was added to mimetypes in 2016 ( https://bugs.python.org/issue16329 ) and has similar support to WebP.

WebP homepage: https://developers.google.com/speed/webp
WebP source: https://chromium.googlesource.com/webm/libwebp/
RIFF container spec: https://developers.google.com/speed/webp/docs/riff_container
VP8 format spec: https://datatracker.ietf.org/doc/rfc6386/

----------
components: Library (Lib)
messages: 357386
nosy: leecatball
priority: normal
severity: normal
status: open
title: image/webp support in mimetypes
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38902>
_______________________________________

From report at bugs.python.org  Sat Nov 23 19:53:25 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 24 Nov 2019 00:53:25 +0000
Subject: [issue38903] #if 0 block on parsetok.c
Message-ID: <1574556805.21.0.874814643739.issue38903@roundup.psfhosted.org>


New submission from Emmanuel Arias <eamanu at yaerobi.com>:

Hi, 

I can see that on parsetok.c there is the next block:

```
#ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD
#if 0
static const char with_msg[] =
"%s:%d: Warning: 'with' will become a reserved keyword in Python 2.6\n";

static const char as_msg[] =
"%s:%d: Warning: 'as' will become a reserved keyword in Python 2.6\n";

static void
warn(const char *msg, const char *filename, int lineno)
{
    if (filename == NULL)
        filename = "<string>";
    PySys_WriteStderr(msg, filename, lineno);
}
#endif
#endif
```
I think that the #if 0 block can be remove safely, right?

I don't know if the #ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD we can remove.

----------
messages: 357387
nosy: eamanu
priority: normal
severity: normal
status: open
title: #if 0 block on parsetok.c
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38903>
_______________________________________

From report at bugs.python.org  Sat Nov 23 19:59:14 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 24 Nov 2019 00:59:14 +0000
Subject: [issue38903] #if 0 block on parsetok.c
In-Reply-To: <1574556805.21.0.874814643739.issue38903@roundup.psfhosted.org>
Message-ID: <1574557154.06.0.486082882655.issue38903@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38903>
_______________________________________

From report at bugs.python.org  Sat Nov 23 22:17:31 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Nov 2019 03:17:31 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574565451.26.0.257695909986.issue38862@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +16851
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/17366

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Sat Nov 23 22:27:20 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Nov 2019 03:27:20 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574566040.02.0.307373729591.issue38862@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

patchcheck.py removes even a single newline if that is all that remains after stripping each line.  So the revised rule is that a file should be either empty or end with a non-whitespace followed by a newline.  My intent is that a file be ready to merge to out github python/cpython repository.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Sat Nov 23 22:28:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Nov 2019 03:28:26 +0000
Subject: [issue36682] duplicate method definitions in
 Lib/test/test_sys_setprofile.py
In-Reply-To: <1555776500.63.0.359750321582.issue36682@roundup.psfhosted.org>
Message-ID: <1574566106.24.0.506307465275.issue36682@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +16852
pull_request: https://github.com/python/cpython/pull/17366

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36682>
_______________________________________

From report at bugs.python.org  Sat Nov 23 23:31:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Nov 2019 04:31:04 +0000
Subject: [issue38901] Add a CLI flag to venv to use the pwd basename as the
 prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1574569864.63.0.697769821153.issue38901@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Sun Nov 24 00:01:50 2019
From: report at bugs.python.org (Eli Schwartz)
Date: Sun, 24 Nov 2019 05:01:50 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1574571710.25.0.411205996616.issue2504@roundup.psfhosted.org>


Eli Schwartz <eschwartz93 at gmail.com> added the comment:

Interestingly enough, the final accepted patch (and the 2010 one) also fixes a bug where gettext.install(..., names='ngettext') would incorrectly work, in violation of the documentation.

I think it would also incorrectly install 'gettext', too...

It used to just check if names.__contains__ is a valid attribute, then check if 'foo' in names, so a dumb string "worked" and even matched more things than it should have.

How I discovered this: I fixed a bug in a python project that stopped working on python 3.8, and had a bit of a head-scratch regarding how it ever worked to begin with: https://github.com/linuxmint/cinnamon/pull/8964

----------
nosy: +eschwartz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sun Nov 24 01:06:20 2019
From: report at bugs.python.org (Richard Warfield)
Date: Sun, 24 Nov 2019 06:06:20 +0000
Subject: [issue38904] "signal only works in main thread" in main thread
Message-ID: <1574575580.88.0.320595380442.issue38904@roundup.psfhosted.org>


New submission from Richard Warfield <warfield at gmail.com>:

I have an application (https://github.com/litxio/ptghci) using embedded Python, which needs to set a signal handler (and use the prompt-toolkit library which itself sets signal handlers).

My call to signal.signal is guarded by a check that we're running in the main thread:

        if threading.current_thread() is threading.main_thread():
            print (threading.current_thread().name)
            signal.signal(signal.SIGINT, int_handler)

And the above indeed prints "MainThread".  But this raises an exception:

  File "app.py", line 45, in __init__
    signal.signal(signal.SIGINT, int_handler)
  File "/usr/lib/python3.8/signal.py", line 47, in signal
    handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
ValueError: signal only works in main thread

This seems like something that should not happen.  

Now, I tried to generate a simple replicating example but thus far haven't been able to do so -- simply calling signal.signal from PyRun_SimpleString doesn't do the trick, even within a pthreads thread.

----------
messages: 357390
nosy: Richard Warfield
priority: normal
severity: normal
status: open
title: "signal only works in main thread" in main thread
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38904>
_______________________________________

From report at bugs.python.org  Sun Nov 24 01:10:21 2019
From: report at bugs.python.org (Richard Warfield)
Date: Sun, 24 Nov 2019 06:10:21 +0000
Subject: [issue38904] "signal only works in main thread" in main thread
In-Reply-To: <1574575580.88.0.320595380442.issue38904@roundup.psfhosted.org>
Message-ID: <1574575821.46.0.92445797683.issue38904@roundup.psfhosted.org>


Richard Warfield <warfield at gmail.com> added the comment:

I should mention, this behavior is new in 3.8.0.  It did not occur in 3.7.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38904>
_______________________________________

From report at bugs.python.org  Sun Nov 24 03:17:40 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 24 Nov 2019 08:17:40 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
Message-ID: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

To reproduce:

> py -m venv fooenv
> fooenv\Scripts\activate.bat
(fooenv) > python -c "import sys; print(sys.executable)"  % This is correct
C:\Users\uranusjr\Downloads\venvtest\Scripts\python.exe
(fooenv) > python -q
>>> import subprocess
>>> subprocess.check_output(['python', '-c', 'import sys; print(sys.executable)'])
b'C:\\Users\\uranusjr\\AppData\\Local\\Programs\\Python\\Python37\\python.exe\r\n'

The output shows the base interpreter, not the interpreter in venv. Not sure whether this is a venv or subprocess problem.

----------
components: Library (Lib), Windows
messages: 357392
nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
priority: normal
severity: normal
status: open
title: venv python reports wrong sys.executable in a subprocess on Windows
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Sun Nov 24 03:36:19 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 24 Nov 2019 08:36:19 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574584579.47.0.715666193368.issue38905@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

Linux works correctly (Ubuntu with self-compiled Python 3.7.5)

$ python3.7 -m venv fooenv
$ . fooenv/bin/activate
(fooenv) $ python -c "import sys; print(sys.executable)"
/home/uranusjr/fooenv/bin/python
(fooenv) $ python -q
>>> import subprocess
>>> subprocess.check_output(['python', '-c', 'import sys; print(sys.executable)'])
b'/home/uranusjr/fooenv/bin/python\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Sun Nov 24 04:33:18 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 24 Nov 2019 09:33:18 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574587998.68.0.116854849557.issue38905@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

3.6 works correctly on Windows:

> py -3.6 -m venv test36
> test36\Scripts\activate.bat
>>> import subprocess
>>> print(subprocess.check_output(['python', '-c', 'import sys; print(sys.executable)']))
b'C:\\Users\\uranusjr\\Downloads\\test36\\Scripts\\python.exe\r\n'

So it seems the problem is introduced sometime after.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Sun Nov 24 05:42:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Nov 2019 10:42:55 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574592175.37.0.940466681673.issue38905@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Sun Nov 24 07:13:26 2019
From: report at bugs.python.org (Gregg Tavares)
Date: Sun, 24 Nov 2019 12:13:26 +0000
Subject: [issue38906] copy2 doesn't copy metadata on Windows and MacOS
Message-ID: <1574597606.02.0.586122584542.issue38906@roundup.psfhosted.org>


New submission from Gregg Tavares <github at greggman.com>:

MacOS have extended file attributes. Windows has both extended file attributes and alternate streams. In both OSes copy/cp and of course the Finder and Windows Explorer copy all this data. Python copy2 does not. 

On Windows it seems like CopyFileW needs to be called to actually do a full copy.

https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-copyfilew

On MacOS it appears to require copyItem

https://developer.apple.com/documentation/foundation/filemanager/1412957-copyitem

It's kind of unexpected to call a function to copy a file and have it not actually copy the file and have the user lose data

Windows example

> dir


    Directory: C:\Users\gregg\temp\test


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       11/24/2019   8:58 PM             28 original.txt


> Set-Content -Path original.txt -Stream FooBar

cmdlet Set-Content at command pipeline position 1
Supply values for the following parameters:
Value[0]: python should copy this too
Value[1]:

> Get-Content -Path original.txt -Stream FooBar
python should copy this too
> copy .\original.txt .\copied-with-copy.txt
> Get-Content -Path copied-with-copy.txt -Stream FooBar
python should copy this too
> C:\Users\gregg\AppData\Local\Programs\Python\Python38\python.exe
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2("original.txt", "copied-with-python3.txt")
>>> exit()
> Get-Content -Path copied-with-python3.txt -Stream FooBar
> Get-Content : Could not open the alternate data stream 'FooBar' of the file 'C:\Users\gregg\temp\test\copied-with-python3.txt'.
At line:1 char:1
+ Get-Content -Path copied-with-python3.txt -Stream FooBar
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : ObjectNotFound: (C:\Users\gregg\...ith-python3.txt:String) [Get-Content], FileNotFoundException
     + FullyQualifiedErrorId : GetContentReaderFileNotFoundError,Microsoft.PowerShell.Commands.GetContentCommand





MacOS example

$ ls -l -@
total 1120
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 original.jpg
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57 
$ cp original.jpg copied-with.cp 
$ ls -l -@                      
total 2240
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 copied-with.cp
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57 
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 original.jpg
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57
$python3
Python 3.8.0 (default, Nov 24 2019, 18:48:01) 
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2('original.jpg', 'copied-with-python3.jpg')
'copied-with-python3.jpg'
>>> exit()
$ ls -l -@
total 3360
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 copied-with-python3.jpg
	com.apple.quarantine	    57 
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 copied-with.cp
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57 
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 original.jpg
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57

----------
components: Library (Lib), Windows, macOS
messages: 357395
nosy: greggman, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: copy2 doesn't copy metadata on Windows and MacOS
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38906>
_______________________________________

From report at bugs.python.org  Sun Nov 24 08:06:26 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 24 Nov 2019 13:06:26 +0000
Subject: [issue38834] TypedDict: no way to tell which (if any) keys are
 optional at runtime
In-Reply-To: <1574038434.98.0.659515857103.issue38834@roundup.psfhosted.org>
Message-ID: <1574600786.7.0.873505010563.issue38834@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38834>
_______________________________________

From report at bugs.python.org  Sun Nov 24 08:18:20 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Sun, 24 Nov 2019 13:18:20 +0000
Subject: [issue37292] _xxsubinterpreters: Can't unpickle objects defined in
 __main__
In-Reply-To: <1560603991.54.0.788079404137.issue37292@roundup.psfhosted.org>
Message-ID: <1574601500.01.0.594347235973.issue37292@roundup.psfhosted.org>


Lewis Gaul <lewis.gaul at gmail.com> added the comment:

Just to move the conversation from the subinterpreters project repo to here...

I'm going to take a look at how this is done by subprocess using the example provided by Guido:

import os
from concurrent.futures import ProcessPoolExecutor
from multiprocessing import get_context

class C:
    def __getstate__(self):
        print("pickled in %d" % os.getpid())
        return {}

    def __setstate__(self, state):
        print("unpickled in %d" % os.getpid())

    def hello(self):
        print("Hello world")


if __name__ == "__main__":
    with ProcessPoolExecutor(mp_context=get_context("spawn")) as ex:
        ex.submit(C().hello).result()

Output:

pickled in 23480
unpickled in 23485
Hello world

----------
nosy: +LewisGaul

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37292>
_______________________________________

From report at bugs.python.org  Sun Nov 24 09:05:36 2019
From: report at bugs.python.org (AnLong)
Date: Sun, 24 Nov 2019 14:05:36 +0000
Subject: [issue27873] multiprocessing.pool.Pool.map should take more than one
 iterable
In-Reply-To: <1472253350.37.0.404019702525.issue27873@psf.upfronthosting.co.za>
Message-ID: <1574604336.81.0.351761456101.issue27873@roundup.psfhosted.org>


Change by AnLong <aisk1988 at gmail.com>:


----------
pull_requests: +16853
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17367

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27873>
_______________________________________

From report at bugs.python.org  Sun Nov 24 09:11:30 2019
From: report at bugs.python.org (lilydjwg)
Date: Sun, 24 Nov 2019 14:11:30 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1574604690.49.0.754520058389.issue37095@roundup.psfhosted.org>


Change by lilydjwg <lilydjwg at gmail.com>:


----------
nosy: +lilydjwg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Sun Nov 24 10:03:16 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Sun, 24 Nov 2019 15:03:16 +0000
Subject: [issue38901] Add a CLI flag to venv to use the pwd basename as the
 prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1574607796.64.0.513927425926.issue38901@roundup.psfhosted.org>


Change by Florian Dahlitz <f2dahlitz at freenet.de>:


----------
nosy: +DahlitzFlorian

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Sun Nov 24 10:36:38 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 24 Nov 2019 15:36:38 +0000
Subject: [issue37063] Incorrect application of func.__defaults__ by inspect's
 signature APIs
In-Reply-To: <1558954658.26.0.250057323757.issue37063@roundup.psfhosted.org>
Message-ID: <1574609798.71.0.00732923194883.issue37063@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

As mentioned in docs, getfullargspec is based on signature() and signature objects doesnt keep record of all defaults. It tries to map defaults with parameters but if you have less default then total parameter amount it will discard rest of defaults. IMHO this isn't a bug.

----------
nosy: +BTaskaya, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37063>
_______________________________________

From report at bugs.python.org  Sun Nov 24 10:49:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2019 15:49:27 +0000
Subject: [issue38804] Regular Expression Denial of Service in http.cookiejar
In-Reply-To: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>
Message-ID: <1574610567.1.0.435216641369.issue38804@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e6499033032d5b647e43a3b49da0c1c64b151743 by Victor Stinner in branch '2.7':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157) (GH-17345)
https://github.com/python/cpython/commit/e6499033032d5b647e43a3b49da0c1c64b151743


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38804>
_______________________________________

From report at bugs.python.org  Sun Nov 24 11:22:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 24 Nov 2019 16:22:20 +0000
Subject: [issue38446] Ambiguous signature for builtins.__build_class__
In-Reply-To: <1570793351.47.0.198943437011.issue38446@roundup.psfhosted.org>
Message-ID: <1574612540.35.0.962727600493.issue38446@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38446>
_______________________________________

From report at bugs.python.org  Sun Nov 24 12:04:10 2019
From: report at bugs.python.org (JIanqiu Tao)
Date: Sun, 24 Nov 2019 17:04:10 +0000
Subject: [issue38907] Add IPv6 Dual-Stack control for http.server
Message-ID: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>


New submission from JIanqiu Tao <zkonge at outlook.com>:

In Python 3.8+, when we run the http.server in a PC that support IPv6, it will bind IPv6 socket normally. On Linux or some other platforms, it also bind IPv4, that's pretty good, but on Windows, it doesn't work and "--bind 0.0.0.0" have to be provided to make it works in IPv4 environment.
In another case, once someone only want the http.server provide service in IPv6 environment, but linux will still bind IPv4 socket automatically.

Could we add a argument such as "--ipv6-only" for http.server and open the support of Dual-Stack socket by default?

----------
components: Library (Lib)
messages: 357399
nosy: zkonge
priority: normal
severity: normal
status: open
title: Add IPv6 Dual-Stack control for http.server
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38907>
_______________________________________

From report at bugs.python.org  Sun Nov 24 12:39:56 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 24 Nov 2019 17:39:56 +0000
Subject: [issue38908] Troubles with @runtime_checkable protocols
Message-ID: <1574617196.5.0.297633036854.issue38908@roundup.psfhosted.org>


New submission from Ivan Levkivskyi <levkivskyi at gmail.com>:

The PEP 544 specifies that:

A protocol can be used as a second argument in isinstance() and issubclass() only if it is explicitly opt-in by @runtime_checkable decorator.

It is not specified exactly whether this should be enforced by static type checkers or at runtime. Currently it is enforced in both cases: mypy flags this as error, and a TypeError is raised at runtime.

There is however a problem with current runtime implementation: abc and functools modules may call issubclass() on non-runtime checkable protocols if they appear as explicit superclasses. This is currently solved by a sys._getframe() hack in  typing module.

The problem is that current solution is incomplete. For example, the TypeError is not raised in the case of non-method protocols:

>>> class P(Protocol):
...     x: int
... 
>>> 
>>> class C: ...
... 
>>> isinstance(C(), P)
False  # should be TypeError

I tried to fix it this morning but after an hour of attempts to tweak the existing hack I gave up. It looks like there are only two reasonable solutions:

* Don't enforce @typing.runtime_checkable at runtime, make it a type-checker-only feature (like @typing.final).
* Add a little helper to abc module that would skip classes in MRO for which C._is_protocol is True but C._is_runtime_protocol is False.

Any thoughts/preferences?

----------
components: Library (Lib)
messages: 357400
nosy: gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Troubles with @runtime_checkable protocols
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38908>
_______________________________________

From report at bugs.python.org  Sun Nov 24 12:50:48 2019
From: report at bugs.python.org (JIanqiu Tao)
Date: Sun, 24 Nov 2019 17:50:48 +0000
Subject: [issue38907] Add IPv6 Dual-Stack control for http.server
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1574617848.19.0.19234977239.issue38907@roundup.psfhosted.org>


JIanqiu Tao <zkonge at outlook.com> added the comment:

"--no-dual-stack" seems to be a better argument name. "--ipv6-only" lead to ambiguity in a IPv4 only environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38907>
_______________________________________

From report at bugs.python.org  Sun Nov 24 12:55:26 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 24 Nov 2019 17:55:26 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1574618126.3.0.884069890515.issue38547@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This also happens when running the test suite with high parallelism:

./python -m test -j 20

This fails with:


== Tests result: FAILURE ==

398 tests OK.

2 tests failed:
    test_embed test_pty

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Sun Nov 24 12:58:03 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 24 Nov 2019 17:58:03 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1574618283.84.0.0442488740562.issue38547@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Indeed, almost all buildbots have to repeat the test_pty.

I think this needs to be fixed or process groups in regrtest should be limited or reverted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Sun Nov 24 12:58:51 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 24 Nov 2019 17:58:51 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1574618331.61.0.499980799075.issue38546@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ran 168 tests in 160.415s
OK (skipped=3)
Warning -- multiprocessing.process._dangling was modified by test_concurrent_futures
  Before: set()
  After:  {<weakref at 0x7fd136d66540; to 'ForkProcess' at 0x7fd136cd4a90>}

Another failure in AMD64 RHEL8 LTO + PGO 3.x

https://buildbot.python.org/all/#/builders/284/builds/300/steps/5/logs/stdio

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Sun Nov 24 13:00:52 2019
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Nov 2019 18:00:52 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1574618451.99.0.810208826886.issue38698@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

More tests are always good :)

The "correct" solution here (as far as I remember, its has been a while since I've had time to even looked at the _header_value_parser code) would be to add a new 'invalid-msg-id' token, and do this:

    message_id = MessageID()
    try:
        token, value = get_msg_id(value)
        message_id.append(token)
    except HeaderParseError as ex:
        message_id = InvalidMessageID(value)
        message_id.defects.append(InvalidHeaderDefect(
            f"Invalid msg_id: {ex}"))
    return message_id

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38698>
_______________________________________

From report at bugs.python.org  Sun Nov 24 13:06:42 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 24 Nov 2019 18:06:42 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574618802.69.0.354180949832.issue38524@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Sun Nov 24 13:34:02 2019
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Nov 2019 18:34:02 +0000
Subject: [issue38672] mimetypes.init() fails if no access to one of known files
In-Reply-To: <1572784402.07.0.839086408394.issue38672@roundup.psfhosted.org>
Message-ID: <1574620442.35.0.566417371273.issue38672@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I haven't looked at this in detail, but here are my general thoughts: I think it would be reasonable to expect that the module would function even if the file permissions are screwed up, similar to how unix commands that try to read .netrc will (try to) function even if its permissions are wrong.  I would, however, expect the module to emit a warning in that case.  I'm of two minds about the behavior when the caller specifies filenames explicitly.  I could see that going either way, but I lean slightly toward making the behavior consistent.  While the programmer might appreciate the traceback, the user of the program would probably appreciate the "try to keep going" behavior, since the filenames provided will often be in the same class of "standard defaults" as the existing well known files are, just in the context of that particular application.  But like I said, that is just a lean, and I could go the other way on this as well :)

I haven't looked at the isflie issue, but it seems reasonable that if the path exists we should make sure it is a file before reading it...but perhaps readfp will effectively do that?  Write a test and see what happens :)

I don't know whether to call this change a bug fix or a feature, so I guess we'd default to feature unless someone can tilt the balance with an argument :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38672>
_______________________________________

From report at bugs.python.org  Sun Nov 24 13:47:58 2019
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Nov 2019 18:47:58 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1574621278.92.0.940098672099.issue38698@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually, the success path there should also check that value is empty, and if it is not register a defect for that as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38698>
_______________________________________

From report at bugs.python.org  Sun Nov 24 14:15:11 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Nov 2019 19:15:11 +0000
Subject: [issue38876] pickle is raising KeyError insteat of
 pickle.UnpicklingError under certain conditions
In-Reply-To: <1574335379.18.0.441188503497.issue38876@roundup.psfhosted.org>
Message-ID: <1574622911.6.0.76251060415.issue38876@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6f03b236c17c96bc9f8a004ffa7e7ae0542e9cac by Miss Islington (bot) (Claudiu Popa) in branch 'master':
bpo-38876: Raise pickle.UnpicklingError when loading an item from memo for invalid input (GH-17335)
https://github.com/python/cpython/commit/6f03b236c17c96bc9f8a004ffa7e7ae0542e9cac


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38876>
_______________________________________

From report at bugs.python.org  Sun Nov 24 14:22:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Nov 2019 19:22:54 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574623374.05.0.544172943663.issue38862@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Currently, iomenu.IOBinding.fixnewlines makes sure that when a non-empty non-Shell file is saved (and possibly run), it ends with at least 1 newline.  At one time, I believe, compile needed this, and it is still good practice.  (Git diffs note the absence of a final newline.)

I originally planned to incorporate possible newline addition into do_rstrip, in anticipation of calling do_rstrip on save, but I have changed my mind, at least for the present.  That code can stay where it is.  If someone explicitly runs Strip Trailing Whitespace, adding a newline would sometimes be desired, but would sometimes be unexpected and possibly a nuisance.  do_rstrip will ensure that non-Shell files end with at most 1 newline.

My revised intent is that once we strip on save, saved files should be  properly formatted for use or merging into a repository.

----------
nosy: +rhettinger, taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Sun Nov 24 14:54:43 2019
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Nov 2019 19:54:43 +0000
Subject: [issue38625] SpooledTemporaryFile does not seek correctly after being
 rolled over
In-Reply-To: <1572306406.72.0.0542092082155.issue38625@roundup.psfhosted.org>
Message-ID: <1574625283.9.0.723892104662.issue38625@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The docs currently say "The returned object is a file-like object whose _file attribute is either an io.BytesIO or io.StringIO object (depending on whether binary or text mode was specified) or a true file object, depending on whether rollover() has been called."  The fact that taking an iterator gets you whatever the *current* _file object is is implied by that but not made explicit.  A doc update to make that explicit would probably be appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38625>
_______________________________________

From report at bugs.python.org  Sun Nov 24 15:25:58 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 24 Nov 2019 20:25:58 +0000
Subject: [issue38906] copy2 doesn't copy metadata on Windows and MacOS
In-Reply-To: <1574597606.02.0.586122584542.issue38906@roundup.psfhosted.org>
Message-ID: <1574627158.02.0.61490434902.issue38906@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

In Windows, using CopyFileExW and CreateDirectoryExW (with a template directory, for copytree) doesn't agree with how shutil implements copying with separate copyfile and copymode/copystat functions. We'd have to extend copyfile() to support alternate data streams, and we'd have to extend copystat() to support file attributes, extended attributes, and security-resource attributes. Or we'd have to abandon consistency between copy2 and copyfile+copystat.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38906>
_______________________________________

From report at bugs.python.org  Sun Nov 24 15:27:58 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 24 Nov 2019 20:27:58 +0000
Subject: [issue38906] copy2 doesn't copy metadata on Windows and MacOS
In-Reply-To: <1574597606.02.0.586122584542.issue38906@roundup.psfhosted.org>
Message-ID: <1574627278.93.0.134950518863.issue38906@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38906>
_______________________________________

From report at bugs.python.org  Sun Nov 24 15:44:00 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 24 Nov 2019 20:44:00 +0000
Subject: [issue38603] inspect.getdoc could examine the __class__ cell for
 dynamically generated subclasses
In-Reply-To: <1572189874.33.0.728183278975.issue38603@roundup.psfhosted.org>
Message-ID: <1574628240.35.0.940303790254.issue38603@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38603>
_______________________________________

From report at bugs.python.org  Sun Nov 24 15:45:53 2019
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 24 Nov 2019 20:45:53 +0000
Subject: [issue38876] pickle is raising KeyError insteat of
 pickle.UnpicklingError under certain conditions
In-Reply-To: <1574335379.18.0.441188503497.issue38876@roundup.psfhosted.org>
Message-ID: <1574628353.16.0.678654956569.issue38876@roundup.psfhosted.org>


Change by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
assignee:  -> alexandre.vassalotti
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38876>
_______________________________________

From report at bugs.python.org  Sun Nov 24 16:29:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Nov 2019 21:29:32 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574630972.9.0.865667533937.issue38862@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 6bf644ec82f14cceae68278dc35bafb00875efae by Terry Jan Reedy in branch 'master':
 bpo-38862: IDLE Strip Trailing Whitespace fixes end newlines  (GH-17366)
https://github.com/python/cpython/commit/6bf644ec82f14cceae68278dc35bafb00875efae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Sun Nov 24 16:29:52 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Nov 2019 21:29:52 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574630992.39.0.663654650624.issue38862@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16854
pull_request: https://github.com/python/cpython/pull/17370

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Sun Nov 24 16:29:58 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Nov 2019 21:29:58 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574630998.93.0.626020193179.issue38862@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16855
pull_request: https://github.com/python/cpython/pull/17371

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Sun Nov 24 16:45:44 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Sun, 24 Nov 2019 21:45:44 +0000
Subject: [issue37292] _xxsubinterpreters: Can't unpickle objects defined in
 __main__
In-Reply-To: <1560603991.54.0.788079404137.issue37292@roundup.psfhosted.org>
Message-ID: <1574631944.38.0.371135788346.issue37292@roundup.psfhosted.org>


Lewis Gaul <lewis.gaul at gmail.com> added the comment:

The relevant code for the multiprocessing example seems to be in Lib/multiprocessing/spawn.py. I think I get what it's doing, but I'm not sure whether we actually need something similar for subinterpreters. Any thoughts @eric.snow?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37292>
_______________________________________

From report at bugs.python.org  Sun Nov 24 17:16:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2019 22:16:04 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1574633764.22.0.598222675863.issue38547@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I think this needs to be fixed or process groups in regrtest should be limited or reverted.

What do you mean by "limited"?

Process groups really help to prevent to leak grandchild processes in multiprocessing tests, when tests are interrupted manually by CTRL+C or by a timeout (sadly, only when the timeout is handled by regrtest, not when it's handled by faulthandler).

See bpo-38502 for the rationale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Sun Nov 24 17:46:50 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 24 Nov 2019 22:46:50 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1574635610.85.0.231128177283.issue38547@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> What do you mean by "limited"?

I mean to deactivate it by default and make opt-in.

> Process groups really help to prevent to leak grandchild processes in multiprocessing tests, when tests are interrupted manually by CTRL+C or by a timeout (sadly, only when the timeout is handled by regrtest, not when it's handled by faulthandler).

I love process groups and they are awesome. But having these test being re-run on every buildbot and failing on my machine when just running test with -j is very annoying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Sun Nov 24 17:50:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2019 22:50:43 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1574635843.36.0.0484281451608.issue38547@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Can't we fix test_pty?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Sun Nov 24 18:02:46 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 24 Nov 2019 23:02:46 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574636566.34.0.179034710259.issue38870@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 27fc3b6f3fc49a36d3f962caac5c5495696d12ed by Pablo Galindo in branch 'master':
bpo-38870: Expose a function to unparse an ast object in the ast module (GH-17302)
https://github.com/python/cpython/commit/27fc3b6f3fc49a36d3f962caac5c5495696d12ed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Sun Nov 24 18:19:08 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 24 Nov 2019 23:19:08 +0000
Subject: [issue38901] Add a CLI flag to venv to use the pwd basename as the
 prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1574637548.16.0.93909037485.issue38901@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Maybe it makes sense to add a `--basename-prompt` flag to set the prompt to the current working directory's basename?

What does this buy you beyond using

--prompt $(basename $PWD)

? Perhaps I'm not understanding what you're getting at - how about an example of what you mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Sun Nov 24 18:27:30 2019
From: report at bugs.python.org (David Bolen)
Date: Sun, 24 Nov 2019 23:27:30 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1574638050.71.0.688044003409.issue38547@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

I think fixing the underlying pty issue should certainly be the goal, but the question is whether the process group change should remain active in the meantime, as its presence is causing a regression in the tests.  I think such cases in the past are usually rolled back, right?

I was originally on the fence since process groups address a real problem, especially in interactive testing, while creating an arguably aesthetic issue for my case of the buildbots (a warning rather than failure).

But Pablo's point about a normal manual full test run failing (not a warning as with the buildbots) feels persuasive since that's probably as common as the issue being addressed by the change.  Even if pre-existing, the pty failure is exposed by the process group change, so it might be best for the process group change to wait on fixing the pty issue.

I don't know how to weigh the relative impact though, e.g,. how many people are likely to run into each failure case.  There's probably more people doing a normal test run than breaking out of such tests though.  At the least, it's a worst impact than just the warnings on the buildbots.

Perhaps an intermediate fallback could be gating the process group change behind a regrtest option (opt-in) which could then preserve its benefits upon request, without negatively impacting the default test process, whether manual or on the buildbots.

At least until resource is available to resolve the pty issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Sun Nov 24 18:45:49 2019
From: report at bugs.python.org (Julien Palard)
Date: Sun, 24 Nov 2019 23:45:49 +0000
Subject: [issue38901] Add a CLI flag to venv to use the pwd basename as the
 prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1574639149.39.0.253941274161.issue38901@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

I like the idea and I think I will use it!

As it's a bit long to type, I'm searching if other shorter variants could be usefull like:

    python3 -m venv --here
    python3 -m venv --cwd
    python3 -m venv --project

being the equivalent of `python3 -m venv --basename-prompt venv`, but I'm not satisfied with the names (and it enforces using "venv" as a directory name)...

----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Sun Nov 24 19:35:55 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 25 Nov 2019 00:35:55 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574642155.33.0.671802720441.issue38905@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Your failing test case with 3.7 works for me.

If you don't use activate.bat, but just run the venv's python directly, what do you see? I get:

>py -m venv fooenv

>fooenv\Scripts\python -V
Python 3.7.0

>fooenv\Scripts\python -q
>>> import subprocess
>>> subprocess.check_output(['python', '-c', 'import sys; print(sys.executable)'])
b'C:\\Users\\XXXXXXX\\fooenv\\Scripts\\python.exe\r\n'

What shell are you using? Above is with cmd.exe.

If you "echo %PATH%" after activate.bat, what do you see?

Before running activate.bat, do you have a python.exe in your path? If so, is it the one that subprocess is reporting?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Sun Nov 24 20:04:39 2019
From: report at bugs.python.org (Jon Nalley)
Date: Mon, 25 Nov 2019 01:04:39 +0000
Subject: [issue38861] zipfile: Corrupts filenames containing non-UTF8
 characters
In-Reply-To: <1574218342.23.0.381286067182.issue38861@roundup.psfhosted.org>
Message-ID: <1574643879.72.0.376182666927.issue38861@roundup.psfhosted.org>


Jon Nalley <code at bluebot.org> added the comment:

I think the Python implementation is adhering to the zip specification.

>From the specification v6.3.6 (Revised: April 26, 2019):

If general purpose bit 11 is unset, the file name and comment SHOULD conform 
to the original ZIP character encoding.  If general purpose bit 11 is set, the 
filename and comment MUST support The Unicode Standard, Version 4.1.0 or 
greater using the character encoding form defined by the UTF-8 storage 
specification.

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

----------
nosy: +jnalley

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38861>
_______________________________________

From report at bugs.python.org  Sun Nov 24 21:37:27 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 25 Nov 2019 02:37:27 +0000
Subject: [issue38625] SpooledTemporaryFile does not seek correctly after being
 rolled over
In-Reply-To: <1572306406.72.0.0542092082155.issue38625@roundup.psfhosted.org>
Message-ID: <1574649447.62.0.52476229188.issue38625@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

SpooledTemporaryFile has very serious bug which causes data corruption (#26730).  Please don't use it with text mode until it is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38625>
_______________________________________

From report at bugs.python.org  Sun Nov 24 22:01:14 2019
From: report at bugs.python.org (John Goerzen)
Date: Mon, 25 Nov 2019 03:01:14 +0000
Subject: [issue38861] zipfile: Corrupts filenames containing non-UTF8
 characters
In-Reply-To: <1574218342.23.0.381286067182.issue38861@roundup.psfhosted.org>
Message-ID: <1574650874.24.0.642584489474.issue38861@roundup.psfhosted.org>


John Goerzen <jgoerzen at users.sourceforge.net> added the comment:

I can tell you that the zip(1) on Unix systems has never done re-encoding to cp437; on a system that uses latin-1 (or any other latin-* for that matter) the filenames in the ZIP will be encoded in latin-1.  Furthermore, this doesn't explain the corruption that extractall() causes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38861>
_______________________________________

From report at bugs.python.org  Sun Nov 24 23:58:28 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 25 Nov 2019 04:58:28 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574657908.08.0.093285664656.issue38905@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

> If you don't use activate.bat, but just run the venv's python directly, what do you see? I get:
> What shell are you using? Above is with cmd.exe.

I get the same result as activating (i.e. shows the base interpeter). All results in cmd.exe as well.

> If you "echo %PATH%" after activate.bat, what do you see?
> Before running activate.bat, do you have a python.exe in your path? If so, is it the one that subprocess is reporting?

PATH is as expected, the venv?s Scripts directory at the front after activation. I (only) have a python.exe from Windows Store in PATH. The one reported by subprocess is not in PATH.

I?ll try to find a clean machine (maybe a VM) and try whether I can replicate this. BTW the problematic versions for me was 3.7.5 and 3.8.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 01:31:37 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 25 Nov 2019 06:31:37 +0000
Subject: [issue38803] test_wait3 and test_wait4 leaked references on x86
 Gentoo Refleaks 3.x
In-Reply-To: <1573771592.29.0.825228162147.issue38803@roundup.psfhosted.org>
Message-ID: <1574663497.78.0.892390606947.issue38803@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38803>
_______________________________________

From report at bugs.python.org  Mon Nov 25 01:33:41 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 25 Nov 2019 06:33:41 +0000
Subject: [issue38803] test_wait3 and test_wait4 leaked references on x86
 Gentoo Refleaks 3.x
In-Reply-To: <1573771592.29.0.825228162147.issue38803@roundup.psfhosted.org>
Message-ID: <1574663621.09.0.964091113576.issue38803@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

Victor, the PR with the fix is out. Easy catch after running it with my leak detector!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38803>
_______________________________________

From report at bugs.python.org  Mon Nov 25 01:34:13 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 25 Nov 2019 06:34:13 +0000
Subject: [issue35381] posixmodule: convert statically allocated types
 (DirEntryType & ScandirIteratorType) to heap-allocated types
In-Reply-To: <1543818839.39.0.788709270274.issue35381@psf.upfronthosting.co.za>
Message-ID: <1574663653.6.0.285983591247.issue35381@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

PR with fix is out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35381>
_______________________________________

From report at bugs.python.org  Mon Nov 25 01:45:47 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Mon, 25 Nov 2019 06:45:47 +0000
Subject: [issue37095] [Feature Request]: Add zstd support in tarfile
In-Reply-To: <1559187768.11.0.7498103877.issue37095@roundup.psfhosted.org>
Message-ID: <1574664347.94.0.517245277167.issue37095@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37095>
_______________________________________

From report at bugs.python.org  Mon Nov 25 03:05:25 2019
From: report at bugs.python.org (Paul Moore)
Date: Mon, 25 Nov 2019 08:05:25 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574669125.62.0.120563484481.issue38905@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

The behaviour in this area is different between 3.7.0, 3.7.2, and 3.7.3 (at least). I have reproduced the issue with 3.7.3. Steve Dower made changes to the way the python executable works in venvs in the point releases of 3.7 - see https://github.com/pypa/virtualenv/issues/1380 and https://github.com/pypa/virtualenv/issues/1339 for some discussion of how this affected virtualenv.

I suspect this issue is related - from 3.7.2 onwards, the python.exe in a venv is a redirector which runs the "base" python.exe, but with sys.executable showing the redirector rather than the actual running exe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 03:09:36 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 25 Nov 2019 08:09:36 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574669376.5.0.436134924126.issue38905@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

I tested the following in various versions (all 64-bit) in a VM. All installations are 64-bit per-user.

> py -m venv testenv
> testenv\Scripts\python.exe -c "import subprocess; print(subprocess.check_output(['python', '-c', 'import sys; print(sys.executable)']))"

3.8.0: Incorrect
3.7.5: Incorrect
3.7.4: Incorrect
3.7.3: Incorrect
3.7.2: Correct
3.6.8: Correct
3.7.1: Correct
3.7.0: Correct

So the change seems to have happened somewhere between 3.7.2 and 3.7.3. Does this timeline line up with the venv redirector change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 03:21:15 2019
From: report at bugs.python.org (Paul Moore)
Date: Mon, 25 Nov 2019 08:21:15 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574670075.41.0.3240226148.issue38905@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Yes, it does.

I think we'd need input from Steve Dower here, as these changes were made (I believe) in support of the Windows Store build of Python, so any changes would need to be considered in the light of how they would affect that. I do, however, consider this to be a regression that should be fixed.

BTW, just for completeness,

>>> subprocess.check_output([sys.executable, '-c', 'import sys; print(sys.executable)'])

works as I'd expect, and that's the idiom that is often used. So relying on a path search to find the correct Python can be considered an unusual case (but nevertheless one I'd expect to be fixed).

I assume that the issue here is that the code is being run by the python.dll in the base environment, and whens searching for executables, Windows gives "exes that are in the same directory as the currently executing code" priority over PATH. See https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw, specifically

"""
If the file name does not contain a directory path, the system searches for the executable file in the following sequence:

1. The directory from which the application loaded.
2. The current directory for the parent process.
3. The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable. Note that this function does not search the per-application path specified by the App Paths registry key. To include this per-application path in the search sequence, use the ShellExecute function.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 03:32:53 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 25 Nov 2019 08:32:53 +0000
Subject: [issue38895] performance degradation creating a mock object (by
 factor 7-8)
In-Reply-To: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>
Message-ID: <1574670773.43.0.961223325046.issue38895@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Marcel for the pointer. I can confirm the performance impact. This occurs in the common case where not being an AsyncMock the signature of NonCallableMock.__init__ is created every time and then bind_partial is used to detect the spec being supplied to be async. It seems creating the signature of NonCallableMock.__init__ per mock creation is expensive and since it doesn't change can we just create the signature once and set it as a module level attribute? There might still be room for some more optimisations here to reduce the impact.

$ python3.7 -m timeit -s 'from unittest.mock import Mock' 'Mock()'
20000 loops, best of 5: 17.6 usec per loop

# Creating signature object per run (Python 3.8.0)

$ ./python.exe -m timeit -s 'from unittest.mock import Mock' 'Mock()'
2000 loops, best of 5: 109 usec per loop

# Set the signature object of NonCallableMock.__init__ as a private module level attribute (Python 3.8.0)

./python.exe -m timeit -s 'from unittest.mock import Mock' 'Mock()'
5000 loops, best of 5: 66.4 usec per loop

----------
nosy: +cjw296, lisroach, mariocj89, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Mon Nov 25 03:50:55 2019
From: report at bugs.python.org (PCManticore)
Date: Mon, 25 Nov 2019 08:50:55 +0000
Subject: [issue38854] Decorator breaks inspect.getsource
In-Reply-To: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>
Message-ID: <1574671855.06.0.180414636723.issue38854@roundup.psfhosted.org>


Change by PCManticore <pcmanticore at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Mon Nov 25 03:53:31 2019
From: report at bugs.python.org (PCManticore)
Date: Mon, 25 Nov 2019 08:53:31 +0000
Subject: [issue38854] Decorator breaks inspect.getsource
In-Reply-To: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>
Message-ID: <1574672011.11.0.705401164672.issue38854@roundup.psfhosted.org>


PCManticore <pcmanticore at gmail.com> added the comment:

Thanks for the report!

Turns out this was a bug in ``inspect.BlockFinder`` which is responsible for extracting out the source code from a given block. This class was considering ")" inside a decorator call as closing the decorator itself, even when the decorator call was accepting additional arguments that needed parentheses, such as function calls or tuples.

Just submitted a PR https://github.com/python/cpython/pull/17374 to address this issue.

----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Mon Nov 25 04:13:45 2019
From: report at bugs.python.org (Leif Middelschulte)
Date: Mon, 25 Nov 2019 09:13:45 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1574673225.31.0.485949758487.issue38893@roundup.psfhosted.org>


Leif Middelschulte <leif.middelschulte at gmail.com> added the comment:

> Could you please provide name and value of the setxattr() call? I bet it's trying to setxattr 'security.selinux' extended file attribute.

(Pdb) bt full
  /usr/lib64/python3.7/pdb.py(1701)main()
-> pdb._runscript(mainpyfile)
  /usr/lib64/python3.7/pdb.py(1570)_runscript()
-> self.run(statement)
  /usr/lib64/python3.7/bdb.py(585)run()
-> exec(cmd, globals, locals)
  <string>(1)<module>()->None
  /tmp/test.py(6)<module>()->None
-> copy2('/tmp/some_file', '/relabel_bug/failure')
  /usr/lib64/python3.7/shutil.py(267)copy2()
-> copystat(src, dst, follow_symlinks=follow_symlinks)
  /usr/lib64/python3.7/shutil.py(209)copystat()
-> _copyxattr(src, dst, follow_symlinks=follow)
> /usr/lib64/python3.7/shutil.py(165)_copyxattr()
-> os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
(Pdb) p dst
'/relabel_bug/failure'
(Pdb) p name
'security.selinux'
(Pdb) p value
b'system_u:object_r:fusefs_t:s0\x00'
(Pdb)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Mon Nov 25 04:17:27 2019
From: report at bugs.python.org (Leif Middelschulte)
Date: Mon, 25 Nov 2019 09:17:27 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1574673447.09.0.744942017388.issue38893@roundup.psfhosted.org>


Leif Middelschulte <leif.middelschulte at gmail.com> added the comment:

For the sake of completeness, the content of `/tmp/test.py`:

```
#!/usr/bin/env python3

from shutil import copy2

copy2('/tmp/some_file', '/relabel_bug/failure')
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Mon Nov 25 04:44:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 25 Nov 2019 09:44:20 +0000
Subject: [issue38895] performance degradation creating a mock object (by
 factor 7-8)
In-Reply-To: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>
Message-ID: <1574675060.43.0.717029667938.issue38895@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Another point is that _spec_asyncs is a list of attributes that pass asyncio.iscoroutinefunction which could be also little expensive [0]. The check is made for the attribute to be async only when the child mock is created to return an AsyncMock [1] during creation. This could be moved to _get_child_mock so that the Mock creation itself for all other mocks and common use case is faster. Creating child mocks will have the iscoroutine function check performed where maybe we can populate the _spec_async list and use it for subsequent calls.

# Baseline 3.7

$ python3.7 -m timeit -s 'from unittest.mock import Mock' 'Mock()'
20000 loops, best of 5: 17.6 usec per loop

# Move NonCallableMock.__init__ signature to module level attribute. (Python 3.8 branch HEAD)

$ ./python.exe -m timeit -s 'from unittest.mock import Mock' 'Mock()'
5000 loops, best of 5: 62.1 usec per loop

# Move the iscoroutinefunction check to the child mock creation. I didn't do the child mock creation benchmark yet and populating _spec_async as the attribute is found to be async would resolve doing iscoroutinefunction check everytime. (Python 3.8 branch HEAD)

$ ./python.exe -m timeit -s 'from unittest.mock import Mock' 'Mock()'
10000 loops, best of 5: 28.3 usec per loop

[0] https://github.com/python/cpython/blob/27fc3b6f3fc49a36d3f962caac5c5495696d12ed/Lib/unittest/mock.py#L488-L492
[1] https://github.com/python/cpython/blob/27fc3b6f3fc49a36d3f962caac5c5495696d12ed/Lib/unittest/mock.py#L987


diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index 488ab1c23d..7ff99407ab 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -403,7 +403,6 @@ class NonCallableMock(Base):
         bases = (cls,)
         if not issubclass(cls, AsyncMock):
             # Check if spec is an async object or function
-            sig = inspect.signature(NonCallableMock.__init__)
             bound_args = sig.bind_partial(cls, *args, **kw).arguments
             spec_arg = [
                 arg for arg in bound_args.keys()
@@ -491,11 +490,6 @@ class NonCallableMock(Base):
                        _eat_self=False):
         _spec_class = None
         _spec_signature = None
-        _spec_asyncs = []
-
-        for attr in dir(spec):
-            if asyncio.iscoroutinefunction(getattr(spec, attr, None)):
-                _spec_asyncs.append(attr)
 
         if spec is not None and not _is_list(spec):
             if isinstance(spec, type):
@@ -513,7 +507,6 @@ class NonCallableMock(Base):
         __dict__['_spec_set'] = spec_set
         __dict__['_spec_signature'] = _spec_signature
         __dict__['_mock_methods'] = spec
-        __dict__['_spec_asyncs'] = _spec_asyncs
 
     def __get_return_value(self):
         ret = self._mock_return_value
@@ -989,7 +982,8 @@ class NonCallableMock(Base):
         For non-callable mocks the callable variant will be used (rather than
         any custom subclass)."""
         _new_name = kw.get("_new_name")
-        if _new_name in self.__dict__['_spec_asyncs']:
+        attribute = getattr(self.__dict__['_spec_class'], _new_name, None)
+        if asyncio.iscoroutinefunction(attribute):
             return AsyncMock(**kw)
 
         _type = type(self)
@@ -1032,6 +1026,8 @@ class NonCallableMock(Base):
         return f"\n{prefix}: {safe_repr(self.mock_calls)}."
 
 
+sig = inspect.signature(NonCallableMock.__init__)
+
 
 def _try_iter(obj):
     if obj is None:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Mon Nov 25 05:40:56 2019
From: report at bugs.python.org (Iza Romanowska)
Date: Mon, 25 Nov 2019 10:40:56 +0000
Subject: [issue38881] unexpected behaviour of random.choices with zero weights
In-Reply-To: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>
Message-ID: <1574678456.71.0.724234996627.issue38881@roundup.psfhosted.org>


Iza Romanowska <izaromanowska at gmail.com> added the comment:

Many thanks for patching it! 
Much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38881>
_______________________________________

From report at bugs.python.org  Mon Nov 25 06:00:39 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 25 Nov 2019 11:00:39 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574679639.96.0.490947257909.issue38905@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> whens searching for executables, Windows gives "exes that are in the
> same directory as the currently executing code" priority over PATH.

That subprocess lets CreateProcessW use a platform-dependent search that prioritizes the application directory has come up in previous issues. To avoid this, we'd have to implement our own search for the given or parsed executable name. Then pass the fully-qualified executable path as the lpApplicationName name of CreateProcessW. This is how CMD works, since it has its own search routine that incorporates the PATHEXT environment variable.

Because the application directory is searched before the working directory (if the working directory is searched at all, depending on context), this issue also affects searching for executable paths that contain a path separator. In Unix a relative path that contains a path separator is always relative to the working directory, but Windows CreateProcessW uses a normal search for a relative name unless it explicitly references the working directory as "." (e.g. ".\Scripts\pip.exe" instead of "Scripts\pip.exe").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 06:29:23 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 25 Nov 2019 11:29:23 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574681363.11.0.519742681426.issue38870@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +16858
pull_request: https://github.com/python/cpython/pull/17376

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Nov 25 06:49:21 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Nov 2019 11:49:21 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574682561.75.0.534940953348.issue38870@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ded8888fbc33011dd39b7b1c86a5adfacc4943f3 by Miss Islington (bot) (Pablo Galindo) in branch 'master':
bpo-38870: Remove dependency on contextlib to avoid performance regression on import (GH-17376)
https://github.com/python/cpython/commit/ded8888fbc33011dd39b7b1c86a5adfacc4943f3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Nov 25 06:51:12 2019
From: report at bugs.python.org (Paul Moore)
Date: Mon, 25 Nov 2019 11:51:12 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574682672.63.0.493619012491.issue38905@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

I presume there's also the option of setting up the environment (or however it's done now - I know the details changed as the feature was developed) so that the "base" python.exe pretends to be the venv one, exactly as the wrapper does.

However, that may well have other difficult-to-fix implications, not least that calling the base Python using an explicit full path should act like the base Python, and *not* like the venv one.

IMO, the key thing here is that either the various limitations/quirks of redirecting to the base Python should either be treated as bugs, or they should be documented (even if only in the form of explicitly saying not to rely on any specific behaviour - e.g. "running an unqualified python and expecting a PATH search to pick up the same executable as the parent shell would is not supported and may produce unexpected results").

Virtual environments are a key part of most Python development workflows, and virtualenv is in the process of switching to use the core venv module internally. When that happens, there will be a lot more visibility for unexpected behaviours like this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 07:36:18 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 25 Nov 2019 12:36:18 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574685378.08.0.338122552664.issue38905@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> "running an unqualified python and expecting a PATH search to pick up
> the same executable as the parent shell would is not supported and may
> produce unexpected results"

CreateProcessW finds "python.exe" in __APPDIR__ before it even searches PATH. I expect that some scripts depend on this when python.exe isn't in PATH, or when a different version is in PATH. If subprocess implements its own search, it can continue to prioritize the *effective* application directory, from dirname(sys.executable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 09:25:53 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 25 Nov 2019 14:25:53 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1574691953.3.0.262866991481.issue38870@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +16859
pull_request: https://github.com/python/cpython/pull/17377

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Nov 25 10:36:29 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 25 Nov 2019 15:36:29 +0000
Subject: [issue20928] xml.etree.ElementInclude does not include nested
 xincludes
In-Reply-To: <1394829606.55.0.5394943571.issue20928@psf.upfronthosting.co.za>
Message-ID: <1574696188.99.0.875183747511.issue20928@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset c6a7bdb356835c9d7513b1ea6846683d446fe6c3 by Stefan Behnel in branch 'master':
bpo-20928: support base-URL and recursive includes in etree.ElementInclude (#5723)
https://github.com/python/cpython/commit/c6a7bdb356835c9d7513b1ea6846683d446fe6c3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20928>
_______________________________________

From report at bugs.python.org  Mon Nov 25 10:38:03 2019
From: report at bugs.python.org (Riccardo Schirone)
Date: Mon, 25 Nov 2019 15:38:03 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1574696283.01.0.0043293319556.issue38576@roundup.psfhosted.org>


Riccardo Schirone <rschiron at redhat.com> added the comment:

The glibc issue mentioned in the first comment is CVE-2016-10739 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Mon Nov 25 10:41:12 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 25 Nov 2019 15:41:12 +0000
Subject: [issue20928] xml.etree.ElementInclude does not include nested
 xincludes
In-Reply-To: <1394829606.55.0.5394943571.issue20928@psf.upfronthosting.co.za>
Message-ID: <1574696472.45.0.499593162826.issue20928@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I think setting "xml:base" from ElementInclude is worth another ticket.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20928>
_______________________________________

From report at bugs.python.org  Mon Nov 25 10:44:15 2019
From: report at bugs.python.org (da-dada)
Date: Mon, 25 Nov 2019 15:44:15 +0000
Subject: [issue38909] module name 'stat.py'
Message-ID: <1574696655.76.0.731755087716.issue38909@roundup.psfhosted.org>


New submission from da-dada <georg.klingenberg at travedsl.de>:

well, call your module 'stat.py' and python takes over full ownership: it's somewhat all public..

----------
components: Windows
messages: 357444
nosy: da-dada, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: module name 'stat.py'
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38909>
_______________________________________

From report at bugs.python.org  Mon Nov 25 10:55:03 2019
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 25 Nov 2019 15:55:03 +0000
Subject: [issue38909] module name 'stat.py'
In-Reply-To: <1574696655.76.0.731755087716.issue38909@roundup.psfhosted.org>
Message-ID: <1574697303.69.0.0513466634927.issue38909@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

It's not clear what you're reporting here, but it looks like the classic issue that naming your module the same as one in the standard library will cause things to break.  There are numerous other issues about that; please find the active one if you have anything to add to it.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38909>
_______________________________________

From report at bugs.python.org  Mon Nov 25 11:47:51 2019
From: report at bugs.python.org (JIanqiu Tao)
Date: Mon, 25 Nov 2019 16:47:51 +0000
Subject: [issue38907] Add IPv6 Dual-Stack control for http.server
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1574700471.86.0.0626184484622.issue38907@roundup.psfhosted.org>


Change by JIanqiu Tao <zkonge at outlook.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38907>
_______________________________________

From report at bugs.python.org  Mon Nov 25 11:56:57 2019
From: report at bugs.python.org (Jon Nalley)
Date: Mon, 25 Nov 2019 16:56:57 +0000
Subject: [issue38861] zipfile: Corrupts filenames containing non-UTF8
 characters
In-Reply-To: <1574650874.24.0.642584489474.issue38861@roundup.psfhosted.org>
Message-ID: <CA+YUYtOhvOX1uEUuicKD=Zv4gZoisxU2akX8E7Q4pizZQ5Rb+w@mail.gmail.com>


Jon Nalley <code at bluebot.org> added the comment:

Please see a detailed explanation of the behavior here:
https://gist.github.com/jnalley/cec21bca2d865758bc5e23654df28bd5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38861>
_______________________________________

From report at bugs.python.org  Mon Nov 25 12:14:04 2019
From: report at bugs.python.org (Eric Snow)
Date: Mon, 25 Nov 2019 17:14:04 +0000
Subject: [issue37292] _xxsubinterpreters: Can't unpickle objects defined in
 __main__
In-Reply-To: <1560603991.54.0.788079404137.issue37292@roundup.psfhosted.org>
Message-ID: <1574702044.59.0.115890250733.issue37292@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Yeah, the case of pickle + __main__ is an awkward one. [1]  However, the approach taken by multiprocessing isn't the right one for subinterpreters.

Multiprocessing operates under 2 design points that do not apply to subinterpreters:

* every process is running in the same __main__ module (sans the "script" part)
* pickle is a critical part of data-passing

For spawn, multiprocessing automatically runs the original __main__ module in each newly spawned process. [2]  Note that it runs it there with __name__ set to __mp_main__ (rather than __main__), to keep the "script" part from running.  
Subinterpreters could be made to work like this [3] but in reality they are more like processes created using the subprocess module.

I do not expect that to change.  However, there is room for add opt-in support for rerunning __main__ in a subinterpreter, or helpers to accomplish the same.  We can address such opt-in support or helpers in a separate issue later.  For now we are focusing on the fundamentals (at least in the context of PEP 554).


[1] Note that the problem is only with the __main__ module.  For other modules pickle does the right thing.
[2] https://github.com/python/cpython/blob/master/Lib/multiprocessing/spawn.py#L287
[3] I expect we will see subinterpreters supported in the multiprocessing module just like threads are supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37292>
_______________________________________

From report at bugs.python.org  Mon Nov 25 12:20:41 2019
From: report at bugs.python.org (Eric Snow)
Date: Mon, 25 Nov 2019 17:20:41 +0000
Subject: [issue37292] _xxsubinterpreters: Can't unpickle objects defined in
 __main__
In-Reply-To: <1560603991.54.0.788079404137.issue37292@roundup.psfhosted.org>
Message-ID: <1574702441.4.0.783500846674.issue37292@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

In the meantime that leaves the workarounds that @crusaderky originally identified.  You could also:

* manually run __main__ in the subinterpreter first (sort of like multiprocessing does automatically); this works because the namespace of __main__ is not reset for each run_string() call
* (for -m) update __module__ of the relevant objects to be the actual module name rather than "__main__"

In the case of that second point, it relates to PEP 499 (which will ensure that the module is added to sys.modules in the -m case).  However, that PEP doesn't say anything about updating __module__ for objects.  I'll bring that up there.  With that solution the problem in this issue would go away.

Note that it won't help for objects in the __main__ of subinterpreters, since they do not correspond to executed modules.  Hmm, maybe it could still work...

Regardless, I'll open issues over on https://github.com/ericsnowcurrently/multi-core-python to track these possible future enhancements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37292>
_______________________________________

From report at bugs.python.org  Mon Nov 25 12:38:12 2019
From: report at bugs.python.org (Eric Snow)
Date: Mon, 25 Nov 2019 17:38:12 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1574703492.91.0.00896331875297.issue36375@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FWIW, I have some feedback on the PEP.  (See msg357448.)  Can we discuss here or should I open a mailing list thread?

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Mon Nov 25 13:06:01 2019
From: report at bugs.python.org (=?utf-8?q?Marcel_Zi=C4=99ba?=)
Date: Mon, 25 Nov 2019 18:06:01 +0000
Subject: [issue38895] performance degradation creating a mock object (by
 factor 7-8)
In-Reply-To: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>
Message-ID: <1574705161.0.0.579570617814.issue38895@roundup.psfhosted.org>


Marcel Zi?ba <marseel at gmail.com> added the comment:

"It seems creating the signature of NonCallableMock.__init__ per mock creation is expensive and since it doesn't change can we just create the signature once and set it as a module level attribute? There might still be room for some more optimisations here to reduce the impact."

This is already done in master branch ;)


"This could be moved to _get_child_mock so that the Mock creation itself for all other mocks and common use case is faster. Creating child mocks will have the iscoroutine function check performed where maybe we can populate the _spec_async list and use it for subsequent calls."

This seems like a reasonable solution.
I've tested it and it improves mock creation speed 2x.

Do you mind if I create PR for it? I would like to start contributing to CPython ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Mon Nov 25 13:06:38 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 25 Nov 2019 18:06:38 +0000
Subject: [issue38890] A subprocess.Popen created with
 creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
In-Reply-To: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>
Message-ID: <1574705198.44.0.872067118595.issue38890@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

For a console application, normally the system connects to either the console that's inherited from the parent or, if no console is inherited, a newly allocated console. The creation flag DETACHED_PROCESS sets the initial console handle in the child to a special value that tells the system to skip connecting to a console. If the child process doesn't subsequently call AllocConsole, AttachConsole, or create a visible top-level window, then it will considered to be background process. 

Note that 'detached' in this case doesn't mean detached from the parent process. There's no such attachment to begin with because Windows does not maintain a process tree. It uses a nested job-object hierarchy as the equivalent of a Unix process tree. The creation flag CREATE_BREAKAWAY_FROM_JOB breaks away from jobs that allow it.

The Popen warning is a tool to help programmers become aware of leaked child processes. I do think there should be a documented way to disable this warning for a child process. However, this is unrelated to the DETACHED_PROCESS flag.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38890>
_______________________________________

From report at bugs.python.org  Mon Nov 25 13:08:25 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 25 Nov 2019 18:08:25 +0000
Subject: [issue38890] A subprocess.Popen created with
 creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
In-Reply-To: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>
Message-ID: <1574705305.55.0.290631213196.issue38890@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38890>
_______________________________________

From report at bugs.python.org  Mon Nov 25 13:38:39 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Nov 2019 18:38:39 +0000
Subject: [issue38901] Add a CLI flag to venv to use the pwd basename as the
 prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1574707119.07.0.213200589708.issue38901@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@Vinay you got exactly what I mean. I had to actually teach a ton of people that shell trick with basename and pwd on Twitter, that trick doesn't seem to be something people know about, and yet a ton of people seem to be creating virtual environments with prompts manually specified like that.

Plus that trick varies from shell to shell and we already have enough issues just explaining to people how to activate between Windows and UNIX and then between even shells on the same OS.

So this is entirely for convenience.

@Julien default directory names is an entirely separate topic as people can't agree on the default name (e.g. I prefer `.venv` as my default).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Mon Nov 25 13:58:07 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 25 Nov 2019 18:58:07 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574708287.61.0.98930348385.issue38905@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yeah, this definitely relates to how Windows handles unqualified argv[0] in CreateProcess. Though I thought we checked that out in another issue and decided that "most" people are correctly using sys.executable here? (Or decided that it was documented well enough that they should, and using a "python" literal was relying on OS behaviour.)

I'm not a fan of trying to override the OS handling in subprocess, though that would be the fix. Possibly we could handle "python[.exe]" literals by substituting sys.executable transparently?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 14:00:51 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 25 Nov 2019 19:00:51 +0000
Subject: [issue38906] copy2 doesn't copy metadata on Windows and MacOS
In-Reply-To: <1574597606.02.0.586122584542.issue38906@roundup.psfhosted.org>
Message-ID: <1574708451.03.0.729678591015.issue38906@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

As a general statement (I haven't taken the time yet to understand all the intricacies of this particular issue), I would prefer to see CopyFile used everywhere on Windows for the performance and reliability benefits. Perfect POSIX emulation here doesn't seem helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38906>
_______________________________________

From report at bugs.python.org  Mon Nov 25 14:03:09 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 25 Nov 2019 19:03:09 +0000
Subject: [issue38890] A subprocess.Popen created with
 creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
In-Reply-To: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>
Message-ID: <1574708589.4.0.535967807104.issue38890@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Didn't we clean up this warning completely on Windows recently?

It apparently matters on POSIX to join() the child process, but on Windows you aren't going to leak any resources by just forgetting about it, so I thought we stopped tracking them entirely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38890>
_______________________________________

From report at bugs.python.org  Mon Nov 25 14:20:31 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 25 Nov 2019 19:20:31 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574709631.15.0.83890717322.issue38905@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

To provide concrete context, the problem I?m facing is with how Flit resolves `flit install --python`:

https://github.com/takluyver/flit/blob/7e65ffc7a540d76b96de0df473d3edff6f97c26c/flit/__init__.py#L18-L28

Generally the setup is to install Flit into a globally available location (let?s name it env A), so it?s usable for every project and environment. For a project foo you?d have a virtual environment (env X) that?s created from a base interpreter (env B, which may or may not be the same as env A).

So the comment workflow would look like this:

> pythonB -m venv project-env
> project-env\Scripts\activate.bat
(project-env) > pythonA -m flit install --python=pythonX

This results in the following subprocess call:

subprocess.check_output(
    ["pythonX", "-c", "import sys; print(sys.executable)"],
    universal_newlines=True,
).strip()

And ideally (pre-3.7.2 Windows, or current POSIX behaviour) this would give you the absolute path to pythonX. But right now on Windows the result is pythonB.

So if this is to be determined as acceptable behaviour, we?d need to come up with a suggestion how this code can be rewritten. `shutil.which` could be a direction, but still not enough since it?d break `flit install --python=py` because that?s give you the location of py.exe, not the actual interperter. What else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 14:37:07 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 25 Nov 2019 19:37:07 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574710627.65.0.0401591414619.issue38905@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> `shutil.which` could be a direction, but still not enough since it?d break `flit install --python=py` because that?s give you the location of py.exe, not the actual interperter.

This would be fine if you still run the process to get its sys.executable.

Your specific example would never have worked, FWIW, as it always would have picked up pythonA rather than the application one or the base one, unless you were relying on python3/python3.7 not being available on Windows (which is no longer true - they are included in the Store package now).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 14:37:21 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 25 Nov 2019 19:37:21 +0000
Subject: [issue38890] A subprocess.Popen created with
 creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
In-Reply-To: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>
Message-ID: <1574710641.05.0.473653004114.issue38890@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Didn't we clean up this warning completely on Windows recently? It
> apparently matters on POSIX to join() the child process, but on
> Windows you aren't going to leak any resources by just forgetting
> about it, so I thought we stopped tracking them entirely.

There's only a PID in POSIX, so the OS keeps a zombie process until the parent waits on it. Windows uses a handle for the process, which gets automatically closed when the Popen instance is finalized, so we don't have to explicitly wait on the process, and doing so has no bearing on the lifetime of the kernel process object. 

Recently, a change was made to set _active to None in Windows, so _cleanup is no longer called unnecessarily. But Victor wanted to keep the resource warning for its educational value, given some programmers might not be aware when they've left a background process running. So Popen.__del__ still issues a resource warning if returncode is None. The OP's workaround to manually set returncode works, but it's undocumented and feels like a kludge to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38890>
_______________________________________

From report at bugs.python.org  Mon Nov 25 15:27:05 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 25 Nov 2019 20:27:05 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574713625.05.0.0795489468755.issue38905@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Possibly we could handle "python[.exe]" literals by substituting 
> sys.executable transparently?

Perhaps generalize this as splitext(basename(sys.executable))[0] in order to support names other than "python" and "pythonw". It would have to handle quoting enough to ignore an initial double quote when parsing the executable name out of an args string, or _winapi could wrap the shell's CommandLineToArgvW function to handle this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 15:37:57 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Nov 2019 20:37:57 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574714277.35.0.965771882618.issue38862@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +16861
pull_request: https://github.com/python/cpython/pull/17379

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Mon Nov 25 15:42:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Nov 2019 20:42:45 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574714565.69.0.926114304111.issue38862@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +16862
pull_request: https://github.com/python/cpython/pull/17380

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Mon Nov 25 16:06:06 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 25 Nov 2019 21:06:06 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574715966.27.0.807768296108.issue38905@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Perhaps generalize this as splitext(basename(sys.executable))[0] in
> order to support names other than "python" and "pythonw". It would have
> to handle quoting enough to ignore an initial double quote when parsing
> the executable name out of an args string, or _winapi could wrap the
> shell's CommandLineToArgvW function to handle this.

This is where we've hit the point of complexity that it would have to be added as a new API. And since it's now opt-in, we may as well document that shutil.which() is the recommended way to resolve a filename against PATH (and make that work properly... ISTR it has some inconsistencies with the OS).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 16:53:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Nov 2019 21:53:56 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574718836.02.0.853795620277.issue38500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fabio: "I don't really see a problem in breaking the API in major releases (so, having access for it in the internal API but without a backwards-compatibility guarantee seems like a good fit for me)."

In Python, the internal C API now means that you have to define Py_BUILD_CORE_MODULE macro and include a special "internal/pycore_pystate.h" header file.

If you are fine with doing that in PyCharm, what is the purpose of this issue?

Do you mean in *internal* API or a *private* API? Private API is basically a public API with weaker backward compatibility warranties and with a "_" prefix (_Py, _PY prefix).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:18:12 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Nov 2019 22:18:12 +0000
Subject: [issue21063] Touch up one-line descriptions of modules for module
 index
In-Reply-To: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>
Message-ID: <1574720292.42.0.964882548338.issue21063@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset f8a6316778faff3991144c3aec4fa92d7b30a72b by Brett Cannon (Sanchit Khurana) in branch 'master':
bpo-21063: Improve module synopsis for distutils (GH-17363)
https://github.com/python/cpython/commit/f8a6316778faff3991144c3aec4fa92d7b30a72b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21063>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:18:15 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Nov 2019 22:18:15 +0000
Subject: [issue21063] Touch up one-line descriptions of modules for module
 index
In-Reply-To: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>
Message-ID: <1574720295.15.0.640390953042.issue21063@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16863
pull_request: https://github.com/python/cpython/pull/17381

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21063>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:18:22 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Nov 2019 22:18:22 +0000
Subject: [issue21063] Touch up one-line descriptions of modules for module
 index
In-Reply-To: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>
Message-ID: <1574720302.49.0.254852823058.issue21063@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16864
pull_request: https://github.com/python/cpython/pull/17382

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21063>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:18:29 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Nov 2019 22:18:29 +0000
Subject: [issue21063] Touch up one-line descriptions of modules for module
 index
In-Reply-To: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>
Message-ID: <1574720309.61.0.369333021811.issue21063@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21063>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:19:50 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Nov 2019 22:19:50 +0000
Subject: [issue21063] Touch up one-line descriptions of modules for module
 index
In-Reply-To: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>
Message-ID: <1574720390.81.0.646856306879.issue21063@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16865
pull_request: https://github.com/python/cpython/pull/17383

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21063>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:26:47 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Nov 2019 22:26:47 +0000
Subject: [issue21063] Touch up one-line descriptions of modules for module
 index
In-Reply-To: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>
Message-ID: <1574720807.25.0.586558058167.issue21063@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 089387ed1f47d9443b5f28bb1863294eeac2de08 by Miss Islington (bot) in branch '3.8':
bpo-21063: Improve module synopsis for distutils (GH-17363)
https://github.com/python/cpython/commit/089387ed1f47d9443b5f28bb1863294eeac2de08


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21063>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:42:00 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Mon, 25 Nov 2019 22:42:00 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574721720.62.0.660700823252.issue38884@roundup.psfhosted.org>


Change by Valentyn Tymofieiev <valentyn at google.com>:


----------
nosy: +brett.cannon -Valentyn Tymofieiev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:42:20 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Mon, 25 Nov 2019 22:42:20 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574721740.44.0.717313000199.issue38884@roundup.psfhosted.org>


Change by Valentyn Tymofieiev <valentyn at google.com>:


----------
nosy: +Valentyn Tymofieiev -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:43:41 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Mon, 25 Nov 2019 22:43:41 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574721821.09.0.0887185893088.issue38884@roundup.psfhosted.org>


Change by Valentyn Tymofieiev <valentyn at google.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Mon Nov 25 17:49:12 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Mon, 25 Nov 2019 22:49:12 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1574722152.16.0.392460638228.issue38884@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

@brett.cannon, looks like I inadvertently dropped you from nosy list, so in case you missed the updates - please take a look at issue38884.zip. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Mon Nov 25 18:28:54 2019
From: report at bugs.python.org (Joseph Reagle)
Date: Mon, 25 Nov 2019 23:28:54 +0000
Subject: [issue38910] AssertionError: ElementTree not initialized, missing root
Message-ID: <1574724534.5.0.309453376726.issue38910@roundup.psfhosted.org>


New submission from Joseph Reagle <joseph.2011 at reagle.org>:

I've attached a simple XHTML file with which the 3.8 interpreter throws an error on the following code, but 3.7 does not. (You'll have to change the path in the code below.)

```
from io import StringIO, BytesIO
from lxml import etree
import os
import readline

HOME = os.path.expanduser("~")

ofile = HOME + '/data/2web/reagle.org/joseph/plan/plans/index.html'
plan_fd = open(ofile, 'r', encoding='utf-8', errors='replace')
plan_content = plan_fd.read()
plan_fd.close()
plan_tree = etree.parse(StringIO(plan_content),
                        etree.XMLParser(ns_clean=True, recover=True))
ul_found = plan_tree.xpath(
    '''//x:div[@id='Done']/x:ul''',
    namespaces={'x': 'http://www.w3.org/1999/xhtml'})
```

----------
components: Library (Lib)
files: index.html
messages: 357465
nosy: joseph.reagle
priority: normal
severity: normal
status: open
title: AssertionError: ElementTree not initialized, missing root
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48742/index.html

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38910>
_______________________________________

From report at bugs.python.org  Mon Nov 25 18:30:44 2019
From: report at bugs.python.org (Joseph Reagle)
Date: Mon, 25 Nov 2019 23:30:44 +0000
Subject: [issue38910] AssertionError: ElementTree not initialized, missing root
In-Reply-To: <1574724534.5.0.309453376726.issue38910@roundup.psfhosted.org>
Message-ID: <44e9b334-fdf8-30c9-33a6-de4abda5a499@reagle.org>


Joseph Reagle <joseph.2011 at reagle.org> added the comment:

Here's the error:

```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "src/lxml/etree.pyx", line 2291, in lxml.etree._ElementTree.xpath
  File "src/lxml/etree.pyx", line 1869, in lxml.etree._ElementTree._assertHasRoot
AssertionError: ElementTree not initialized, missing root
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38910>
_______________________________________

From report at bugs.python.org  Mon Nov 25 19:29:58 2019
From: report at bugs.python.org (Matt McEwen)
Date: Tue, 26 Nov 2019 00:29:58 +0000
Subject: [issue38911] include __del__ in Generator ABC
Message-ID: <1574728198.51.0.732377638731.issue38911@roundup.psfhosted.org>


New submission from Matt McEwen <mmcewen at google.com>:

The Generator ABC in the standard library lets users define objects that follow the Generator specification given in PEP342, and which can be used in the place of builtin generator objects. 

This was originally added in issue 24018

The ABC enforces that the methods `send`, `throw` and `close` are implemented, as per the spec. It doesn't enforce that `__del__` is implemented. PEP342 specifies that `__del__` be a wrapper for `close`, such that when a generator object is garbage collected `close` is called.

For a user (like me) implementing such a generator object by inheriting the Generator ABC, the resulting objects do not have `close` called when they are garbage collected. Fixing this requires manually implementing a `__del__` that calls `close`. 

Ideally from the user perspective, inheriting from Generator should be enough to guarantee that the object behaves like a generator object, provided the abstract methods are correctly implemented. This could be easily achieved by implementing `__del__` concretely in the ABC as a wrapper for `close`:

def __del__(self):
    self.close()

----------
components: Library (Lib)
messages: 357467
nosy: Matt McEwen
priority: normal
severity: normal
status: open
title: include __del__ in Generator ABC
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38911>
_______________________________________

From report at bugs.python.org  Mon Nov 25 19:33:45 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Nov 2019 00:33:45 +0000
Subject: [issue38911] include __del__ in Generator ABC
In-Reply-To: <1574728198.51.0.732377638731.issue38911@roundup.psfhosted.org>
Message-ID: <1574728425.54.0.64368117767.issue38911@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38911>
_______________________________________

From report at bugs.python.org  Mon Nov 25 19:41:20 2019
From: report at bugs.python.org (Peter Donis)
Date: Tue, 26 Nov 2019 00:41:20 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
 incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1574728880.67.0.79122129697.issue1812@roundup.psfhosted.org>


Change by Peter Donis <peterdonis at alum.mit.edu>:


----------
pull_requests: +16867
pull_request: https://github.com/python/cpython/pull/17385

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Mon Nov 25 19:43:38 2019
From: report at bugs.python.org (Peter Donis)
Date: Tue, 26 Nov 2019 00:43:38 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
 incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1574729018.65.0.948120625254.issue1812@roundup.psfhosted.org>


Peter Donis <peterdonis at alum.mit.edu> added the comment:

I have submitted pull request #17385 regarding this issue:

https://github.com/python/cpython/pull/17385

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Mon Nov 25 19:44:18 2019
From: report at bugs.python.org (Peter Donis)
Date: Tue, 26 Nov 2019 00:44:18 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
 incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1574729058.53.0.891169085801.issue1812@roundup.psfhosted.org>


Change by Peter Donis <peterdonis at alum.mit.edu>:


----------
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Mon Nov 25 19:48:26 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Nov 2019 00:48:26 +0000
Subject: [issue38911] include __del__ in Generator ABC
In-Reply-To: <1574728198.51.0.732377638731.issue38911@roundup.psfhosted.org>
Message-ID: <1574729306.53.0.68364402592.issue38911@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Guido should decide this one.  The PEP isn't entirely clear whether __del__ is a CPython implementation detail, nor is it clear whether the intent was for the isinstance() to insist on __del__ being present.  Also, at one time __del__ interfered with garbage collection, but that may have been fixed.

----------
assignee:  -> gvanrossum
nosy: +gvanrossum, pje, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38911>
_______________________________________

From report at bugs.python.org  Mon Nov 25 19:50:21 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 26 Nov 2019 00:50:21 +0000
Subject: [issue38912] test_asyncio altered the execution environment
Message-ID: <1574729421.23.0.927917235759.issue38912@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

https://buildbot.python.org/all/#/builders/260/builds/60/steps/5/logs/stdio


0:05:06 load avg: 6.65 [131/423] test_contextlib_async passed -- running: test_signal (1 min 53 sec), test_concurrent_futures (4 min 11 sec), test_zipfile (47.5 sec), test_statistics (48.6 sec), test_multiprocessing_forkserver (2 min 58 sec), test_multiprocessing_spawn (4 min 54 sec)
beginning 6 repetitions
123456
Task was destroyed but it is pending!
task: <Task pending name='Task-9' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-11' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-16' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-68' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-70' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-75' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-127' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-129' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-134' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-186' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-188' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-193' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-245' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-247' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-252' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-304' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-306' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-311' coro=<<async_generator_athrow without __name__>()>>
.
0:05:06 load avg: 6.65 [132/423] test_ssl passed -- running: test_signal (1 min 53 sec), test_concurrent_futures (4 min 11 sec), test_zipfile (47.6 sec), test_statistics (48.7 sec), test_multiprocessing_forkserver (2 min 58 sec), test_multiprocessing_spawn (4 min 54 sec)
beginning 6 repetitions
123456
/home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 45335), raddr=('127.0.0.1', 54018)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 39709), raddr=('127.0.0.1', 55950)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 39169), raddr=('127.0.0.1', 34992)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 53179), raddr=('127.0.0.1', 33400)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 36717), raddr=('127.0.0.1', 49724)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 40913), raddr=('127.0.0.1', 45944)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
.

beginning 6 repetitions
123456
Warning -- threading_cleanup() failed to cleanup 1 threads (count: 1, dangling: 2)
Dangling thread: <_MainThread(MainThread, started 140669094238016)>
Dangling thread: <Thread(waitpid-0, started daemon 140668768876288)>
Unknown child process pid 3450080, will report returncode 255
Loop <_UnixSelectorEventLoop running=False closed=True debug=False> that handles pid 3450080 is closed
....Unknown child process pid 3467752, will report returncode 255
Loop <_UnixSelectorEventLoop running=False closed=True debug=False> that handles pid 3467752 is closed
.Unknown child process pid 3468093, will report returncode 255
.

1 test altered the execution environment:
    test_asyncio

----------
components: Tests, asyncio
messages: 357470
nosy: asvetlov, pablogsal, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio altered the execution environment
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38912>
_______________________________________

From report at bugs.python.org  Mon Nov 25 20:01:22 2019
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 26 Nov 2019 01:01:22 +0000
Subject: [issue29167] Race condition in enum.py:_decompose()
In-Reply-To: <1483613666.47.0.301459916652.issue29167@psf.upfronthosting.co.za>
Message-ID: <1574730082.3.0.844094265609.issue29167@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

The latest patch from issue38045 should make race-conditions non-existent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29167>
_______________________________________

From report at bugs.python.org  Mon Nov 25 20:21:02 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 26 Nov 2019 01:21:02 +0000
Subject: [issue38911] include __del__ in Generator ABC
In-Reply-To: <1574728198.51.0.732377638731.issue38911@roundup.psfhosted.org>
Message-ID: <1574731262.73.0.265805701384.issue38911@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The PEP does not specify collections.Generator at all, so this is not just a matter of interpreting the PEP.

The presence of a __del__ method can cause subtle behavior changes to the GC, so I worry that adding __del__ to that class now is going to break currently-working code.

Not having seen the OP's Generator subclass, I wonder if they even meant to subclass collections.Generator?  It's pretty esoteric to subclass Generator -- usually it's better to subclass Iterator or Iterable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38911>
_______________________________________

From report at bugs.python.org  Mon Nov 25 20:48:04 2019
From: report at bugs.python.org (Graham Coster)
Date: Tue, 26 Nov 2019 01:48:04 +0000
Subject: [issue38625] SpooledTemporaryFile does not seek correctly after being
 rolled over
In-Reply-To: <1574649447.62.0.52476229188.issue38625@roundup.psfhosted.org>
Message-ID: <23A63731-1232-4D0F-A8C7-9FAA73A7A814@yahoo.co.uk>


Graham Coster <graham_coster999 at yahoo.co.uk> added the comment:

This may be a silly question, however, does SpooledTemporaryFile need to exist at all?

>From some testing on macOS, SpooledTemporaryFile appeared to never have a performance advantage over OS file caching, but with max_size greater than 4GB, it was a significant disadvantage.   

I found that the macOS built-in file cache was increasing in size as I wrote bigger TemporaryFile files, up to some limit the OS had decided. So, it seems the OS is automatically doing the same job as SpooledTemporaryFile.  Once the OS decided to write to disk, there was no sudden hit to performance, it just slowed down.

However, when SpooledTemporaryFile rolled-over large max_size files, there was a temporary big hit to performance, which then became a consistent slow down the same as TemporaryFile.

A big issue came with very large SpooledTemporaryFile  max_sizes hogging RAM and causing the OS to start swapping all processes.  This caused a huge performance hit to my program and the system as a whole. Once my program did finish, it took the system considerable time to reclaim swap.

I?m guessing SpooledTemporaryFile may have benefits on light weight embedded OSes that have no, or poor, file caching.  However, tuning the max_size to work with embedded systems? limited RAM could be tricky for developers and would be hardware dependent. So, perhaps leaving file caching to operating systems is actually a better, and safer, option than offering it in Python?

If there are no benefits to SpooledTemporaryFile, should it be deprecated? If so, as it is phasesd out, could it be patched to be a TemporaryFile wrapper, with no rollover functionality?

> On 25 Nov 2019, at 1:37 pm, Inada Naoki <report at bugs.python.org> wrote:
> 
> 
> Inada Naoki <songofacandy at gmail.com> added the comment:
> 
> SpooledTemporaryFile has very serious bug which causes data corruption (#26730).  Please don't use it with text mode until it is fixed.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38625>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38625>
_______________________________________

From report at bugs.python.org  Mon Nov 25 21:00:42 2019
From: report at bugs.python.org (Graham Coster)
Date: Tue, 26 Nov 2019 02:00:42 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <23A63731-1232-4D0F-A8C7-9FAA73A7A814@yahoo.co.uk>
Message-ID: <B991E2C3-55F8-458A-AA34-6FBC28108FC1@yahoo.co.uk>


Graham Coster <graham_coster999 at yahoo.co.uk> added the comment:

This may be a silly question, however, does SpooledTemporaryFile need to exist at all?

>From some testing on macOS, SpooledTemporaryFile appeared to never have a performance advantage over OS file caching, but with max_size greater than 4GB, it was a significant disadvantage. So, if the purpose of SpooledTemporaryFile is to increase performance, it may not work.

I found that the macOS built-in file cache was increasing in size as I wrote bigger TemporaryFile files, up to some limit the OS had decided. So, it seems the OS is automatically doing the same job as SpooledTemporaryFile.  Once the OS decided to write to disk, there was no sudden hit to performance, it just slowed down.

However, when SpooledTemporaryFile rolled-over large max_size files, there was a temporary big hit to performance, which then became a consistent slow down the same as a TemporaryFile that had exceeded the OS file cache.

A big issue came with very large SpooledTemporaryFile  max_sizes hogging RAM and causing the OS to start swapping all processes.  This caused a huge performance hit to my program and the system as a whole. Once my program did finish, it took the system considerable time to reclaim swap.

I?m guessing SpooledTemporaryFile may have benefits on light weight embedded OSes that have no, or poor, file caching.  However, tuning the max_size to work with embedded systems? limited RAM could be tricky for developers and would be hardware dependent. So, perhaps leaving file caching to the underlying operating systems is actually a better, and safer, option than offering it in Python?

If there are no benefits to SpooledTemporaryFile, should it be deprecated? If so, as it is phasesd out, could it be patched to be a TemporaryFile wrapper, with no rollover functionality?

----------
nosy: +graham.coster

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Mon Nov 25 22:07:43 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Nov 2019 03:07:43 +0000
Subject: [issue38803] test_wait3 and test_wait4 leaked references on x86
 Gentoo Refleaks 3.x
In-Reply-To: <1573771592.29.0.825228162147.issue38803@roundup.psfhosted.org>
Message-ID: <1574737663.75.0.386343544867.issue38803@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset e4db1f05e9a5828f6b287f99067362fa0e5732e8 by Benjamin Peterson (Eddie Elizondo) in branch 'master':
closes bpo-38803: Fix leak in posixmodule. (GH-17373)
https://github.com/python/cpython/commit/e4db1f05e9a5828f6b287f99067362fa0e5732e8


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38803>
_______________________________________

From report at bugs.python.org  Mon Nov 25 22:32:44 2019
From: report at bugs.python.org (Matt McEwen)
Date: Tue, 26 Nov 2019 03:32:44 +0000
Subject: [issue38911] include __del__ in Generator ABC
In-Reply-To: <1574728198.51.0.732377638731.issue38911@roundup.psfhosted.org>
Message-ID: <1574739164.52.0.211892814458.issue38911@roundup.psfhosted.org>


Matt McEwen <mmcewen at google.com> added the comment:

My interpretation of issue 24018 was that the Generator ABC was trying to follow the PEP as much as possible, so that users were able to produce a custom generator object and have it behave just like a builtin generator object.

I know that subclassing Generator is unusual; In my case that is a custom object that needs to be an iterator and also enter context managers internally. This seemed to me a very similar problem that the `close` machinery for generators was aimed to address, and subclassing generator worked really nicely, with one exception.

It took me some time to understand why the context managers weren't being exited correctly when the generator was interrupted, and it was because my `close` wasn't being called when the object fell out of scope, as it would have been if my object was a builtin generator object. Manually implementing __del__ fixed this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38911>
_______________________________________

From report at bugs.python.org  Mon Nov 25 22:42:03 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 26 Nov 2019 03:42:03 +0000
Subject: [issue38911] include __del__ in Generator ABC
In-Reply-To: <1574728198.51.0.732377638731.issue38911@roundup.psfhosted.org>
Message-ID: <1574739723.61.0.0577032899738.issue38911@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I wouldn't have use a Generator subclass for that. Let's not destabilize the Generator class.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38911>
_______________________________________

From report at bugs.python.org  Mon Nov 25 22:59:28 2019
From: report at bugs.python.org (Cameron Simpson)
Date: Tue, 26 Nov 2019 03:59:28 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1574703492.91.0.00896331875297.issue36375@roundup.psfhosted.org>
Message-ID: <20191126035922.GA55620@cskk.homeip.net>


Cameron Simpson <cs at cskk.id.au> added the comment:

On 25Nov2019 17:38, Python Bug Reports <report at bugs.python.org> wrote:
>Eric Snow <ericsnowcurrently at gmail.com> added the comment:
>
>FWIW, I have some feedback on the PEP.  (See msg357448.)  Can we discuss here or should I open a mailing list thread?

Let's discuss it here unless it looks like we need wider input. This is 
related to issue37292 (_xxsubinterpreters: Can't unpickle objects 
defined in __main__), yes?

With PEP499, "python -m foo" should have __name__=='__main__' and 
__spec__.name=='foo'. Were you thinking the __module__ should come from 
__spec__.name (and that the PEP should make that clear)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Mon Nov 25 23:28:01 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Tue, 26 Nov 2019 04:28:01 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574742481.67.0.663805807152.issue38905@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

>> not enough since it?d break `flit install --python=py` because that?s give you the location of py.exe, not the actual interperter.
> This would be fine if you still run the process to get its sys.executable.

But then I need two separate workflows based on what is passed in. For py.exe I need to run it and get sys.executable. But for python.exe I *cannot* use sys.executable because that?s the base interepeter, not the venv path I want. And `if Path(arg).stem == "py"` just seems like a bug waiting to happen.


> Your specific example would never have worked, FWIW, as it always would have picked up pythonA rather than the application one or the base one, unless you were relying on python3/python3.7 not being available on Windows (which is no longer true - they are included in the Store package now).

It is an illustration. I am fully aware of Windows not having version-named python executables. Thanks for the reminder anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Mon Nov 25 23:28:17 2019
From: report at bugs.python.org (John Goerzen)
Date: Tue, 26 Nov 2019 04:28:17 +0000
Subject: [issue38861] zipfile: Corrupts filenames containing non-UTF8
 characters
In-Reply-To: <1574218342.23.0.381286067182.issue38861@roundup.psfhosted.org>
Message-ID: <1574742497.21.0.901658869202.issue38861@roundup.psfhosted.org>


John Goerzen <jgoerzen at users.sourceforge.net> added the comment:

Hi Jon,

I've read your article in the gist, the ZIP spec, and the article you linked to.  As the article you linked to (https://marcosc.com/2008/12/zip-files-and-encoding-i-hate-you/) states, "Implementers just encode file names however they want (usually byte for byte as they are in the OS".  That is certainly my observation.  CP437 has NEVER been guaranteed, *even on DOS*.  See https://en.wikipedia.org/wiki/Category:DOS_code_pages and https://www.aivosto.com/articles/charsets-codepages-dos.html for details on DOS code pages.  I do not recall any translation between DOS codepages being done in practice, or even possible - since the whole point of multiple codepages was the need for more than 256 symbols.  So (leaving aside utf-8 encodings for a second) no operating system or ZIP implementation I am aware of performs a translation to cp437, such translation is often not even possible, and they're just copying literal bytes to ZIP -- as the POSIX filesystem itself is.

So, from the above paragraph, it's clear that the assumption in zipfile that cp437 is in use is faulty.  Your claim that Python "fixes" a problem is also faulty.  Converting from a latin-1 character, using a cp437 codeset, and generating a filename with that cp437 character represented as a Unicode code point is wrong in many ways.  Python should not take an opinion on this; it should be agnostic and copy the bytes that represent the filename in the ZIP to bytes that represent the filename on the filesystem.

POSIX filenames contain any of 254 characters (only 0x00 and '/' are invalid).  The filesystem is encoding-agnostic; POSIX filenames are just stream of bytes.  There is no alternative but to treat ZIP filenames (without the Unicode flag) the same way.  Copy bytes to bytes.  It is not possible to identify the encoding of the filename in the absence of the Unicode flag.

zipfile should:

1) expose a bytes interface to filename
2) use byte-for-byte extraction when no Unicode flag is present
3) not make the assumption that cp437 was the original encoding

Your proposal only "works" cross-platform because it is broken on every platform!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38861>
_______________________________________

From report at bugs.python.org  Mon Nov 25 23:51:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Nov 2019 04:51:16 +0000
Subject: [issue38895] performance degradation creating a mock object (by
 factor 7-8)
In-Reply-To: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>
Message-ID: <1574743876.02.0.727028087.issue38895@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> This is already done in master branch ;)

Thanks, I noticed the speed improvement in master and 3.7 but assumed it's due to some other optimisation in master.

> Do you mind if I create PR for it? I would like to start contributing to CPython ;)

Sure, I will be happy to review. I would like to know others thoughts on this too on deferring whether the attribute is async check to the mock's own creation in _get_child_mock instead of making the parent mock construction slightly expensive as per the current approach. We can at least backport the NonCallableMock.__init__ signature fix which seems safe to make an improvement.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38895>
_______________________________________

From report at bugs.python.org  Tue Nov 26 00:06:06 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Nov 2019 05:06:06 +0000
Subject: [issue38910] AssertionError: ElementTree not initialized, missing root
In-Reply-To: <1574724534.5.0.309453376726.issue38910@roundup.psfhosted.org>
Message-ID: <1574744766.3.0.945043071788.issue38910@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems more like an issue with lxml.

----------
nosy: +scoder, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38910>
_______________________________________

From report at bugs.python.org  Tue Nov 26 00:16:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Nov 2019 05:16:40 +0000
Subject: [issue34716] MagicMock.__divmod__ should return a pair
In-Reply-To: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>
Message-ID: <1574745400.48.0.613329232185.issue34716@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34716>
_______________________________________

From report at bugs.python.org  Tue Nov 26 00:17:14 2019
From: report at bugs.python.org (Bo Anderson)
Date: Tue, 26 Nov 2019 05:17:14 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1574745434.62.0.212632844332.issue38295@roundup.psfhosted.org>


Bo Anderson <bo at toxicflames.co.uk> added the comment:

For what it's worth, this is having an impact on some real code: https://github.com/Homebrew/homebrew-core/pull/45110

Perhaps a simpler way to reproduce is:

% cd /tmp
% python3 -c 'import os; open(os.path.relpath("/tmp/test.txt"), "w")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: '../../tmp/test.txt'

----------
nosy: +Bo98

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Nov 26 01:17:13 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Nov 2019 06:17:13 +0000
Subject: [issue38328] Speed up the creation time of constant list and set
 literals.
In-Reply-To: <1569862645.36.0.924344090693.issue38328@roundup.psfhosted.org>
Message-ID: <1574749033.07.0.723090482553.issue38328@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 6dd9b64770af8905bef293c81d541eaaf8d8df52 by Inada Naoki (Brandt Bucher) in branch 'master':
bpo-38328: Speed up the creation time of constant list and set display. (GH-17114)
https://github.com/python/cpython/commit/6dd9b64770af8905bef293c81d541eaaf8d8df52


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38328>
_______________________________________

From report at bugs.python.org  Tue Nov 26 01:17:35 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Nov 2019 06:17:35 +0000
Subject: [issue38328] Speed up the creation time of constant list and set
 literals.
In-Reply-To: <1569862645.36.0.924344090693.issue38328@roundup.psfhosted.org>
Message-ID: <1574749055.41.0.476398563729.issue38328@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy:  -inada.naoki
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38328>
_______________________________________

From report at bugs.python.org  Tue Nov 26 01:27:21 2019
From: report at bugs.python.org (danielen)
Date: Tue, 26 Nov 2019 06:27:21 +0000
Subject: [issue38913] Py_BuildValue("(s#O)",
 ...) segfaults if entered with exception raised
Message-ID: <1574749641.72.0.139840395561.issue38913@roundup.psfhosted.org>


New submission from danielen <daniele at grinta.net>:

The following code results in a segmentation fault in CPython 3.8 while executes fines (raises a SystemError) in CPython 3.7.

PyObject* debug(PyObject *self, PyObject *args)
{
        const char * debug = "debug";
        PyErr_SetString(PyExc_ValueError, "debug!");
        return Py_BuildValue("(s#O)", debug, strlen(debug), Py_None);
}

It seems necessary for the format string to contain both an instance of "s#" and "O" to trigger the bug.

I'm attaching a C module that reproduces the problem.

----------
components: Extension Modules
files: module.c
messages: 357485
nosy: danielen
priority: normal
severity: normal
status: open
title: Py_BuildValue("(s#O)", ...) segfaults if entered with exception raised
versions: Python 3.8
Added file: https://bugs.python.org/file48743/module.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38913>
_______________________________________

From report at bugs.python.org  Tue Nov 26 01:34:47 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Nov 2019 06:34:47 +0000
Subject: [issue38897] Example in socket documentation uses deprecated
 array.fromstring
In-Reply-To: <1574449156.01.0.686437832509.issue38897@roundup.psfhosted.org>
Message-ID: <1574750087.0.0.516273660859.issue38897@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38897>
_______________________________________

From report at bugs.python.org  Tue Nov 26 02:55:05 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Nov 2019 07:55:05 +0000
Subject: [issue27145] long_add and long_sub might return a new int where
 &small_ints[x] could be returned
In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za>
Message-ID: <1574754905.2.0.417133219676.issue27145@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 036fe85bd3e6cd01093d836d71792a1966f961e8 by Inada Naoki (HongWeipeng) in branch 'master':
bpo-27145: small_ints[x] could be returned in long_add and long_sub (GH-15716)
https://github.com/python/cpython/commit/036fe85bd3e6cd01093d836d71792a1966f961e8


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27145>
_______________________________________

From report at bugs.python.org  Tue Nov 26 02:55:28 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Nov 2019 07:55:28 +0000
Subject: [issue27145] long_add and long_sub might return a new int where
 &small_ints[x] could be returned
In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za>
Message-ID: <1574754928.67.0.408464206207.issue27145@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27145>
_______________________________________

From report at bugs.python.org  Tue Nov 26 03:20:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Nov 2019 08:20:48 +0000
Subject: [issue27145] long_add and long_sub might return a new int where
 &small_ints[x] could be returned
In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za>
Message-ID: <1574756448.62.0.940248172937.issue27145@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like there are a few corner cases where long integers are not normalized:
https://github.com/python/cpython/pull/15716#pullrequestreview-298002027

But the initial issue described here has been fixed, so it's better to keep this issue closed. If someone wants to cover more cases (to normalize), please open a separated issue.

Thanks HongWeipeng for the fix and Oren Milman for the original bug report and original patches!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27145>
_______________________________________

From report at bugs.python.org  Tue Nov 26 03:25:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Nov 2019 08:25:31 +0000
Subject: [issue38803] test_wait3 and test_wait4 leaked references on x86
 Gentoo Refleaks 3.x
In-Reply-To: <1573771592.29.0.825228162147.issue38803@roundup.psfhosted.org>
Message-ID: <1574756731.11.0.197213420635.issue38803@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for the fix Eddie Elizondo!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38803>
_______________________________________

From report at bugs.python.org  Tue Nov 26 03:33:37 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Nov 2019 08:33:37 +0000
Subject: [issue38897] Example in socket documentation uses deprecated
 array.fromstring
In-Reply-To: <1574449156.01.0.686437832509.issue38897@roundup.psfhosted.org>
Message-ID: <1574757217.53.0.68522269659.issue38897@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16869
pull_request: https://github.com/python/cpython/pull/17387

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38897>
_______________________________________

From report at bugs.python.org  Tue Nov 26 03:41:21 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Nov 2019 08:41:21 +0000
Subject: [issue38897] Example in socket documentation uses deprecated
 array.fromstring
In-Reply-To: <1574449156.01.0.686437832509.issue38897@roundup.psfhosted.org>
Message-ID: <1574757681.18.0.0669179286669.issue38897@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks David for the report and patch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38897>
_______________________________________

From report at bugs.python.org  Tue Nov 26 04:41:11 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Tue, 26 Nov 2019 09:41:11 +0000
Subject: [issue38914] Clarify wording for warning message when checking a
 package
Message-ID: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>


New submission from J?rgen Gmach <juergen.gmach at googlemail.com>:

When creating a package for PyPi, and naming an author, but not an author_email, you get a warning as follows:

warning: Check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too

The specs ( https://packaging.python.org/specifications/core-metadata/#author ) do not enforce this behavior, so I'd like to change the wording from `must` to `should`.

This can be reproduced by creating a setup.py, providing `author`, but not `author_email`, and then calling `python setup.py check` or `python -m pep517.build .`.

This issue was discussed at:
https://discuss.python.org/t/which-fields-are-required-for-a-setup-py-especially-is-author-required/2705
and
https://github.com/pypa/pep517/issues/73

Background:
I ported a 16 year old package to Python 3, and tried to upload it to PyPi. I know the author name, but not his email address. Also, I think he does not like to get bothered with emails for a project he abandoned 16 years ago.

P.S.: I am working on a PR for this and update this issue accordingly.

----------
components: Distutils
messages: 357490
nosy: dstufft, eric.araujo, jugmac00
priority: normal
severity: normal
status: open
title: Clarify wording for warning message when checking a package
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38914>
_______________________________________

From report at bugs.python.org  Tue Nov 26 05:07:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Nov 2019 10:07:17 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574762837.66.0.538987788358.issue26730@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Nov 26 05:17:05 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Nov 2019 10:17:05 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574763425.26.0.349931910544.issue26730@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Creating files is slow on Windows too.

But I think we should fix the data corruption ASAP.

While Serhiy's patch looks good to me, there is a more quick and safe way to fix the data corruption.  Use TemporaryFile at first if it is text mode.

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Nov 26 05:25:02 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Tue, 26 Nov 2019 10:25:02 +0000
Subject: [issue38914] Clarify wording for warning message when checking a
 package
In-Reply-To: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>
Message-ID: <1574763902.4.0.607749920136.issue38914@roundup.psfhosted.org>


Change by J?rgen Gmach <juergen.gmach at googlemail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38914>
_______________________________________

From report at bugs.python.org  Tue Nov 26 06:40:34 2019
From: report at bugs.python.org (Yan)
Date: Tue, 26 Nov 2019 11:40:34 +0000
Subject: [issue38915] 'r[/]*', str,
 re.MULTILINE | re.DOTALL Won't match // in a string in Python3.6.8
Message-ID: <1574768434.06.0.471895216723.issue38915@roundup.psfhosted.org>


New submission from Yan <yanioaioan at gmail.com>:

str="//"
matches = re.finditer('r[/]*', str, re.MULTILINE | re.DOTALL)
for match in matches:
    print(match.group(0))

The above will match double forward slash in Python2.7.15  but NOT in Python3.6.8.

----------
components: Library (Lib)
messages: 357492
nosy: yanioaioan
priority: normal
severity: normal
status: open
title: 'r[/]*', str, re.MULTILINE | re.DOTALL Won't match // in a string in Python3.6.8
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38915>
_______________________________________

From report at bugs.python.org  Tue Nov 26 06:58:06 2019
From: report at bugs.python.org (Yan)
Date: Tue, 26 Nov 2019 11:58:06 +0000
Subject: [issue38915] 'r[/]*', str,
 re.MULTILINE | re.DOTALL Won't match // in a string in Python3.6.8
In-Reply-To: <1574768434.06.0.471895216723.issue38915@roundup.psfhosted.org>
Message-ID: <1574769486.01.0.309232967151.issue38915@roundup.psfhosted.org>


Change by Yan <yanioaioan at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38915>
_______________________________________

From report at bugs.python.org  Tue Nov 26 08:35:39 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 26 Nov 2019 13:35:39 +0000
Subject: [issue38901] Add a CLI flag to venv to use the pwd basename as the
 prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1574775339.03.0.252715010317.issue38901@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Since there is already a --prompt available, I'd prefer a solution that allowed some special value(s) to be passed for this, e.g.

--prompt .

or perhaps

--prompt __curdir__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Tue Nov 26 08:49:06 2019
From: report at bugs.python.org (Joseph Reagle)
Date: Tue, 26 Nov 2019 13:49:06 +0000
Subject: [issue38910] AssertionError: ElementTree not initialized, missing root
In-Reply-To: <1574744766.3.0.945043071788.issue38910@roundup.psfhosted.org>
Message-ID: <f0abf184-55c9-8805-7cbf-1924c9620163@reagle.org>


Joseph Reagle <joseph.2011 at reagle.org> added the comment:

On 11/26/19 12:06 AM, Karthikeyan Singaravelan wrote:
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
> 
> This seems more like an issue with lxml.

I posted a report over there now too:

https://bugs.launchpad.net/lxml/+bug/1854057

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38910>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:08:48 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 26 Nov 2019 14:08:48 +0000
Subject: [issue38916] Remove array.fromstring
Message-ID: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

array.fromstring was deprecated at 3.2

IMHO, now we can remove array.fromstring.
For my research, there is no usage on the standard library.
I 'd like to propose that let's remove array.fromstring from 3.9

----------
components: Library (Lib)
messages: 357495
nosy: benjamin.peterson, corona10, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Remove array.fromstring
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:10:33 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 26 Nov 2019 14:10:33 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574777433.63.0.791206268904.issue38916@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I'd like to tag this issue as an easy issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:10:49 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 26 Nov 2019 14:10:49 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574777449.94.0.178108606699.issue38916@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +easy (C)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:13:26 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 26 Nov 2019 14:13:26 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574777606.86.0.241913364489.issue38916@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

For whom are interested in this issue,
Please wait until the core developer decides to approve this issue. :)
After that, we can review the PR for this issue.

Thank you for understanding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:13:51 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 26 Nov 2019 14:13:51 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574777631.18.0.388656383564.issue38916@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:20:16 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Nov 2019 14:20:16 +0000
Subject: [issue38914] Clarify wording for warning message when checking a
 package
In-Reply-To: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>
Message-ID: <1574778016.32.0.670234618814.issue38914@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

For your project, if you define maintainer and maintainer-email (with your own info), it?s too bad that adding author results in a warning for missing author-email!

The goal of these checks as I understand them is a best effort to encourage projects to contain contact information (and recognition for the work).  It seems legitimate to know the original author name but not email, and too bad that the simplest way to avoid the warning is to remove the author info.

I wonder if it would be going too far to change the checks to avoid the warning if we have author, maintainer and maintainer-email (or even more combinations? given that email format allows embedding a name directly there)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38914>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:20:49 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Nov 2019 14:20:49 +0000
Subject: [issue38914] Clarify wording for warning message when checking a
 package
In-Reply-To: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>
Message-ID: <1574778049.78.0.03125224378.issue38914@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
type: enhancement -> behavior
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38914>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:37:50 2019
From: report at bugs.python.org (Denis S. Otkidach)
Date: Tue, 26 Nov 2019 14:37:50 +0000
Subject: [issue36221] Setting PYTHONASYNCIODEBUG breaks warnings
In-Reply-To: <1551941918.68.0.578445039903.issue36221@roundup.psfhosted.org>
Message-ID: <1574779070.86.0.134276924255.issue36221@roundup.psfhosted.org>


Denis S. Otkidach <denis.otkidach at gmail.com> added the comment:

It's fixed in 3.8 final, but the problem persists in 3.7.5

----------
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36221>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:39:11 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Tue, 26 Nov 2019 14:39:11 +0000
Subject: [issue38914] Clarify wording for warning message when checking a
 package
In-Reply-To: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>
Message-ID: <1574779151.65.0.488705270062.issue38914@roundup.psfhosted.org>


J?rgen Gmach <juergen.gmach at googlemail.com> added the comment:

Thank you for your feedback.

Paul Ganssle suggested a updated wording over at
https://github.com/pypa/pep517/issues/73
so this is why I created a pr accordingly.

The intent of this issue and the pr is to minimize the confusion for a beginner with Python packaging (e.g myself) by doing something with the probably wrong word "must".

Changing the checks is another way to fix this issue, but it is beyond my scope to say one is better or the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38914>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:47:49 2019
From: report at bugs.python.org (Acid Ascorbic)
Date: Tue, 26 Nov 2019 14:47:49 +0000
Subject: [issue38917] Color setting doesn't work in tkinter
Message-ID: <1574779669.0.0.89145609827.issue38917@roundup.psfhosted.org>


New submission from Acid Ascorbic <ascorbic.acid.test2 at gmail.com>:

It is impossible to set colors properly in Treeview.
Python behavior is different between versions 3.6.2 and 3.7.3/3.8.0.
Origin: https://stackoverflow.com/questions/57634982/can-i-change-the-foreground-color-of-a-single-column-in-python-treeview/59047842
Example 1:

from tkinter import ttk
import tkinter as tk

root = tk.Tk()
tree = ttk.Treeview(root)
c = tree.insert('', 'end', text='This is critical message', tags='critical')
tree.insert(c, 'end', text='This is child of critical message', tags='critical')
for i in range(5):
    tree.insert('', 'end', text='This is non-critical message')
tree.tag_configure('critical', background='red', foreground="black")
tree.pack()
root.mainloop()

Example 2:

import tkinter as tk
from tkinter import ttk

root = tk.Tk()
style = ttk.Style(root)
style.theme_use("clam")
style.configure("Treeview", background="black",
                fieldbackground="black", foreground="white")
tree = ttk.Treeview(root)
tree.insert("", 0, "item", text="item")
tree.pack()
root.mainloop()

----------
components: Tkinter
messages: 357501
nosy: Acid Ascorbic
priority: normal
severity: normal
status: open
title: Color setting doesn't work in tkinter
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38917>
_______________________________________

From report at bugs.python.org  Tue Nov 26 09:54:36 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 26 Nov 2019 14:54:36 +0000
Subject: [issue38910] AssertionError: ElementTree not initialized, missing root
In-Reply-To: <1574724534.5.0.309453376726.issue38910@roundup.psfhosted.org>
Message-ID: <1574780076.07.0.468862555745.issue38910@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38910>
_______________________________________

From report at bugs.python.org  Tue Nov 26 10:27:12 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 26 Nov 2019 15:27:12 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
Message-ID: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The docs page for the inspect module has a large table describing the special attributes of various important types.  One entry for function attributes is missing: __module__.  It should be added.

Note that __module__ *is* included in the function attributes listed in the language reference. [2]

The same goes for the "method" (really "instance method") section of the table: it should also have __module__. [3]


[1] https://docs.python.org/3/library/inspect.html#types-and-members
[2] https://docs.python.org/3/reference/datamodel.html#index-34
[3] https://docs.python.org/3/reference/datamodel.html#index-36

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 357502
nosy: docs at python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Add __module__ entry for function type in inspect docs table.
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38918>
_______________________________________

From report at bugs.python.org  Tue Nov 26 10:32:01 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 26 Nov 2019 15:32:01 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1574782321.2.0.286988425528.issue36375@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Exactly. :)

I'd expect PEP 499 to specify changing __module__ of classes and functions from __main__ to the module name (__spec__.name).  This aligns closely with the whole point of the PEP. :)  As a bonus, it will simplify things for pickling (which doesn't inherently deal well with __main__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Tue Nov 26 11:12:20 2019
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 26 Nov 2019 16:12:20 +0000
Subject: [issue38913] Py_BuildValue("(s#O)",
 ...) segfaults if entered with exception raised
In-Reply-To: <1574749641.72.0.139840395561.issue38913@roundup.psfhosted.org>
Message-ID: <1574784740.13.0.579415630374.issue38913@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

seen with the current 3.8 branch.

----------
keywords: +3.8regression
nosy: +doko, lukasz.langa
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38913>
_______________________________________

From report at bugs.python.org  Tue Nov 26 11:14:49 2019
From: report at bugs.python.org (James Hennessy)
Date: Tue, 26 Nov 2019 16:14:49 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574784889.13.0.612337037857.issue26730@roundup.psfhosted.org>


James Hennessy <jhennessy0 at gmail.com> added the comment:

I have to disagree with the idea that SpooledTemporaryFile is not useful.  Although on some systems, the file system may appear as fast as memory, that cannot be assumed to be universally true.  I think the idea behind SpooledTemporaryFile is completely valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Nov 26 11:16:53 2019
From: report at bugs.python.org (James Hennessy)
Date: Tue, 26 Nov 2019 16:16:53 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574785013.52.0.251098868113.issue26730@roundup.psfhosted.org>


James Hennessy <jhennessy0 at gmail.com> added the comment:

I don't like the idea of using a TemporaryFile right from the beginning in text mode.  You might as well remove text mode support altogether if that's the approach you want to take, since it undoes any potential performance benefit of using SpooledTemporaryFile in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Nov 26 11:23:02 2019
From: report at bugs.python.org (mohamad khosravi)
Date: Tue, 26 Nov 2019 16:23:02 +0000
Subject: [issue38919] support Assignment Operators
Message-ID: <1574785382.07.0.788773831848.issue38919@roundup.psfhosted.org>


New submission from mohamad khosravi <khosravim861 at gmail.com>:

support "Assignment Operators":

x = "ME"
while len(x:*=2) < 64:print("value doubled!")

----------
messages: 357507
nosy: mohamad khosravi
priority: normal
severity: normal
status: open
title: support Assignment Operators
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38919>
_______________________________________

From report at bugs.python.org  Tue Nov 26 11:26:27 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 26 Nov 2019 16:26:27 +0000
Subject: [issue38914] Clarify wording for warning message when checking a
 package
In-Reply-To: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>
Message-ID: <1574785587.72.0.307355903986.issue38914@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

For the future, we generally tend to keep distutils pretty "frozen", only making minor changes or the changes needed to build Python itself. Instead we generally make changes in setuptools, which for the moment monkey-patches distutils (and into which distutils will eventually be merged). One of the big reasons is that setuptools is used across all versions of Python, so the changes are automatically backported, whereas changes to distutils will only be seen by people using the most recent Python versions.

In this case, it's not really a substantive change, so I think we can leave it in distutils, I just wanted to bring this up as an FYI.

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38914>
_______________________________________

From report at bugs.python.org  Tue Nov 26 11:38:48 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Nov 2019 16:38:48 +0000
Subject: [issue22377] %Z in strptime doesn't match EST and others
In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za>
Message-ID: <1574786328.52.0.691470370805.issue22377@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bc441ed7c1449f06df37905ee6289aa93b85d4cb by Miss Islington (bot) (Karl Dubost) in branch 'master':
bpo-22377: Fixes documentation for %Z in datetime (GH-16507)
https://github.com/python/cpython/commit/bc441ed7c1449f06df37905ee6289aa93b85d4cb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22377>
_______________________________________

From report at bugs.python.org  Tue Nov 26 11:50:01 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Nov 2019 16:50:01 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574787001.44.0.101102473032.issue26730@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

But poor performance is better than silent data corruption.
If we can not fix the rollover right now, stop the spooling is a considerable option for next bugfix release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Nov 26 11:54:02 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Nov 2019 16:54:02 +0000
Subject: [issue38919] support Assignment Operators
In-Reply-To: <1574785382.07.0.788773831848.issue38919@roundup.psfhosted.org>
Message-ID: <1574787242.68.0.227233038413.issue38919@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This needs to be discussed on python-ideas mailing list. Inplace operation for walrus operator like :*= feels difficulty to read than (x := x * 2) and would require changes to grammar.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38919>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:05:01 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 17:05:01 +0000
Subject: [issue38913] Py_BuildValue("(s#O)",
 ...) segfaults if entered with exception raised
In-Reply-To: <1574749641.72.0.139840395561.issue38913@roundup.psfhosted.org>
Message-ID: <1574787901.26.0.694573308476.issue38913@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Does it depend on whether PY_SSIZE_T_CLEAN is defined?

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38913>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:07:59 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 17:07:59 +0000
Subject: [issue38892] Audit Hook doc typos and confusion
In-Reply-To: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>
Message-ID: <1574788079.19.0.936387716066.issue38892@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset e563a155be60fc0757914f87c8138f10de00bb16 by Steve Dower (Terry Jan Reedy) in branch 'master':
bpo-38892: Improve docs for audit event (GH-17361)
https://github.com/python/cpython/commit/e563a155be60fc0757914f87c8138f10de00bb16


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38892>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:08:12 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Nov 2019 17:08:12 +0000
Subject: [issue38892] Audit Hook doc typos and confusion
In-Reply-To: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>
Message-ID: <1574788092.79.0.191967551903.issue38892@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16873
pull_request: https://github.com/python/cpython/pull/17391

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38892>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:10:31 2019
From: report at bugs.python.org (danielen)
Date: Tue, 26 Nov 2019 17:10:31 +0000
Subject: [issue38913] Py_BuildValue("(s#O)",
 ...) segfaults if entered with exception raised
In-Reply-To: <1574749641.72.0.139840395561.issue38913@roundup.psfhosted.org>
Message-ID: <1574788231.35.0.983688401662.issue38913@roundup.psfhosted.org>


danielen <daniele at grinta.net> added the comment:

It is not reproducible with PY_SSIZE_T_CLEAN defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38913>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:12:35 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 17:12:35 +0000
Subject: [issue38892] Audit Hook doc typos and confusion
In-Reply-To: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>
Message-ID: <1574788355.89.0.655385403208.issue38892@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks Terry!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38892>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:14:54 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Nov 2019 17:14:54 +0000
Subject: [issue38892] Audit Hook doc typos and confusion
In-Reply-To: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>
Message-ID: <1574788494.95.0.443569163864.issue38892@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 86d9933cc627c4232f9702ca0766713714ebbc53 by Miss Islington (bot) in branch '3.8':
bpo-38892: Improve docs for audit event (GH-17361)
https://github.com/python/cpython/commit/86d9933cc627c4232f9702ca0766713714ebbc53


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38892>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:15:28 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 17:15:28 +0000
Subject: [issue38920] Audit events for unhandled exceptions
Message-ID: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

We currently have no audit events for unhandled exceptions.

While these can be recorded by sys.excepthook or sys.unraisablehook in Python code, there is no way to intercept them from C code set up before running Python code. There's also no way to collect information about what hook is running, in the case where Python code may have overridden it (for example, to suppress error reporting when malicious code fails).

----------
messages: 357517
nosy: steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Audit events for unhandled exceptions
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:21:02 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 17:21:02 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1574788862.32.0.614522545775.issue38920@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:21:33 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 17:21:33 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1574788893.17.0.566884874088.issue38920@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:23:12 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Nov 2019 17:23:12 +0000
Subject: [issue38919] support Assignment Operators
In-Reply-To: <1574785382.07.0.788773831848.issue38919@roundup.psfhosted.org>
Message-ID: <1574788992.21.0.131499283766.issue38919@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Agreed with Karthikeyan.  This is a PEP-level change, meaning it will first need to find some approval on python-ideas, a PEP will need to be written and eventually approved before an issue should be opened to implement the change; thus I'm closing this issue as "rejected".  I will warn you that it's very unlikely that this will make it through that process, but you are welcome to try :)

----------
components: +Interpreter Core
nosy: +zach.ware
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38919>
_______________________________________

From report at bugs.python.org  Tue Nov 26 12:31:37 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 17:31:37 +0000
Subject: [issue38905] venv python reports wrong sys.executable in a subprocess
 on Windows
In-Reply-To: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>
Message-ID: <1574789497.11.0.0779021545947.issue38905@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> But then I need two separate workflows based on what is passed in. For py.exe I need to run it and get sys.executable. But for python.exe I *cannot* use sys.executable because that?s the base interepeter, not the venv path I want. And `if Path(arg).stem == "py"` just seems like a bug waiting to happen.

If you use shutil.which() to resolve "python" or "py" against PATH (which doesn't include the application directory), then you'll get the full path to the correct python.exe and will get the expected sys.executable. So it's only one flow that works for both once you add the shutil.which step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38905>
_______________________________________

From report at bugs.python.org  Tue Nov 26 13:15:42 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 26 Nov 2019 18:15:42 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1574415736.34.0.914530277604.issue38021@roundup.psfhosted.org>
Message-ID: <68fc0e45-22b2-e1ec-80f3-7928c1d77eac@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 22/11/2019 10:42, Paul Moore wrote:
> Paul Moore <p.f.moore at gmail.com> added the comment:
>
> PyPA member here - if this PR is defining new compatibility tags,
replacement platform_tag, not compatibility tag.
>  I would have expected it to need discussion as a revision to PEP 425, much like the manylinux efforts did. (It may actually be a closer parallel with MacOS, which didn't have a tagging PEP - I'm not sure how that would relate here, but as MacOS is a much more mainstream platform I'd be inclined to err on the side of caution and look for AIX to be explicitly covered in the tag specs).

As I understand the 'manylinux*' compatibility tags - which are used as
a replacement for platform tags - these compatibility tags are added on
by the packager who works in a carefully configured environment in order
to support binary compatibility over multiple Linux distributions and
releases.

Before AIX 6.1 binary compatibility in AIX was not guaranteed upfront.
Starting with AIX 6.1 IBM has a policy of guaranteeing binary
compatibility for applications.

>From https://www.recarta.co.uk/our-partners/software-partners/ibm-aix/

This page, from IBM, speaks of binary compatibility even going back to
AIX 3.2 -
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/install/binary_compatability.html

So, again - the PR is to provide an adequate platform tag. As is, an
adequate tag works on equality. Once the platform tag is established -
then - "we" (I guess that will mean me writing and "the community"
providing feedback) can look at how to use the tags over different
`releases` of AIX. Like MacOS, unlike Linux - there is only one distributor.

I am willing to work on an informational PEP - as long as waiting for
that process to complete does not mean an adequate platform_tag is left
in limbo for months to years. This new PEP would have two pieces - a)
describe the AIX platform tag; b) describe how tags of different
releases are compared and accepted or rejected as binary compatible.

Please note: the PR does not address any aspect of point b). Without
point a) there is no basis for point b).

Sincerely,

Michael

>
> I thought that was something that had been discussed on the Pip tracker, but maybe the implications weren't clear (I don't really understand the AIX scheme, so I'm relying on someone else, probably Michael, to propose something that could be added to PEP 425 and to lead/guide the discussion).
>
> ----------
> nosy: +paul.moore
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38021>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Tue Nov 26 13:28:11 2019
From: report at bugs.python.org (James Hennessy)
Date: Tue, 26 Nov 2019 18:28:11 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574792891.16.0.729587440926.issue26730@roundup.psfhosted.org>


James Hennessy <jhennessy0 at gmail.com> added the comment:

The quickest fix for the data corruption problem is to delete the line
    newfile.seek(file.tell(), 0)
from the rollover() method.

This doesn't fix the inconsistency of tell() and seek(), but it's very low risk.  It's technically a change to the API, that rollover() no longer preserves the seek position, but unless the user was writing only characters from the ISO-8859-1 character set, it wasn't working properly before anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Nov 26 13:30:42 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 26 Nov 2019 18:30:42 +0000
Subject: [issue27501] Add typing.py class describing a PEP 3118 buffer object
In-Reply-To: <1468346843.82.0.455431578723.issue27501@psf.upfronthosting.co.za>
Message-ID: <1574793042.7.0.856095681749.issue27501@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Cross-ref to the typing issue https://github.com/python/typing/issues/593. It looks like there is some interest in this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27501>
_______________________________________

From report at bugs.python.org  Tue Nov 26 13:39:43 2019
From: report at bugs.python.org (Joy)
Date: Tue, 26 Nov 2019 18:39:43 +0000
Subject: [issue38921] Max Recursion Depth Reached in Logging Library
Message-ID: <1574793583.29.0.769726111814.issue38921@roundup.psfhosted.org>


New submission from Joy <joy.bushnell at gmail.com>:

Seeing an issue with the logger fmt not setting correctly in the Handler class. Our code calls format many times which works for a while and then we receive the following errors:

[3206] 2019/11/26 12:42:31.011> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1725, in info
[3206] 2019/11/26 12:42:31.013> [ERROR] self.log(INFO, msg, *args, **kwargs)
[3206] 2019/11/26 12:42:31.014> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1763, in log
[3206] 2019/11/26 12:42:31.016> [ERROR] self.logger.log(level, msg, *args, **kwargs)
[3206] 2019/11/26 12:42:31.017> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1444, in log
[3206] 2019/11/26 12:42:31.018> [ERROR] self._log(level, msg, args, **kwargs)
[3206] 2019/11/26 12:42:31.019> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1514, in _log
[3206] 2019/11/26 12:42:31.021> [ERROR] self.handle(record)
[3206] 2019/11/26 12:42:31.022> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1524, in handle
[3206] 2019/11/26 12:42:31.024> [ERROR] self.callHandlers(record)
[3206] 2019/11/26 12:42:31.025> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1586, in callHandlers
[3206] 2019/11/26 12:42:31.026> [ERROR] hdlr.handle(record)
[3206] 2019/11/26 12:42:31.027> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 894, in handle
[3206] 2019/11/26 12:42:31.029> [ERROR] self.emit(record)
[3206] 2019/11/26 12:42:31.029> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1127, in emit
[3206] 2019/11/26 12:42:31.031> [ERROR] StreamHandler.emit(self, record)
[3206] 2019/11/26 12:42:31.032> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1025, in emit
[3206] 2019/11/26 12:42:31.033> [ERROR] msg = self.format(record)
[3206] 2019/11/26 12:42:31.035> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
[3206] 2019/11/26 12:42:31.036> [ERROR] return fmt.format(record)
[3206] 2019/11/26 12:42:31.037> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
[3206] 2019/11/26 12:42:31.039> [ERROR] return fmt.format(record)
[3206] 2019/11/26 12:42:31.040> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
[3206] 2019/11/26 12:42:31.041> [ERROR] return fmt.format(record)
[3206] 2019/11/26 12:42:31.042> [ERROR]   [Previous line repeated 978 more times]
[3206] 2019/11/26 12:42:31.043> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 608, in format
[3206] 2019/11/26 12:42:31.045> [ERROR] record.message = record.getMessage()
[3206] 2019/11/26 12:42:31.046> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 367, in getMessage
[3206] 2019/11/26 12:42:31.048> [ERROR] msg = str(self.msg)
[3206] 2019/11/26 12:42:31.049> [ERROR] RecursionError
[3206] 2019/11/26 12:42:31.049> [ERROR] :
[3206] 2019/11/26 12:42:31.050> [ERROR] maximum recursion depth exceeded while calling a Python object


I believe after a while the fmt object is not being set correctly and ends up calling the Handler's format function again and again.

----------
components: Library (Lib)
messages: 357523
nosy: joy
priority: normal
severity: normal
status: open
title: Max Recursion Depth Reached in Logging Library
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38921>
_______________________________________

From report at bugs.python.org  Tue Nov 26 13:39:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 18:39:57 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1574793597.74.0.793977237593.issue38920@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +16875
pull_request: https://github.com/python/cpython/pull/17393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Tue Nov 26 14:10:20 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Nov 2019 19:10:20 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574795420.03.0.0546236446853.issue38916@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

If it was documented as deprecated and raising a deprecation warning then 3.2 is definitely far enough back to warrant removing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Tue Nov 26 14:10:32 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 26 Nov 2019 19:10:32 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574795432.86.0.896112685257.issue38021@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

> replacement platform_tag, not compatibility tag.

Ah, I see, sorry. In that case, this should be fine, it's purely a CPython question. There's obviously a follow-on discussion about how that platform tag is *incorporated* into the compatibility tags, but as you say, that's a separate point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Tue Nov 26 14:29:00 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Nov 2019 19:29:00 +0000
Subject: [issue38921] Max Recursion Depth Reached in Logging Library
In-Reply-To: <1574793583.29.0.769726111814.issue38921@roundup.psfhosted.org>
Message-ID: <1574796540.51.0.984924162129.issue38921@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please attach a simple script to reproduce the issue?

----------
nosy: +vinay.sajip, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38921>
_______________________________________

From report at bugs.python.org  Tue Nov 26 14:51:24 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Nov 2019 19:51:24 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574797883.99.0.164459268355.issue38916@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Although I will admit we have not had a discussion on python-dev about removing stuff that was left for Python 2.7 compatibility, so that discussion should probably occur first before we go ripping stuff out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Tue Nov 26 15:02:31 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Nov 2019 20:02:31 +0000
Subject: [issue21063] Touch up one-line descriptions of modules for module
 index
In-Reply-To: <1395763211.53.0.0504974625449.issue21063@psf.upfronthosting.co.za>
Message-ID: <1574798551.05.0.943698127592.issue21063@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 2f2489310d89f589a091aa09ac1eb973d9a383d8 by Brett Cannon (Miss Islington (bot)) in branch '3.7':
bpo-21063: Improve module synopsis for distutils (GH-17363) (#17381)
https://github.com/python/cpython/commit/2f2489310d89f589a091aa09ac1eb973d9a383d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21063>
_______________________________________

From report at bugs.python.org  Tue Nov 26 15:13:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 20:13:46 +0000
Subject: [issue38922] code.replace() does not raise audit event
Message-ID: <1574799226.23.0.693103985318.issue38922@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Because code.replace() manually creates a new code object (that is, with arbitrary co_code rather than via the compiler), it should raise code.__new__ with its arguments.

----------
assignee: steve.dower
messages: 357529
nosy: steve.dower
priority: normal
severity: normal
status: open
title: code.replace() does not raise audit event
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38922>
_______________________________________

From report at bugs.python.org  Tue Nov 26 15:14:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 20:14:46 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1574799286.02.0.400627801464.issue38920@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

+Victor in case you'd like to check my changes to the unraisable hook implementation.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Tue Nov 26 15:22:01 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 20:22:01 +0000
Subject: [issue38922] code.replace() does not raise audit event
In-Reply-To: <1574799226.23.0.693103985318.issue38922@roundup.psfhosted.org>
Message-ID: <1574799721.78.0.303755379603.issue38922@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38922>
_______________________________________

From report at bugs.python.org  Tue Nov 26 16:22:27 2019
From: report at bugs.python.org (Brian Kardon)
Date: Tue, 26 Nov 2019 21:22:27 +0000
Subject: [issue38923] Spurious OSError "Not enough memory resources" when
 allocating memory using multiprocessing.RawArray
Message-ID: <1574803347.18.0.0106891265005.issue38923@roundup.psfhosted.org>


New submission from Brian Kardon <brian.kardon at gmail.com>:

When I try to create a series of multiprocessing.RawArray objects, I get an "OSError: Not enough memory resources are available to process this command". However, by my calculations, the total amount of memory I'm trying to allocate is just about 1 GB, and my system reports that it has around 20 GB free memory. I can't find any information about any artificial memory limit, and my system seems to have plenty of memory for this, so it seems like a bug to me. This is my first issue report, so I apologize if I'm doing this wrong.

The attached script produces the following output on my Windows 10 64-bit machine with Python 3.7:

Creating buffer # 0
Creating buffer # 1
Creating buffer # 2
Creating buffer # 3
Creating buffer # 4
...etc...
Creating buffer # 276
Creating buffer # 277
Creating buffer # 278
Creating buffer # 279
Creating buffer # 280
Traceback (most recent call last):
  File ".\Cruft\memoryErrorTest.py", line 10, in <module>
    buffers.append(mp.RawArray(imageDataType, imageDataSize))
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\context.py", line 129, in RawArray
    return RawArray(typecode_or_type, size_or_initializer)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\sharedctypes.py", line 61, in RawArray
    obj = _new_value(type_)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\sharedctypes.py", line 41, in _new_value
    wrapper = heap.BufferWrapper(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 263, in __init__
    block = BufferWrapper._heap.malloc(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 242, in malloc
    (arena, start, stop) = self._malloc(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 134, in _malloc
    arena = Arena(length)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 38, in __init__
    buf = mmap.mmap(-1, size, tagname=name)
OSError: [WinError 8] Not enough memory resources are available to process this command

----------
components: Library (Lib), Windows, ctypes
files: memoryErrorTest.py
messages: 357531
nosy: bkardon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Spurious OSError "Not enough memory resources" when allocating memory using multiprocessing.RawArray
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48744/memoryErrorTest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38923>
_______________________________________

From report at bugs.python.org  Tue Nov 26 16:52:38 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Nov 2019 21:52:38 +0000
Subject: [issue38923] Spurious OSError "Not enough memory resources" when
 allocating memory using multiprocessing.RawArray
In-Reply-To: <1574803347.18.0.0106891265005.issue38923@roundup.psfhosted.org>
Message-ID: <1574805158.42.0.0465474532131.issue38923@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

You appear to be using a 32-bit version of Python on Windows; do you get the same behavior using the 64-bit version?

----------
components:  -ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38923>
_______________________________________

From report at bugs.python.org  Tue Nov 26 17:17:56 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 26 Nov 2019 22:17:56 +0000
Subject: [issue38923] Spurious OSError "Not enough memory resources" when
 allocating memory using multiprocessing.RawArray
In-Reply-To: <1574803347.18.0.0106891265005.issue38923@roundup.psfhosted.org>
Message-ID: <1574806676.83.0.0267029086994.issue38923@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Good catch, Zach! A 32bit version of Python would certainly explain your problem. A 32bit process can only address 4 GB of address space. Almost half of the address space is reserved for OS, stack, Python itself, and other things. That leaves a little more than 2 GB of free heap memory for user data. Due to memory fragmentation it is possible that the allocator can't find a continuous free block 1 GB.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38923>
_______________________________________

From report at bugs.python.org  Tue Nov 26 17:23:45 2019
From: report at bugs.python.org (=?utf-8?b?SW9udcibIENpb2PDrnJsYW4=?=)
Date: Tue, 26 Nov 2019 22:23:45 +0000
Subject: [issue38924] pathlib paths .normalize()
Message-ID: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>


New submission from Ionu? Cioc?rlan <ionut.ciocirlan at gmail.com>:

pathlib paths should expose a `.normalize()` method. This is highly useful, especially in web-related scenarios.

On `PurePath` its usefulness is obvious, but it's debatable for `Path`, as it would yield different results from `.resolve()` in case of symlinks (which resolves them before normalizing).

----------
components: Library (Lib)
messages: 357534
nosy: iciocirlan
priority: normal
severity: normal
status: open
title: pathlib paths .normalize()
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38924>
_______________________________________

From report at bugs.python.org  Tue Nov 26 17:36:06 2019
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 26 Nov 2019 22:36:06 +0000
Subject: [issue38045] enum.Flag instance creation is slow
In-Reply-To: <1567772280.73.0.782923595007.issue38045@roundup.psfhosted.org>
Message-ID: <1574807766.41.0.682266447334.issue38045@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 0b41a922f95f62b620d5a197b9f2ed8e4bb70730 by Ethan Furman (HongWeipeng) in branch 'master':
bpo-38045: Improve the performance of _decompose() in enum.py (GH-16483)
https://github.com/python/cpython/commit/0b41a922f95f62b620d5a197b9f2ed8e4bb70730


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38045>
_______________________________________

From report at bugs.python.org  Tue Nov 26 17:44:07 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Tue, 26 Nov 2019 22:44:07 +0000
Subject: [issue38914] Clarify wording for warning message when checking a
 package
In-Reply-To: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>
Message-ID: <1574808247.76.0.293040202535.issue38914@roundup.psfhosted.org>


J?rgen Gmach <juergen.gmach at googlemail.com> added the comment:

Thank you, both of you!

I especially appreciate the further information about how setuptools and distutils play together.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38914>
_______________________________________

From report at bugs.python.org  Tue Nov 26 17:45:32 2019
From: report at bugs.python.org (Sebastian Szwarc)
Date: Tue, 26 Nov 2019 22:45:32 +0000
Subject: [issue38925] Decoding unicode not supported after upd to 2.7.17
 [possible pymysql related?]
Message-ID: <1574808332.82.0.628068067635.issue38925@roundup.psfhosted.org>


New submission from Sebastian Szwarc <seba.szwarc at gmail.com>:

As follow up to my recent bug error regarding segmentation fault.
Installed 2.7.17 on Mojave.
Because MySQLdb for reason unknown (SSL required error) is impossible to install by PIP I used PyMysql and modified line as `import pymysql as MySQLdb`

There is no segmentation fault for now (what indicates there can be bug in older python interpreter) but:
the following line worked fine for 2+ years:

colVals = unicode(", ".join(stringList), 'utf-8')

however now I got the error:
2019-11-26 23:25:55,273 [INFO]: Beginning incremental ingest of epf_video_price (200589 records)
Traceback (most recent call last):
  File "EPFImporter2.py", line 453, in <module>
    main()
  File "EPFImporter2.py", line 436, in main
    fieldDelim=fieldSep)
  File "EPFImporter2.py", line 221, in doImport
    ing.ingest(skipKeyViolators=skipKeyViolators)
  File "/Users/sebastian/Documents/test2/EPFIngester.py", line 111, in ingest
    self.ingestIncremental(skipKeyViolators=skipKeyViolators)
  File "/Users/sebastian/Documents/test2/EPFIngester.py", line 206, in ingestIncremental
    skipKeyViolators=skipKeyViolators)
  File "/Users/sebastian/Documents/test2/EPFIngester.py", line 375, in _populateTable
    colVals = unicode(", ".join(stringList), 'utf-8')
TypeError: decoding Unicode is not supported

So the questions:
1. why decoding Unicode is not supported if previously was and worked fine?
2. is it python thing or some pymysql enforcing rules ?


For reference I attached populateTable function

----------
components: macOS
files: populateTable.txt
messages: 357537
nosy: Sebastian Szwarc, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Decoding unicode not supported after upd to 2.7.17 [possible pymysql related?]
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file48745/populateTable.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38925>
_______________________________________

From report at bugs.python.org  Tue Nov 26 17:51:08 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Nov 2019 22:51:08 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574808668.85.0.323911664037.issue38916@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thoughts:
* The tostring() method should be handled in the same way.
* Remediation is easy because from_bytes() is a alias
* Still, all removals cause disruption from at least some users
* The only real benefit of removing it is a sense of tidiness;
  otherwise, there's no harm to keeping it (it's not broken).
* The other deprecation in the array module says, "Deprecated since
  version 3.3, will be removed in version 4.0".  Perhaps this
  one should have had the same qualifier.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Tue Nov 26 18:33:45 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 26 Nov 2019 23:33:45 +0000
Subject: [issue38925] Decoding unicode not supported after upd to 2.7.17
 [possible pymysql related?]
In-Reply-To: <1574808332.82.0.628068067635.issue38925@roundup.psfhosted.org>
Message-ID: <1574811225.55.0.718255637428.issue38925@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Hi Sebastian,

It will help if you do some minimal debugging before reporting what you think is a bug. Also, you should report what version you are upgrading from, not just the version you have upgraded to.

It may help you to provide better bug reports if you read this: http://sscce.org/

"Dcoding unicode" does not make sense and never did, and hasn't been supported since since at least version 2.4:

    py> unicode(u'a', 'uft-8')
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: decoding Unicode is not supported

One *encodes* Unicode to bytes, and *decodes* bytes to Unicode.

What I believe is happening is that somewhere, somehow, your ``stringList`` variable has a Unicode string object in it, rather than all byte-strings. Calling `', '.join(stringList)` returns a Unicode string if any item in the list is Unicode.

I'm closing this as "Not a bug" as it is not a bug in the language.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38925>
_______________________________________

From report at bugs.python.org  Tue Nov 26 19:13:37 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 27 Nov 2019 00:13:37 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1574813617.47.0.985360367811.issue18233@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

There's another important use case for this, that hasn't been discussed here. If you want to use openssl for TLS + the system trust store to verify certificates, then you need to disable openssl's certificate validation, perform the handshake, and then extract the certificate chain that there peer sent and pass it to the system native APIs to validate.

For this case, we don't need to do any validation or resolution on the chain ? we just want to pull out the DER that the peer sent. AFAICT, the lack of this functionality is the one major blocker to using the system trust store with the 'ssl' module.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Tue Nov 26 19:21:46 2019
From: report at bugs.python.org (Brian Kardon)
Date: Wed, 27 Nov 2019 00:21:46 +0000
Subject: [issue38923] Spurious OSError "Not enough memory resources" when
 allocating memory using multiprocessing.RawArray
In-Reply-To: <1574803347.18.0.0106891265005.issue38923@roundup.psfhosted.org>
Message-ID: <1574814106.76.0.684554404318.issue38923@roundup.psfhosted.org>


Brian Kardon <brian.kardon at gmail.com> added the comment:

Ah, thank you so much! That makes sense. I'll have to switch to 64-bit python. 

I've marked this as closed - hope that's the right thing to do here.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38923>
_______________________________________

From report at bugs.python.org  Tue Nov 26 19:27:54 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Nov 2019 00:27:54 +0000
Subject: [issue38922] code.replace() does not raise audit event
In-Reply-To: <1574799226.23.0.693103985318.issue38922@roundup.psfhosted.org>
Message-ID: <1574814474.07.0.720331263228.issue38922@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset c7c01ab1e5415b772c68e15f1aba51e520010830 by Steve Dower in branch 'master':
bpo-38922: Raise code.__new__ audit event when code object replace() is called (GH-17394)
https://github.com/python/cpython/commit/c7c01ab1e5415b772c68e15f1aba51e520010830


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38922>
_______________________________________

From report at bugs.python.org  Tue Nov 26 19:28:04 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Nov 2019 00:28:04 +0000
Subject: [issue38922] code.replace() does not raise audit event
In-Reply-To: <1574799226.23.0.693103985318.issue38922@roundup.psfhosted.org>
Message-ID: <1574814484.06.0.226916434508.issue38922@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16877
pull_request: https://github.com/python/cpython/pull/17396

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38922>
_______________________________________

From report at bugs.python.org  Tue Nov 26 19:28:36 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Nov 2019 00:28:36 +0000
Subject: [issue38922] code.replace() does not raise audit event
In-Reply-To: <1574799226.23.0.693103985318.issue38922@roundup.psfhosted.org>
Message-ID: <1574814516.91.0.691531638855.issue38922@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38922>
_______________________________________

From report at bugs.python.org  Tue Nov 26 19:46:36 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Nov 2019 00:46:36 +0000
Subject: [issue38922] code.replace() does not raise audit event
In-Reply-To: <1574799226.23.0.693103985318.issue38922@roundup.psfhosted.org>
Message-ID: <1574815596.1.0.343274690461.issue38922@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 191f94cca6f8cf59535e7459c1113e4a1cdfe201 by Miss Islington (bot) in branch '3.8':
bpo-38922: Raise code.__new__ audit event when code object replace() is called (GH-17394)
https://github.com/python/cpython/commit/191f94cca6f8cf59535e7459c1113e4a1cdfe201


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38922>
_______________________________________

From report at bugs.python.org  Tue Nov 26 20:10:53 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 27 Nov 2019 01:10:53 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574817053.5.0.686892257494.issue38688@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:


New changeset 9bbcbc9f6dfe1368fe7330b117707f828e6a2c18 by Giampaolo Rodola (Bruno P. Kinoshita) in branch 'master':
bpo-38688, shutil.copytree: consume iterator and create list of entries to prevent infinite recursion (GH-17098)
https://github.com/python/cpython/commit/9bbcbc9f6dfe1368fe7330b117707f828e6a2c18


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Tue Nov 26 20:12:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Nov 2019 01:12:59 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574817179.73.0.98360987564.issue38862@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 2fb971940b18bcf5a58b1b242b697d0f1d8ad7ef by Terry Jan Reedy in branch '3.7':
[3.7] bpo-38862: IDLE Strip Trailing Whitespace fixes end newlines  (GH-17366) (#17379)
https://github.com/python/cpython/commit/2fb971940b18bcf5a58b1b242b697d0f1d8ad7ef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Tue Nov 26 20:13:16 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 27 Nov 2019 01:13:16 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574817196.58.0.790357504498.issue38688@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
stage: patch review -> commit review
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Tue Nov 26 20:13:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Nov 2019 01:13:26 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574817206.65.0.688255942304.issue38862@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset a9c86f5e1afa2487524b1947153953b583714d62 by Terry Jan Reedy in branch '3.8':
[3.8] bpo-38862: IDLE Strip Trailing Whitespace fixes end newlines  (GH-17366)
https://github.com/python/cpython/commit/a9c86f5e1afa2487524b1947153953b583714d62


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Tue Nov 26 20:13:58 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Nov 2019 01:13:58 +0000
Subject: [issue38862] IDLE: Include end newlines in whitespace fix.
In-Reply-To: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>
Message-ID: <1574817238.04.0.166412602981.issue38862@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38862>
_______________________________________

From report at bugs.python.org  Tue Nov 26 20:31:25 2019
From: report at bugs.python.org (Andy Maier)
Date: Wed, 27 Nov 2019 01:31:25 +0000
Subject: [issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
In-Reply-To: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>
Message-ID: <1574818285.35.0.868700474356.issue38810@roundup.psfhosted.org>


Andy Maier <andreas.r.maier at gmx.de> added the comment:

Our user was able to fix this issue by upgrading the OpenSSL version used on the client side from 1.0.1e-fips to 1.1.1.

It seems to me that Python's SSL support cannot do anything about this issue. As far as I'm concerned ths issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38810>
_______________________________________

From report at bugs.python.org  Tue Nov 26 20:32:14 2019
From: report at bugs.python.org (Andy Maier)
Date: Wed, 27 Nov 2019 01:32:14 +0000
Subject: [issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
In-Reply-To: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>
Message-ID: <1574818334.71.0.845725246648.issue38810@roundup.psfhosted.org>


Andy Maier <andreas.r.maier at gmx.de> added the comment:

Thanks for the help, Christian!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38810>
_______________________________________

From report at bugs.python.org  Tue Nov 26 21:11:04 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Wed, 27 Nov 2019 02:11:04 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574820664.13.0.109345540721.issue38688@roundup.psfhosted.org>


Change by Bruno P. Kinoshita <brunodepaulak at yahoo.com.br>:


----------
pull_requests: +16878
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/17397

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Tue Nov 26 21:30:57 2019
From: report at bugs.python.org (Jeff Berkowitz)
Date: Wed, 27 Nov 2019 02:30:57 +0000
Subject: [issue38926] MacOS: 'Install certificates.command' has no effect
Message-ID: <1574821857.22.0.986895903547.issue38926@roundup.psfhosted.org>


New submission from Jeff Berkowitz <pdxjjb at gmail.com>:

After using the Python-supported installer to install 3.8.0 on my employer-owned Mac running High Sierra (10.13.6), the 'Install Certificates.command' had no apparently effect on the behavior of Python.

The behavior before executing the script was that a Python program using urllib3 was unable to verify that public certificate of github.com. Using curl, I could download via the desired URL. But the Python program could not, consistently throwing SSL verify errors instead.

I ran the command script several times. I verified that the symlink cert.pem was created in /Library/Frameworks/Python.framework/Versions/3.8/etc/openssl and that it contained "../../lib/python3.8/site-packages/certifi/cacert.pem" and I verified that the latter file had content (4558 lines) and was readable. And that it did contain the root cert for Github.

But despite that and despite multiple new shell windows and so on, I could never get Python to regard the certs. I eventually worked around this by: export SSL_CERT_FILE=/etc/ssl/cert.pem. After this, the Python program using urllib3 could verify Github.com's public cert. But as I understand things, this env var is actually regarded by the OpenSSL "C" library itself, not Python.(?) Which, if true, raises the question of why this was necessary.

Of course, there's quite likely something in my environment that is causing this. But it would be nice to know what.

----------
components: macOS
messages: 357549
nosy: Jeff Berkowitz, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: MacOS: 'Install certificates.command' has no effect
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38926>
_______________________________________

From report at bugs.python.org  Tue Nov 26 21:59:03 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 27 Nov 2019 02:59:03 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574823543.48.0.356973921094.issue26730@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

@Serhiy, would you create a pull request based on your patch?  Or may I?

@James it doesn't make sense at all.  It breaks the file even when only ASCII characters are used.

f = SpooledTemporaryFile(mode="w+")
f.write("foobar")
f.seek(3)
f.rollover()
f.write("baz")

----------
title: SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written -> SpooledTemporaryFile rollover corrupts data silently when Unicode characters are written

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Nov 26 22:38:58 2019
From: report at bugs.python.org (Leandro Lima)
Date: Wed, 27 Nov 2019 03:38:58 +0000
Subject: [issue37218] Default hmac.new() digestmod has not been removed from
 documentation
In-Reply-To: <1560200535.68.0.253007657272.issue37218@roundup.psfhosted.org>
Message-ID: <1574825938.82.0.354922359709.issue37218@roundup.psfhosted.org>


Leandro Lima <leandro at limaesilva.com.br> added the comment:

In my view, this function signature changed too silently. Even using static type checkers, I could only find about this compatibility breaking change when actually running the code.

If I understand well the reason it was done this way, digestmod needed to become a mandatory argument, but this couldn't be done without changing the order between msg and digestmod in the function's signature.

In my view, the two other ways this could be solved were:
1. hmac.new(key: Union[bytes, bytearray],
            digestmod: str,
            msg: Union[bytes, bytearray, None] = None)
2. hmac.new(key: Union[bytes, bytearray],
            *,
            digestmod: str,
            msg: Union[bytes, bytearray] = None)

If the signature of the function changed to reflect digestmod becoming mandatory, then static code checkers could catch a misuse of the function.

Now, suppose that we're dealing with someone that doesn't use static code analysis and a legacy signature used in some code:

hmac.new(b"key", b"msg")

- In option (1), we'd be passing b"msg" as the digestmod argument when the original intention was to pass it as the msg argument. But since both have disjoint expected types, this mistake would be rejected because passing the wrong type would lead to a TypeError
- In option (2) we'd be making clear that from now on, both msg and digestmod would only be specifiable as keyword arguments and an inadvertent use of the old signature would also lead to a TypeError.

Given that it seems a rather safe signature change (that is: there's no chance someone would be able to use the old signature with the new definition) and that actually changing the signature would allow for static code analysis tools to actually catch the error without needing to run the code, I think that we should consider further changing this function and making sure that the change doesn't go so easily unnoticed like today.

----------
nosy: +Leandro Lima

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37218>
_______________________________________

From report at bugs.python.org  Tue Nov 26 22:56:04 2019
From: report at bugs.python.org (Leandro Lima)
Date: Wed, 27 Nov 2019 03:56:04 +0000
Subject: [issue33604] HMAC default to MD5 marked as to be removed in 3.6
In-Reply-To: <1527014760.1.0.682650639539.issue33604@psf.upfronthosting.co.za>
Message-ID: <1574826964.05.0.82463231647.issue33604@roundup.psfhosted.org>


Leandro Lima <leandro at limaesilva.com.br> added the comment:

IMV, the adopted solution creates a problem of a mismatch between the signature and the function behavior.

I was just hit by this, as I never cared to specify digestmod trusting that Python defaults are usually sound choices.

I agree that changing the signature would break more code, but the choice made here violates the principle of least astonishment. An error that could be caught by a static analysis tool silently entered the code base to be provoked only when the function got called.

The choice to break compatibility was already made. Introducing silent bugs is something that I think we should avoid.

I've wrote an argument about this in a different message, and I'm not sure if I should repeat it here. Here's the link to it:
https://bugs.python.org/msg357551

----------
nosy: +Leandro Lima

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33604>
_______________________________________

From report at bugs.python.org  Tue Nov 26 22:57:51 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 27 Nov 2019 03:57:51 +0000
Subject: [issue38874] asyncio.Queue: putting items out of order when it is full
In-Reply-To: <1574306754.82.0.07273997342.issue38874@roundup.psfhosted.org>
Message-ID: <1574827071.16.0.824701436566.issue38874@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Yes, five outstanding blocked puts can be bypassed by a put that comes in immediately after a get creates space. But this isn't really a problem; there are no guarantees on what order puts are executed in, only a guarantee that once a put succeeds, it's FIFO ordered with respect to all other puts.

Nothing in the docs even implies the behavior you're expecting, so I'm not seeing how even a documentation fix is warranted here. The docs on put clearly say:

"Put an item into the queue. If the queue is full, wait until a free slot is available before adding the item."

If we forcibly hand off on put even when a slot is available (to allow older puts to finish first), then we violate the expectation that waiting is only performed when the queue is full (if I test myqueue.full() and it returns False, I can reasonably expect that put won't block). This would be especially impossible to fix if people write code like `if not myqueue.full(): myqueue.put_nowait()`. put_nowait isn't even a coroutine, so it *can't* hand off control to the event loop to allow waiting puts to complete, even if it wanted to, and it can't fail to put (e.g. by determining the empty slots will be filled by outstanding puts in some relatively expensive way), because you literally *just* verified the queue wasn't full and had no awaits between the test and the put_nowait, so it *must* succeed.

In short: Yes, it's somewhat unpleasant that a queue slot can become free and someone else can swoop in and steal it before older waiting puts can finish. But any change that "fixed" that would make all code slower (forcing unnecessary coroutine switches), and violate existing documentation guarantees.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38874>
_______________________________________

From report at bugs.python.org  Tue Nov 26 23:12:56 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 27 Nov 2019 04:12:56 +0000
Subject: [issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
In-Reply-To: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>
Message-ID: <1574827976.42.0.540602722289.issue38810@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38810>
_______________________________________

From report at bugs.python.org  Tue Nov 26 23:38:55 2019
From: report at bugs.python.org (danielen)
Date: Wed, 27 Nov 2019 04:38:55 +0000
Subject: [issue38913] Py_BuildValue("(s#O)",
 ...) segfaults if entered with exception raised
In-Reply-To: <1574749641.72.0.139840395561.issue38913@roundup.psfhosted.org>
Message-ID: <1574829535.2.0.731319247849.issue38913@roundup.psfhosted.org>


danielen <daniele at grinta.net> added the comment:

The problem arises from this code in do_mktuple(), staring at line 394 in modsupport.c:

            if (**p_format == '#') {
                ++*p_format;
                if (flags & FLAG_SIZE_T)
                    n = va_arg(*p_va, Py_ssize_t);
                else {
                    if (PyErr_WarnEx(PyExc_DeprecationWarning,
                                "PY_SSIZE_T_CLEAN will be required for '#' formats", 1)) {
                        return NULL;
                    }
                    n = va_arg(*p_va, int);
                }
            }

If this is entered with an exception raised, PyErr_WarnEx() return NULL, thus this function return NULL without consuming the argument relative to the string length for the "s#" specifier. This argument is then consumed at the next iteration for the "O" specifier, resulting in a segmentation fault when the string length is interpreted as an object pointer.

I don't know what is the best solution: either ignoring the return value of PyErr_WarnEx or swapping the lines from 

                    if (PyErr_WarnEx(PyExc_DeprecationWarning,
                                "PY_SSIZE_T_CLEAN will be required for '#' formats", 1)) {
                        return NULL;
                    }
                    n = va_arg(*p_va, int);


to 

                    n = va_arg(*p_va, int);
                    if (PyErr_WarnEx(PyExc_DeprecationWarning,
                                "PY_SSIZE_T_CLEAN will be required for '#' formats", 1)) {
                        return NULL;
                    }

The handling of the "y#" just below suffers from the same problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38913>
_______________________________________

From report at bugs.python.org  Tue Nov 26 23:43:12 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 27 Nov 2019 04:43:12 +0000
Subject: [issue38908] Troubles with @runtime_checkable protocols
In-Reply-To: <1574617196.5.0.297633036854.issue38908@roundup.psfhosted.org>
Message-ID: <1574829792.7.0.668825909529.issue38908@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

If the "little helper in abc" solves it, let's do that. The sys._getframe() hack has always been a bit smelly -- I assume we can get rid of that then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38908>
_______________________________________

From report at bugs.python.org  Tue Nov 26 23:49:43 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 27 Nov 2019 04:49:43 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574830183.45.0.212527981982.issue38688@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:


New changeset 65c92c5870944b972a879031abd4c20c4f0d7981 by Giampaolo Rodola (Bruno P. Kinoshita) in branch '3.8':
[3.8] bpo-38688, shutil.copytree: consume iterator and create list of entries to prevent infinite recursion (GH-17397)
https://github.com/python/cpython/commit/65c92c5870944b972a879031abd4c20c4f0d7981


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Tue Nov 26 23:50:18 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 27 Nov 2019 04:50:18 +0000
Subject: [issue38688] Python 3.8 regression: endless loop in shutil.copytree
In-Reply-To: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>
Message-ID: <1574830218.94.0.467609678112.issue38688@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38688>
_______________________________________

From report at bugs.python.org  Wed Nov 27 00:03:11 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Nov 2019 05:03:11 +0000
Subject: [issue38715] Regression in compileall ddir parameter when recursing
In-Reply-To: <1573024333.47.0.536430294956.issue38715@roundup.psfhosted.org>
Message-ID: <1574830991.08.0.894411030761.issue38715@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38715>
_______________________________________

From report at bugs.python.org  Wed Nov 27 00:28:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Nov 2019 05:28:04 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1574832484.9.0.145743665934.issue38924@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please add an example of how normalize() should behave? I assume you want the same behaviour as os.path.normpath which already accepts a pathlike object to be added to pathlib.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38924>
_______________________________________

From report at bugs.python.org  Wed Nov 27 00:33:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Nov 2019 05:33:22 +0000
Subject: [issue38854] Decorator breaks inspect.getsource
In-Reply-To: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>
Message-ID: <1574832802.11.0.618984119743.issue38854@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38854>
_______________________________________

From report at bugs.python.org  Wed Nov 27 00:50:49 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Nov 2019 05:50:49 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574833849.83.0.2214718051.issue26730@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I cannot cre?te a pr now. Please take this issue yourself Inada+san.

----------
assignee: serhiy.storchaka -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Wed Nov 27 02:31:25 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 27 Nov 2019 07:31:25 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574839885.16.0.398171995421.issue26730@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +16880
pull_request: https://github.com/python/cpython/pull/17400

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Wed Nov 27 03:46:49 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 27 Nov 2019 08:46:49 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574844409.09.0.249577043035.issue38524@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset 1bddf890e595a865414645c6041733043c4081f8 by Tal Einat (Florian Dahlitz) in branch 'master':
bpo-38524: document implicit and explicit calling of descriptors' __set_name__ (GH-17364)
https://github.com/python/cpython/commit/1bddf890e595a865414645c6041733043c4081f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Wed Nov 27 03:47:06 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Nov 2019 08:47:06 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574844426.04.0.184920169284.issue38524@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16881
pull_request: https://github.com/python/cpython/pull/17401

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Wed Nov 27 03:47:13 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Nov 2019 08:47:13 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574844432.99.0.505946696243.issue38524@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16882
pull_request: https://github.com/python/cpython/pull/17402

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Wed Nov 27 03:52:42 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Nov 2019 08:52:42 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574844762.82.0.104195287143.issue38524@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cd27d22ac90a869dc740004597246f24246348a6 by Miss Islington (bot) in branch '3.7':
bpo-38524: document implicit and explicit calling of descriptors' __set_name__ (GH-17364)
https://github.com/python/cpython/commit/cd27d22ac90a869dc740004597246f24246348a6


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Wed Nov 27 03:53:55 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Nov 2019 08:53:55 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574844835.34.0.474624080686.issue38524@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0f9c9d53283420a570850aa92869d032b40d4fba by Miss Islington (bot) in branch '3.8':
bpo-38524: document implicit and explicit calling of descriptors' __set_name__ (GH-17364)
https://github.com/python/cpython/commit/0f9c9d53283420a570850aa92869d032b40d4fba


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Wed Nov 27 04:18:13 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 27 Nov 2019 09:18:13 +0000
Subject: [issue38927] venv --upgrade_deps fails on Windows
Message-ID: <1574846292.94.0.272462348302.issue38927@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

https://github.com/python/cpython/commit/4acdbf11b1fae1af24c47413a6caa593010d1b6f

EnvBuilder.upgrade_dependencies() uses `pip.exe install -U` to upgrade pip, which fails on Windows with `[WinError 5] Access is denied`.

----------
components: Library (Lib), Windows
messages: 357562
nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
priority: normal
severity: normal
status: open
title: venv --upgrade_deps fails on Windows
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38927>
_______________________________________

From report at bugs.python.org  Wed Nov 27 04:33:24 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 27 Nov 2019 09:33:24 +0000
Subject: [issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
Message-ID: <1574847204.22.0.593056122111.issue38928@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

The documentation says it is new in 3.8, but in reality it is not present until 3.9.

https://docs.python.org/3/library/venv.html#venv.EnvBuilder.upgrade_dependencies

----------
assignee: docs at python
components: Documentation
messages: 357563
nosy: docs at python, uranusjr
priority: normal
severity: normal
status: open
title: EnvBuilder.upgrade_dependencies() does not exist on 3.8
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38928>
_______________________________________

From report at bugs.python.org  Wed Nov 27 04:44:11 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 27 Nov 2019 09:44:11 +0000
Subject: [issue38927] venv --upgrade_deps fails on Windows
In-Reply-To: <1574846292.94.0.272462348302.issue38927@roundup.psfhosted.org>
Message-ID: <1574847851.14.0.312358837535.issue38927@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38927>
_______________________________________

From report at bugs.python.org  Wed Nov 27 04:52:36 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 27 Nov 2019 09:52:36 +0000
Subject: [issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
In-Reply-To: <1574847204.22.0.593056122111.issue38928@roundup.psfhosted.org>
Message-ID: <1574848356.32.0.268946373739.issue38928@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38928>
_______________________________________

From report at bugs.python.org  Wed Nov 27 05:57:27 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 27 Nov 2019 10:57:27 +0000
Subject: [issue38906] copy2 doesn't copy metadata on Windows and MacOS
In-Reply-To: <1574597606.02.0.586122584542.issue38906@roundup.psfhosted.org>
Message-ID: <1574852247.76.0.164646290355.issue38906@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

If we use CopyFileExW in copy2(), then also copystat() and copymode() should be able to copy the same metadata/security-bits/etc as CopyFileExW. I don't know which Windows APIs should be used though.

I sort of agree with Steven that CopyFileExW could be used everywhere (meaning copyfile()), but that basically means breaking backward compatibility re. what is promised in the doc, and am not sure how to deal with that. For that reason it's probably it's better to leave copyfile() alone. 

On macOS it seems we can use fcopyfile(3) syscall (which is already exposed) and its flag argument (COPYFILE_METADATA, COPYFILE_DATA. COPYFILE_XATTR, etc,) to implement both copy2() and copystat() / copymode().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38906>
_______________________________________

From report at bugs.python.org  Wed Nov 27 06:45:52 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Nov 2019 11:45:52 +0000
Subject: [issue38861] zipfile: Corrupts filenames containing non-UTF8
 characters
In-Reply-To: <1574218342.23.0.381286067182.issue38861@roundup.psfhosted.org>
Message-ID: <1574855152.56.0.654502565349.issue38861@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The standard requires interpreting filename encoding as cp470 or utf8. But for practical reasons it would be handy to allow to specify other encoding (which is not necessary equal ti the local filesystem encoding)
. This is issue28080. But i left this issue open so that we will not forget to ensure that it will be the option of using extractall() with the encoding that matches the encoding of the local zip tool. There may be percularities on Windows and macOS. Lso there should be an option for CLI.

----------
components: +Library (Lib)
dependencies: +Allow reading member names with bogus encodings in zipfile
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38861>
_______________________________________

From report at bugs.python.org  Wed Nov 27 07:00:58 2019
From: report at bugs.python.org (Douglas Feather)
Date: Wed, 27 Nov 2019 12:00:58 +0000
Subject: [issue38929] Float // Integer doesn't give best result.
Message-ID: <1574856058.19.0.635617982042.issue38929@roundup.psfhosted.org>


New submission from Douglas Feather <python at def.me.uk>:

40.9//2 give 20.0 as a result.  I would have expected one of: 20.45 or 20.  If it is going to give an FP answer then it should do the division as FP and get the right answer.  If it is going to do an integer division then it should give the division as an integer.

----------
components: ctypes
messages: 357566
nosy: def
priority: normal
severity: normal
status: open
title: Float // Integer doesn't give best result.
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38929>
_______________________________________

From report at bugs.python.org  Wed Nov 27 07:26:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Nov 2019 12:26:09 +0000
Subject: [issue38929] Float // Integer doesn't give best result.
In-Reply-To: <1574856058.19.0.635617982042.issue38929@roundup.psfhosted.org>
Message-ID: <1574857569.29.0.472054352472.issue38929@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

To get 20.45 use the true division operator /.

If float // int would return int, 1e300 // 2 would return a 300-digit integer. It takee more memory and its creation is slower than 5e299. In addition it does not make sense to provide such precision.

----------
nosy: +mark.dickinson, serhiy.storchaka, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38929>
_______________________________________

From report at bugs.python.org  Wed Nov 27 07:43:21 2019
From: report at bugs.python.org (Xuan Hu)
Date: Wed, 27 Nov 2019 12:43:21 +0000
Subject: [issue38930] Subprocess failed to kill child process after timeout
 when using with statement
Message-ID: <1574858601.45.0.747000214566.issue38930@roundup.psfhosted.org>


New submission from Xuan Hu <huxuan8218528 at gmail.com>:

The original issue is that the `timeout` in `subprocess.run()` does not work properly, so I try to use `subprocess.Popen()` instead. There are two references I found, [1] is the implementation of `subprocess.run()` and [2] is the example for `Popen.communicate()`. Surprisingly, [2] works for me, and seems the `with` statement is the cause of the issue.

I created a snippet [3] to reproduce the bug, note that `ffmpeg` is needed to run the script. Ideally, all the time should be less than 0.1 or just a little bit greater than 0.1, but when using the `with` statement, the result would be much larger than that.

[1] https://github.com/python/cpython/blob/0f9c9d53283420a570850aa92869d032b40d4fba/Lib/subprocess.py#L489
[2] https://docs.python.org/3/library/subprocess.html#subprocess.Popen.communicate
[3] https://gist.github.com/huxuan/d58a5899be9b42e0936c71dd7884442a

----------
components: Library (Lib)
messages: 357568
nosy: Xuan Hu
priority: normal
severity: normal
status: open
title: Subprocess failed to kill child process after timeout when using with statement
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38930>
_______________________________________

From report at bugs.python.org  Wed Nov 27 07:50:33 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 27 Nov 2019 12:50:33 +0000
Subject: [issue38929] Float // Integer doesn't give best result.
In-Reply-To: <1574856058.19.0.635617982042.issue38929@roundup.psfhosted.org>
Message-ID: <1574859033.98.0.741745538136.issue38929@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Although it often gets called "integer division", that's not actually what // does, it is actually *floor* division, as documented here:

https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex

So the behaviour as given is correct: it returns the floor of the quotient. Arguments are coerced to a common type in the normal fashion, so float//int performs the floor  division in floating point, which may not give the same result as integer floor division due to floating point rounding:

py> 10**17 // 7
14285714285714285
py> 1e17 // 7
1.4285714285714284e+16

If you don't want floating point rounding, don't use floats.

If you want "true division", use / not the floor division operator.

This isn't a bug, it is working as designed.

Even if the behaviour you are asking for was possible, practical and desirable, it would break backwards compatibility. There's no way to do a "floor division that returns an int" for all float arguments, since there are no int NANs.

py> float('inf')//7
nan

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38929>
_______________________________________

From report at bugs.python.org  Wed Nov 27 08:22:10 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 27 Nov 2019 13:22:10 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574860930.54.0.757704452095.issue26730@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset ea9835c5d154ab6a54eed627958473b6768b28cc by Inada Naoki in branch 'master':
bpo-26730: Fix SpooledTemporaryFile data corruption (GH-17400)
https://github.com/python/cpython/commit/ea9835c5d154ab6a54eed627958473b6768b28cc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Wed Nov 27 08:22:20 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Nov 2019 13:22:20 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574860940.05.0.966324997022.issue26730@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16885
pull_request: https://github.com/python/cpython/pull/17405

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Wed Nov 27 08:25:07 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 27 Nov 2019 13:25:07 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574861107.41.0.988849257385.issue38524@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
pull_requests: +16886
pull_request: https://github.com/python/cpython/pull/17406

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Wed Nov 27 08:29:41 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 27 Nov 2019 13:29:41 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574861381.75.0.929274435014.issue26730@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +16887
pull_request: https://github.com/python/cpython/pull/17407

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Wed Nov 27 08:47:23 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 27 Nov 2019 13:47:23 +0000
Subject: [issue38270] Tests: Avoid MD5 or check for MD5 availablity
In-Reply-To: <1569406198.76.0.145895264341.issue38270@roundup.psfhosted.org>
Message-ID: <1574862443.38.0.100120193254.issue38270@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

The change silently disables 2 tests, see comment here:
https://github.com/python/cpython/commit/66cd041df8dfadd001ae298292e16f0271c0d139#diff-ba7d7a4a1a0050e1f497b71b5cd50afcR365

(I think it's better to reopen this bug, than to open a new one, so all the fixes are in one place. Do you agree?)

----------
nosy: +petr.viktorin
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38270>
_______________________________________

From report at bugs.python.org  Wed Nov 27 10:32:37 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 27 Nov 2019 15:32:37 +0000
Subject: [issue38906] copy2 doesn't copy metadata on Windows and MacOS
In-Reply-To: <1574597606.02.0.586122584542.issue38906@roundup.psfhosted.org>
Message-ID: <1574868757.12.0.864567386728.issue38906@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> copystat() and copymode() should be able to copy the same 
> metadata/security-bits/etc as CopyFileExW. 

Regarding metadata, CopyFileExW copies the basic file info (i.e. FileAttributes, LastAccessTime, LastWriteTime, and ChangeTime). This metadata can be copied separately as the FileBasicInfo, via GetFileInformationByHandleEx and SetFileInformationByHandle. (Zero the CreationTime field to skip setting it.) Note that this includes the change time (i.e. Unix st_ctime) in file systems that support it, such as NTFS and ReFS. It also includes all settable file attributes, including readonly, hidden, system, archive, temporary, and not-content-indexed. Currently we only copy the readonly attribute.

Regarding security bits, CopyFileExW copies security resource attributes (i.e. ATTRIBUTE_SECURITY_INFORMATION), which in Windows 8+ can be referenced by arbitrarily complex expressions in conditional ACEs. See "[MS-DTYP] 2.4.4.17 Conditional ACEs" [1] for details. Security resource attributes can be queried and set by handle via GetSecurityInfo and SetSecurityInfo. This information is set in the system access control list (SACL), but it does not require the privileged ACCESS_SYSTEM_SECURITY right. It only requires READ_CONTROL and WRITE_DAC access.

CopyFileExW also copies extended attributes. These are commonly set on system files, but in this case they're usually "$Kernel." attributes [2], which cannot be set from user mode. IIRC, WSL also uses them. Otherwise extended attributes are not used much at all because the Windows API provides no way to query and set them separately. (They're supported in the NT API via NtQueryEaFile and NtSetEaFile.) When creating a new file via CreateFileW, we can pass it a handle to a template file from which to copy extended attributes. But that doesn't help with copystat(), which requires copying extended attributes onto an existing file.

Regarding data, CopyFileExW copies all $DATA streams [3] in a file, not just the anonymous $DATA stream. The stream names and sizes can be read via GetFileInformationByHandleEx: FileStreamInfo. Just loop over the stream names to try copying them individually.

For complete consistency, copytree should copy named data streams in directories. (A directory can't have an anonymous data stream, but it can have named streams, and it's not uncommon to store metadata about a directory like this. Ignoring this data is inconsistent, but it's a matter of opinion whether complete consistency is worthwhile.) This can be implemented at a high level via CreateDirectoryExW by passing the source directory path as the lpTemplateDirectory parameter. However, CreateDirectoryExW also preserves whether the directory is compressed or encrypted. I don't know whether copytree should preserve those attributes.

[1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/10dc22eb-788d-4343-b556-0b6969fe58ca
[2] https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/kernel-extended-attributes
[3] https://docs.microsoft.com/en-us/windows/win32/fileio/file-streams

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38906>
_______________________________________

From report at bugs.python.org  Wed Nov 27 11:45:30 2019
From: report at bugs.python.org (Ido Michael)
Date: Wed, 27 Nov 2019 16:45:30 +0000
Subject: [issue37883] threading.Lock.locked is not documented
In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org>
Message-ID: <1574873130.44.0.655561696723.issue37883@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Thanks, Tal, I think this one can be closed, I don't think I have permissions to close it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37883>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:00:38 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Nov 2019 17:00:38 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
In-Reply-To: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>
Message-ID: <1574874038.35.0.00456091531127.issue38918@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38918>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:16:00 2019
From: report at bugs.python.org (tempest)
Date: Wed, 27 Nov 2019 17:16:00 +0000
Subject: [issue38931] pathlib.Path on Windows - parser issue
Message-ID: <1574874960.06.0.13653965118.issue38931@roundup.psfhosted.org>


New submission from tempest <online_m at majck.com>:

the Path parser from pathlib seems to give incorrect paths if a folder (subdirectory) name includes a period. (This issue does not manifest with Unix paths.) 

Please see a demonstration below: "Out[2]" is not the same as "Out[3]" and "Out[4]"; the "\" separator following the folder name with the period is not converted to the forward slash ("/") in the WindowsPath() when the full path is given as a Windows path string. This issue manifests with pathlib.WindowsPath() as well. This is Python 3.7.4 from the Anaconda distribution.

Jupyter QtConsole 4.6.0
Python 3.7.4 (default, Aug  9 2019, 18:34:13) [MSC v.1915 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 7.9.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from pathlib import Path

In [2]: Path('C:\Temp\MyProj.wc\test.eps')
Out[2]: WindowsPath('C:/Temp/MyProj.wc\test.eps')

In [3]: Path('C:\Temp\MyProj.wc').joinpath('test.eps')
Out[3]: WindowsPath('C:/Temp/MyProj.wc/test.eps')

In [4]: Path('C:/Temp/MyProj.wc/test.eps')
Out[4]: WindowsPath('C:/Temp/MyProj.wc/test.eps')

----------
components: Windows
messages: 357574
nosy: paul.moore, steve.dower, tempest, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib.Path on Windows - parser issue
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38931>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:28:57 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 17:28:57 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1574875737.67.0.808172132611.issue38924@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Do note that Path inherits from PurePath, so providing a normalize() method on the latter means it will end up on the former.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38924>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:29:47 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 17:29:47 +0000
Subject: [issue38927] venv --upgrade_deps fails on Windows
In-Reply-To: <1574846292.94.0.272462348302.issue38927@roundup.psfhosted.org>
Message-ID: <1574875787.75.0.164639553528.issue38927@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38927>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:30:17 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 17:30:17 +0000
Subject: [issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
In-Reply-To: <1574847204.22.0.593056122111.issue38928@roundup.psfhosted.org>
Message-ID: <1574875817.37.0.662402096421.issue38928@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38928>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:31:38 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 17:31:38 +0000
Subject: [issue38931] pathlib.Path on Windows - parser issue
In-Reply-To: <1574874960.06.0.13653965118.issue38931@roundup.psfhosted.org>
Message-ID: <1574875898.08.0.345386017859.issue38931@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38931>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:56:03 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 17:56:03 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1574877363.04.0.399597612896.issue35003@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:56:10 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 17:56:10 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1574877370.27.0.457143310033.issue35003@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Wed Nov 27 12:59:20 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 17:59:20 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574877560.03.0.0153332101029.issue38916@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> there's no harm to keeping it (it's not broken)

... for now. :) There's always the risk that will change if we keep the code around.

> The other deprecation in the array module says, "Deprecated since version 3.3, will be removed in version 4.0".  Perhaps this one should have had the same qualifier.

If the function is left then I agree it should probably be updated to match the rest of the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:00:05 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 27 Nov 2019 18:00:05 +0000
Subject: [issue38931] pathlib.Path on Windows - parser issue
In-Reply-To: <1574874960.06.0.13653965118.issue38931@roundup.psfhosted.org>
Message-ID: <1574877605.0.0.570737011321.issue38931@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Note that you're using backslashes in a non-raw string; in particular, you're naming your file `\x09est.eps`.  Try `Path(r'C:\Temp\MyProj.wc\test.eps')` and see if that works for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38931>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:38:40 2019
From: report at bugs.python.org (Michael Felt)
Date: Wed, 27 Nov 2019 18:38:40 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1574795432.86.0.896112685257.issue38021@roundup.psfhosted.org>
Message-ID: <ff5a406b-1479-fb41-4e15-0babd6428502@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 26/11/2019 20:10, Paul Moore wrote:
> Paul Moore <p.f.moore at gmail.com> added the comment:
>
>> replacement platform_tag, not compatibility tag.
> Ah, I see, sorry. In that case, this should be fine, it's purely a CPython question. There's obviously a follow-on discussion about how that platform tag is *incorporated* into the compatibility tags, but as you say, that's a separate point.
Still an excellent question - as it clarified at least one vital point!
Thanks for the feedback and question.
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38021>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:41:38 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:41:38 +0000
Subject: [issue38021] pep425 tag for AIX is inadequate
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574880098.51.0.263003915102.issue38021@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:41:45 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:41:45 +0000
Subject: [issue32856] Optimize the `for y in [x]` idiom in comprehensions
In-Reply-To: <1518770483.24.0.467229070634.issue32856@psf.upfronthosting.co.za>
Message-ID: <1574880105.24.0.60389712824.issue32856@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32856>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:42:19 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:42:19 +0000
Subject: [issue38649] tkinter messagebox is sloppy
In-Reply-To: <1572464225.7.0.112082789313.issue38649@roundup.psfhosted.org>
Message-ID: <1574880139.36.0.358972891966.issue38649@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38649>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:42:35 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:42:35 +0000
Subject: [issue38593] Python 3.7 does not catch infinite recursion for some
 values of sys.getrecursionlimit()
In-Reply-To: <1572040268.11.0.31838216135.issue38593@roundup.psfhosted.org>
Message-ID: <1574880155.33.0.330444430609.issue38593@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38593>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:42:51 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:42:51 +0000
Subject: [issue38569] Unknown distribution option: 'license_files'
In-Reply-To: <1571860665.03.0.77407877223.issue38569@roundup.psfhosted.org>
Message-ID: <1574880171.53.0.612675984914.issue38569@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38569>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:43:06 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:43:06 +0000
Subject: [issue34309] Trouble when reloading extension modules.
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1574880186.38.0.688984326627.issue34309@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:44:21 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:44:21 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1574880261.92.0.293028750193.issue7980@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

As per Paul's suggestion, closing as "won't fix" as this only pertains to Python 2.7 and it will not be changing.

----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:45:14 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:45:14 +0000
Subject: [issue11664] Add patch method to unittest.TestCase
In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za>
Message-ID: <1574880314.27.0.480255322904.issue11664@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11664>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:45:45 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:45:45 +0000
Subject: [issue16079] list duplicate test names with patchcheck
In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za>
Message-ID: <1574880345.92.0.451652911441.issue16079@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16079>
_______________________________________

From report at bugs.python.org  Wed Nov 27 13:46:11 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Nov 2019 18:46:11 +0000
Subject: [issue38079] _PyObject_VAR_SIZE should avoid arithmetic overflow
In-Reply-To: <1568095434.38.0.419984745356.issue38079@roundup.psfhosted.org>
Message-ID: <1574880371.31.0.499042718375.issue38079@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38079>
_______________________________________

From report at bugs.python.org  Wed Nov 27 14:53:32 2019
From: report at bugs.python.org (Roy Smith)
Date: Wed, 27 Nov 2019 19:53:32 +0000
Subject: [issue38462] Typo (nam ing) in import system docs
In-Reply-To: <1570973495.13.0.272264963981.issue38462@roundup.psfhosted.org>
Message-ID: <1574884412.49.0.0641642856773.issue38462@roundup.psfhosted.org>


Roy Smith <roy at panix.com> added the comment:

Just for the archives:

https://bugs.chromium.org/p/chromium/issues/detail?id=1022011

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38462>
_______________________________________

From report at bugs.python.org  Wed Nov 27 14:59:26 2019
From: report at bugs.python.org (Vegard Stikbakke)
Date: Wed, 27 Nov 2019 19:59:26 +0000
Subject: [issue38932] MagicMock.reset_mocks does not pass all arguments to its
 children
Message-ID: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>


New submission from Vegard Stikbakke <vegard.stikbakke at gmail.com>:

MagicMock, from unittest.mock, has a method reset_mock, which takes optional arguments return_value and side_effect, both with default values False.

In the body of reset_mock, reset_mock is again called on all the _mock_children of of the MagicMock object. However, here the arguments are not passed. This means that if you have a MagicMock object with children that are also mocked, and methods on these have been directly mocked, then it is not enough to call reset_mock on the parent object. A code example that demonstrates this follows below. Here, we could expect m to have been completely reset. But the final print statement shows that m.a() still returns 1.

```
from unittest.mock import MagicMock

m = MagicMock(a=MagicMock())
m.a.return_value = 1
m.reset_mock(return_value=True)
print(m.a())
```

Pertinent line in Github https://github.com/python/cpython/blob/dadff6f6610e03a9363c52ba9c49aa923984640a/Lib/unittest/mock.py#L601

----------
components: Library (Lib)
messages: 357581
nosy: vegarsti
priority: normal
severity: normal
status: open
title: MagicMock.reset_mocks does not pass all arguments to its children
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Wed Nov 27 15:05:27 2019
From: report at bugs.python.org (Vegard Stikbakke)
Date: Wed, 27 Nov 2019 20:05:27 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1574885127.6.0.131203694816.issue38932@roundup.psfhosted.org>


Change by Vegard Stikbakke <vegard.stikbakke at gmail.com>:


----------
title: MagicMock.reset_mocks does not pass all arguments to its children -> unittest.mock.Mock.reset_mocks does not pass all arguments to its children

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Wed Nov 27 15:06:00 2019
From: report at bugs.python.org (Vegard Stikbakke)
Date: Wed, 27 Nov 2019 20:06:00 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1574885160.61.0.220859964655.issue38932@roundup.psfhosted.org>


Vegard Stikbakke <vegard.stikbakke at gmail.com> added the comment:

I said MagicMock, but I meant Mock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Wed Nov 27 15:19:17 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 27 Nov 2019 20:19:17 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1574885957.62.0.241074239873.issue35003@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The problem of bin over Scripts is that IIRC Scripts is baked-in in Windows, not just for venvs (e.g. a standard Python installation puts stuff in Scripts). So venv just sticks with the platform convention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Wed Nov 27 15:22:07 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 27 Nov 2019 20:22:07 +0000
Subject: [issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
In-Reply-To: <1574847204.22.0.593056122111.issue38928@roundup.psfhosted.org>
Message-ID: <1574886127.83.0.929821098502.issue38928@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 045d4e243d042638bbbc9479d4f85f6f579ac3ca by Vinay Sajip (Tzu-ping Chung) in branch 'master':
bpo-38928: Fix versionadded for venv's upgrade_deps function (GH-17404)
https://github.com/python/cpython/commit/045d4e243d042638bbbc9479d4f85f6f579ac3ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38928>
_______________________________________

From report at bugs.python.org  Wed Nov 27 15:25:28 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 27 Nov 2019 20:25:28 +0000
Subject: [issue38927] venv --upgrade_deps fails on Windows
In-Reply-To: <1574846292.94.0.272462348302.issue38927@roundup.psfhosted.org>
Message-ID: <1574886328.54.0.687417551983.issue38927@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset d9aa216d49423d58e192cd7a25016f90fe771ce7 by Vinay Sajip (Tzu-ping Chung) in branch 'master':
bpo-38927: Use python -m pip to upgrade venv deps (GH-17403)
https://github.com/python/cpython/commit/d9aa216d49423d58e192cd7a25016f90fe771ce7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38927>
_______________________________________

From report at bugs.python.org  Wed Nov 27 15:26:56 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 27 Nov 2019 20:26:56 +0000
Subject: [issue38927] venv --upgrade_deps fails on Windows
In-Reply-To: <1574846292.94.0.272462348302.issue38927@roundup.psfhosted.org>
Message-ID: <1574886416.04.0.498722558892.issue38927@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38927>
_______________________________________

From report at bugs.python.org  Wed Nov 27 15:42:58 2019
From: report at bugs.python.org (Vegard Stikbakke)
Date: Wed, 27 Nov 2019 20:42:58 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1574887378.16.0.304156578323.issue38932@roundup.psfhosted.org>


Change by Vegard Stikbakke <vegard.stikbakke at gmail.com>:


----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Wed Nov 27 15:55:17 2019
From: report at bugs.python.org (Vegard Stikbakke)
Date: Wed, 27 Nov 2019 20:55:17 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1574888117.35.0.410928011713.issue38932@roundup.psfhosted.org>


Change by Vegard Stikbakke <vegard.stikbakke at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Wed Nov 27 16:22:03 2019
From: report at bugs.python.org (Alexey Burdin)
Date: Wed, 27 Nov 2019 21:22:03 +0000
Subject: [issue38933] unusual behaviour on list of dependable lambdas
Message-ID: <1574889723.55.0.16614385889.issue38933@roundup.psfhosted.org>


New submission from Alexey Burdin <longsillyusernamealreadytaken8 at gmail.com>:

>>> x=[2,3]
>>> [f(x) for f in [(lambda a:a[i]) for i in [0,1]]]
[3, 3]
>>> [f(x) for f in [lambda a:a[0],lambda a:a[1]]]
[2, 3]

----------
components: Interpreter Core
messages: 357586
nosy: Alexey Burdin
priority: normal
severity: normal
status: open
title: unusual behaviour on list of dependable lambdas
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38933>
_______________________________________

From report at bugs.python.org  Wed Nov 27 16:24:49 2019
From: report at bugs.python.org (Alexey Burdin)
Date: Wed, 27 Nov 2019 21:24:49 +0000
Subject: [issue38933] unusual behaviour on list of dependable lambdas
In-Reply-To: <1574889723.55.0.16614385889.issue38933@roundup.psfhosted.org>
Message-ID: <1574889889.97.0.776243567063.issue38933@roundup.psfhosted.org>


Alexey Burdin <longsillyusernamealreadytaken8 at gmail.com> added the comment:

x=[2,3]
[f(x) for f in [(lambda a:a[i]) for i in [0,1]]]
#the expected output is [2,3] but actual is [3,3]
[f(x) for f in [lambda a:a[0],lambda a:a[1]]]
#results [2,3] normally

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38933>
_______________________________________

From report at bugs.python.org  Wed Nov 27 19:35:44 2019
From: report at bugs.python.org (Ayush Mahajan)
Date: Thu, 28 Nov 2019 00:35:44 +0000
Subject: [issue38817] Immutable types inplace operations work incorrect in
 async
In-Reply-To: <1573847808.01.0.483185624752.issue38817@roundup.psfhosted.org>
Message-ID: <1574901344.91.0.552446987522.issue38817@roundup.psfhosted.org>


Ayush Mahajan <mahajan.ayush2306 at gmail.com> added the comment:

Can I work on this issue?

----------
nosy: +ay2306

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38817>
_______________________________________

From report at bugs.python.org  Wed Nov 27 21:54:30 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 28 Nov 2019 02:54:30 +0000
Subject: [issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
In-Reply-To: <1574847204.22.0.593056122111.issue38928@roundup.psfhosted.org>
Message-ID: <1574909670.39.0.869920375073.issue38928@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
pull_requests: +16890
pull_request: https://github.com/python/cpython/pull/17410

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38928>
_______________________________________

From report at bugs.python.org  Wed Nov 27 22:21:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Nov 2019 03:21:14 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1574911274.55.0.181372356369.issue38932@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Wed Nov 27 22:55:29 2019
From: report at bugs.python.org (sourya varenya)
Date: Thu, 28 Nov 2019 03:55:29 +0000
Subject: [issue38934] Dictionaries of dictionaries behave incorrectly when
 created from dict.fromkeys()
Message-ID: <1574913328.98.0.722203602523.issue38934@roundup.psfhosted.org>


New submission from sourya varenya <souryavarenya at gmail.com>:

Here's a sample run for reproducibility:
---
Python 3.6.9(Ubuntu 18.04) & 3.7.4(Windows)
---
                                                                                     >>> a = {1:{5:8},2:{5:8}}         
                                                                                     >>> b = dict.fromkeys([1,2],{5:8})   
                                                                                  >>> a                                                                                                                  {1: {5: 8}, 2: {5: 8}}          
                                                                                       >>> b                                                                                                                  {1: {5: 8}, 2: {5: 8}}   
                                                                                              >>> a[1].update({6:9})       
                                                                                          >>> b[1].update({6:9})  
                                                                                               >>> a                                                                                                                  {1: {5: 8, 6: 9}, 2: {5: 8}}     
                                                                                      >>> b                                                                                                                  {1: {5: 8, 6: 9}, 2: {5: 8, 6: 9}}

----------
components: Interpreter Core
messages: 357589
nosy: sourya varenya
priority: normal
severity: normal
status: open
title: Dictionaries of dictionaries behave incorrectly when created from dict.fromkeys()
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38934>
_______________________________________

From report at bugs.python.org  Wed Nov 27 23:00:10 2019
From: report at bugs.python.org (sourya varenya)
Date: Thu, 28 Nov 2019 04:00:10 +0000
Subject: [issue38934] Dictionaries of dictionaries behave incorrectly when
 created from dict.fromkeys()
In-Reply-To: <1574913328.98.0.722203602523.issue38934@roundup.psfhosted.org>
Message-ID: <1574913610.82.0.685031409257.issue38934@roundup.psfhosted.org>


sourya varenya <souryavarenya at gmail.com> added the comment:

Here's a sample run for reproducibility:
---
Python 3.6.9(Ubuntu 18.04) & 3.7.4(Windows)
---
>>> a = {1:{5:8},2:{5:8}}

>>> b = dict.fromkeys([1,2],{5:8})

>>> a
{1: {5: 8}, 2: {5: 8}}

>>> b
{1: {5: 8}, 2: {5: 8}}

>>> a[1].update({6:9})
>>> b[1].update({6:9})

>>> a
{1: {5: 8, 6: 9}, 2: {5: 8}}

>>> b
{1: {5: 8, 6: 9}, 2: {5: 8, 6: 9}}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38934>
_______________________________________

From report at bugs.python.org  Wed Nov 27 23:02:48 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 28 Nov 2019 04:02:48 +0000
Subject: [issue38934] Dictionaries of dictionaries behave incorrectly when
 created from dict.fromkeys()
In-Reply-To: <1574913328.98.0.722203602523.issue38934@roundup.psfhosted.org>
Message-ID: <1574913768.45.0.452125942848.issue38934@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

That's the expected behavior, and it's clearly documented here: https://docs.python.org/3/library/stdtypes.html#dict.fromkeys

Quote: "All of the values refer to just a single instance, so it generally doesn?t make sense for value to be a mutable object such as an empty list. To get distinct values, use a dict comprehension instead."

----------
nosy: +josh.r
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38934>
_______________________________________

From report at bugs.python.org  Wed Nov 27 23:46:35 2019
From: report at bugs.python.org (Xuan Hu)
Date: Thu, 28 Nov 2019 04:46:35 +0000
Subject: [issue38930] Subprocess failed to kill child process after timeout
 when using with statement
In-Reply-To: <1574858601.45.0.747000214566.issue38930@roundup.psfhosted.org>
Message-ID: <1574916395.51.0.880866862405.issue38930@roundup.psfhosted.org>


Xuan Hu <huxuan8218528 at gmail.com> added the comment:

Seems it is a false negative report. Close it temporarily.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38930>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:22:30 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 28 Nov 2019 05:22:30 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574918550.13.0.294309206511.issue38524@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset 02519f75d15b063914a11351da30178ca4ceb54b by Tal Einat in branch 'master':
bpo-38524: clarify example a bit and improve formatting (GH-17406)
https://github.com/python/cpython/commit/02519f75d15b063914a11351da30178ca4ceb54b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:22:34 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Nov 2019 05:22:34 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574918554.88.0.721513477344.issue38524@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16891
pull_request: https://github.com/python/cpython/pull/17411

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:22:42 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Nov 2019 05:22:42 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574918562.58.0.829364123799.issue38524@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16892
pull_request: https://github.com/python/cpython/pull/17412

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:22:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Nov 2019 05:22:43 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1574918563.58.0.608793152465.issue38932@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Vegard for the report. The docs say "Child mocks and the return value mock (if any) are reset as well." so it makes sense to me to reset the return_value and side_effect of children. But as mentioned in the PR it's a behaviour change that someone might be dependent on and can go on 3.9 . If we are not going ahead with the change then we can clarify the same in the docs and ask the user to reset mock recursively on their own so that it avoids confusion.

----------
nosy: +cjw296, lisroach, mariocj89, michael.foord
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:23:17 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Nov 2019 05:23:17 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574918597.76.0.268814044188.issue26730@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d21b8e82dda3caf0989bb39bc0e0ce2bfef97081 by Miss Islington (bot) in branch '3.8':
bpo-26730: Fix SpooledTemporaryFile data corruption (GH-17400)
https://github.com/python/cpython/commit/d21b8e82dda3caf0989bb39bc0e0ce2bfef97081


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:24:03 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Nov 2019 05:24:03 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574918643.0.0.137410847994.issue26730@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset e65b3fa9f16537d20f5f37c25673ac899fcd7099 by Inada Naoki in branch '3.7':
bpo-26730: Fix SpooledTemporaryFile data corruption (GH-17400)
https://github.com/python/cpython/commit/e65b3fa9f16537d20f5f37c25673ac899fcd7099


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:26:42 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 28 Nov 2019 05:26:42 +0000
Subject: [issue37883] threading.Lock.locked is not documented
In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org>
Message-ID: <1574918802.81.0.705888205339.issue37883@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Ido, I don't see why this should be closed. The suggestion is good and the PR is good. I'm only waiting for the CLA signing to be worked through to merge the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37883>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:28:42 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Nov 2019 05:28:42 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574918922.01.0.329009645679.issue38524@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7e9bbbe51e74e5928e6a6c3e70434d824970ef58 by Miss Islington (bot) in branch '3.7':
bpo-38524: clarify example a bit and improve formatting (GH-17406)
https://github.com/python/cpython/commit/7e9bbbe51e74e5928e6a6c3e70434d824970ef58


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:29:06 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Nov 2019 05:29:06 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574918946.04.0.396076525074.issue38524@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c0db88f6abbace79644b2aca2290bf41b1a37174 by Miss Islington (bot) in branch '3.8':
bpo-38524: clarify example a bit and improve formatting (GH-17406)
https://github.com/python/cpython/commit/c0db88f6abbace79644b2aca2290bf41b1a37174


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:33:36 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 28 Nov 2019 05:33:36 +0000
Subject: [issue38524] functools.cached_property is not supported for setattr
In-Reply-To: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>
Message-ID: <1574919216.32.0.301151865618.issue38524@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thanks for the suggestion hongweipeng!

Thanks for the PR Florian, and congratulations on your first contribution to the project! May it be the first of many.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38524>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:38:48 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Nov 2019 05:38:48 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574919528.51.0.579950227369.issue26730@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:39:07 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 28 Nov 2019 05:39:07 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574919547.24.0.989925823633.issue38916@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> The other deprecation in the array module says, "Deprecated since version 3.3, will be removed in version 4.0".  Perhaps this one should have had the same qualifier.

I agree,
How about note it in the documentation and logging rather than removing them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:44:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Nov 2019 05:44:06 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574919846.97.0.119001969607.issue26730@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Inada-san.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Thu Nov 28 00:44:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Nov 2019 05:44:16 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574919856.61.0.0414490447759.issue26730@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Do we need to explicitly document the return value change of _file which is documented with a separate versionchanged directive for 3.7 and 3.8? Code like below could fail in them since TextIOWrapper doesn't have getvalue attribute as the minor version upgrade is done.

import tempfile

with tempfile.SpooledTemporaryFile(mode='wt') as f:
    f.write('abc')
    assert f._file.getvalue() == 'abc'

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Thu Nov 28 01:04:24 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Nov 2019 06:04:24 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574921064.15.0.198337428698.issue26730@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Do we need to explicitly document the return value change of _file which is documented with a separate versionchanged directive for 3.7 and 3.8?

I feel it is too detailed.

Note that the _file attribute may be TextIOWrapper after rollover() anyway and the rollover() may be called implicitly.
The code depending on the specific type of the _file is fragile at first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Thu Nov 28 01:07:09 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Thu, 28 Nov 2019 06:07:09 +0000
Subject: [issue38933] unusual behaviour on list of dependable lambdas
In-Reply-To: <1574889723.55.0.16614385889.issue38933@roundup.psfhosted.org>
Message-ID: <1574921229.92.0.101875699893.issue38933@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Why exactly is [2,3] expected? In the first example, the inner list has two functions that are _exactly the same_. Each of them takes a, grabs i from outer scope, and returns a[i]. (And of course, at the moment of evaluation of these functions, i is 1.) 

Do you really expect i to be "spliced" into the lambda as a value at the moment of constructing the function? Would you also expect

lambda x: x + input('y? ')

to ask you for input?

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38933>
_______________________________________

From report at bugs.python.org  Thu Nov 28 01:15:44 2019
From: report at bugs.python.org (Vegard Stikbakke)
Date: Thu, 28 Nov 2019 06:15:44 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1574921744.08.0.752500718697.issue38932@roundup.psfhosted.org>


Vegard Stikbakke <vegard.stikbakke at gmail.com> added the comment:

Oh, right! Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Thu Nov 28 01:18:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Nov 2019 06:18:23 +0000
Subject: [issue38933] unusual behaviour on list of dependable lambdas
In-Reply-To: <1574889723.55.0.16614385889.issue38933@roundup.psfhosted.org>
Message-ID: <1574921903.43.0.75449372136.issue38933@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This could also help in understanding late binding that happens with the lambdas in the report : https://docs.python-guide.org/writing/gotchas/#late-binding-closures

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38933>
_______________________________________

From report at bugs.python.org  Thu Nov 28 01:18:39 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Nov 2019 06:18:39 +0000
Subject: [issue38898] Tkinter checkbutton switch on and off together
In-Reply-To: <1574457380.17.0.828287003226.issue38898@roundup.psfhosted.org>
Message-ID: <1574921919.28.0.319613743185.issue38898@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gpolo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38898>
_______________________________________

From report at bugs.python.org  Thu Nov 28 01:38:05 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Nov 2019 06:38:05 +0000
Subject: [issue38917] Color setting doesn't work in tkinter
In-Reply-To: <1574779669.0.0.89145609827.issue38917@roundup.psfhosted.org>
Message-ID: <1574923085.66.0.665170299646.issue38917@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I believe this is a duplicate of Issue36468 which identifies the issue which is apparently fixed in Tk 8.6.9+; it also provides a workaround for Tk 8.6.8.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Treeview: wrong color change

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38917>
_______________________________________

From report at bugs.python.org  Thu Nov 28 02:04:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Nov 2019 07:04:43 +0000
Subject: [issue38898] Tkinter checkbutton switch on and off together
In-Reply-To: <1574457380.17.0.828287003226.issue38898@roundup.psfhosted.org>
Message-ID: <1574924683.82.0.244979701426.issue38898@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Problem with Checkbutton and  duplicate last name components

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38898>
_______________________________________

From report at bugs.python.org  Thu Nov 28 02:17:15 2019
From: report at bugs.python.org (Anmol Kejriwal)
Date: Thu, 28 Nov 2019 07:17:15 +0000
Subject: [issue38935] File modes with '+' character does not give expected
 output
Message-ID: <1574925435.14.0.207210290632.issue38935@roundup.psfhosted.org>


New submission from Anmol Kejriwal <kejriwalanmol at gmail.com>:

The file modes a+, r+, w+ should read and write both. But a+ and w+ modes are not reading anything from the file. The RUN for the program is successful, but there is no output from the program.
Below is a simple program:

file=open("abcd.txt","w+")
l=["This is python.\nThis is an easy language.\nAnyone can learn this easily"]
file.writelines(l)
file.close()
file=open("abcd.txt","a+")   #Replacing with w+ also doesn't read.
file.write("123")      
t1=file.read()               #This read() does not work.
print(t1)                    #Does not print anything here.
file.close()

In r+ mode, it should write in the file without truncation and read it too. Instead, it is removing from the file, the equal number of characters I am trying to write in the file.
Below is the program:

file=open("abcd.txt","w+")
l=["This is python.\nThis is an easy language.\nAnyone can learn this easily"]
file.writelines(l)
file.close()
file=open("abcd.txt","r+")
file.write("123")
t1=file.read()
print(t1)

Output for this is:

s is python.
This is an easy language.
Anyone can learn this easily

----------
components: Windows
messages: 357609
nosy: anmolkejriwal, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: File modes with '+' character does not give expected output
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38935>
_______________________________________

From report at bugs.python.org  Thu Nov 28 02:20:26 2019
From: report at bugs.python.org (Anmol Kejriwal)
Date: Thu, 28 Nov 2019 07:20:26 +0000
Subject: [issue38935] File modes with '+' character does not give expected
 output
In-Reply-To: <1574925435.14.0.207210290632.issue38935@roundup.psfhosted.org>
Message-ID: <1574925626.58.0.929771931651.issue38935@roundup.psfhosted.org>


Anmol Kejriwal <kejriwalanmol at gmail.com> added the comment:

According to the doc,
https://docs.python.org/3/library/functions.html#open

The expected output for r+ mode in the program mentioned earlier should be:

123This is python.
This is an easy language.
Anyone can learn this easily

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38935>
_______________________________________

From report at bugs.python.org  Thu Nov 28 02:29:19 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 28 Nov 2019 07:29:19 +0000
Subject: [issue38935] File modes with '+' character does not give expected
 output
In-Reply-To: <1574925435.14.0.207210290632.issue38935@roundup.psfhosted.org>
Message-ID: <1574926159.34.0.407958015428.issue38935@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is expected behaviour. You read from the position of the file pointer, not the beginning of the file, so after writing to to the file, you have to use the seek() method to return to the beginning if you want to read what you just wrote.

https://docs.python.org/3/library/io.html

https://docs.python.org/3/tutorial/inputoutput.html#methods-of-file-objects

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38935>
_______________________________________

From report at bugs.python.org  Thu Nov 28 03:26:47 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Thu, 28 Nov 2019 08:26:47 +0000
Subject: [issue38933] unusual behaviour on list of dependable lambdas
In-Reply-To: <1574889723.55.0.16614385889.issue38933@roundup.psfhosted.org>
Message-ID: <1574929607.6.0.223610591654.issue38933@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Yes, I never really understood what problem people have with it. If I manually say

i = 0
f = lambda a: a[i]
i = 1
g = lambda a: a[i]

why does anyone expect functions f and g to be different? They have the same argument, and do the same thing with it. The bytecode is completely the same. How can they do different things?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38933>
_______________________________________

From report at bugs.python.org  Thu Nov 28 03:27:28 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Nov 2019 08:27:28 +0000
Subject: [issue26730] SpooledTemporaryFile rollover corrupts data silently
 when Unicode characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1574929648.28.0.655538211514.issue26730@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> Note that the _file attribute may be TextIOWrapper after rollover() anyway and the rollover() may be called implicitly.
The code depending on the specific type of the _file is fragile at first.

Okay, thanks for the detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Thu Nov 28 05:10:08 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 28 Nov 2019 10:10:08 +0000
Subject: [issue38021] Modify AIX platform_tag so it provides PEP425 needs
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574935808.64.0.000715483387035.issue38021@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
title: pep425 tag for AIX is inadequate -> Modify AIX platform_tag so it provides PEP425 needs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Thu Nov 28 05:11:50 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 28 Nov 2019 10:11:50 +0000
Subject: [issue38021] Modify AIX platform_tag so it provides PEP425 needs
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1574935910.2.0.412842655185.issue38021@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Updated this PR, and PRs in pypa/pip and pypa/packaging to all be "in sync".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Thu Nov 28 06:27:46 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 28 Nov 2019 11:27:46 +0000
Subject: [issue38817] Immutable types inplace operations work incorrect in
 async
In-Reply-To: <1573847808.01.0.483185624752.issue38817@roundup.psfhosted.org>
Message-ID: <1574940466.24.0.208596547072.issue38817@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Raymond correctly spotted the problem.

I think we should just close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38817>
_______________________________________

From report at bugs.python.org  Thu Nov 28 08:19:25 2019
From: report at bugs.python.org (tempest)
Date: Thu, 28 Nov 2019 13:19:25 +0000
Subject: [issue38931] pathlib.Path on Windows - parser issue
In-Reply-To: <1574874960.06.0.13653965118.issue38931@roundup.psfhosted.org>
Message-ID: <1574947165.39.0.538598997137.issue38931@roundup.psfhosted.org>


tempest <online_m at majck.com> added the comment:

But for course! (Slaps forehead!)

Yes, giving the Windows path as a raw string works. For all the times I've done '\t'.join(str(f) for f in some_array) to get a tab-delimited text string, I should have had a clue. Sorry for the noise, and thanks for setting me straight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38931>
_______________________________________

From report at bugs.python.org  Thu Nov 28 10:11:55 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 28 Nov 2019 15:11:55 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1574953915.73.0.795386202181.issue35003@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

There are more differences than Scripts/bin, like Windows use Lib but POSIX uses lib/pythonX.Y. IMO it?s probably better to stick with platform conventions, especially since those can be discovered with sysconfig.get_paths(expand=False).

I wonder whether it?d be a good idea to record what scheme was used to create the venv (in pyvenv.cfg). Any Python runtime can use that value in get_paths(scheme=..., expand=False) to know about the venv?s structure, even if the venv was created on another platform. This would be particularly useful to e.g. inspect a Windows-native venv in a WSL Python.

----------
nosy: +uranusjr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Thu Nov 28 10:42:19 2019
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 28 Nov 2019 15:42:19 +0000
Subject: [issue37347] Reference-counting problem in sqlite
In-Reply-To: <1561029299.63.0.688173181801.issue37347@roundup.psfhosted.org>
Message-ID: <1574955739.37.0.536304837559.issue37347@roundup.psfhosted.org>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
pull_requests: +16894
pull_request: https://github.com/python/cpython/pull/17413

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37347>
_______________________________________

From report at bugs.python.org  Thu Nov 28 10:44:14 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 28 Nov 2019 15:44:14 +0000
Subject: [issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
In-Reply-To: <1574847204.22.0.593056122111.issue38928@roundup.psfhosted.org>
Message-ID: <1574955854.57.0.0837824677004.issue38928@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 18d8edbbb6626ac9cdf1152a720811beb2230b33 by Vinay Sajip (Tzu-ping Chung) in branch '3.8':
bpo-38928: Remove upgrade_dependencies() from venv doc (GH-17410)
https://github.com/python/cpython/commit/18d8edbbb6626ac9cdf1152a720811beb2230b33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38928>
_______________________________________

From report at bugs.python.org  Thu Nov 28 10:45:41 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 28 Nov 2019 15:45:41 +0000
Subject: [issue38928] EnvBuilder.upgrade_dependencies() does not exist on 3.8
In-Reply-To: <1574847204.22.0.593056122111.issue38928@roundup.psfhosted.org>
Message-ID: <1574955941.65.0.0962067792744.issue38928@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38928>
_______________________________________

From report at bugs.python.org  Thu Nov 28 10:48:13 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 28 Nov 2019 15:48:13 +0000
Subject: [issue38931] pathlib.Path on Windows - parser issue
In-Reply-To: <1574874960.06.0.13653965118.issue38931@roundup.psfhosted.org>
Message-ID: <1574956093.65.0.678825399859.issue38931@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

You're welcome :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38931>
_______________________________________

From report at bugs.python.org  Thu Nov 28 11:46:31 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Nov 2019 16:46:31 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1574959591.26.0.0916003230275.issue38920@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset b74a6f14b94d36fb72b1344663e81776bf450847 by Steve Dower in branch '3.8':
bpo-38920: Add audit hooks for when sys.excepthook and sys.unraisablehook are invoked (GH-17392)
https://github.com/python/cpython/commit/b74a6f14b94d36fb72b1344663e81776bf450847


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Thu Nov 28 11:46:31 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Nov 2019 16:46:31 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1574959591.41.0.685344356796.issue38920@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset bea33f5e1db6e4a554919a82894f44568576e979 by Steve Dower in branch 'master':
bpo-38920: Add audit hooks for when sys.excepthook and sys.unraisable hooks are invoked (GH-17392)
https://github.com/python/cpython/commit/bea33f5e1db6e4a554919a82894f44568576e979


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Thu Nov 28 11:46:31 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Nov 2019 16:46:31 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1574959591.26.0.0916003230275.issue38920@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset b74a6f14b94d36fb72b1344663e81776bf450847 by Steve Dower in branch '3.8':
bpo-38920: Add audit hooks for when sys.excepthook and sys.unraisablehook are invoked (GH-17392)
https://github.com/python/cpython/commit/b74a6f14b94d36fb72b1344663e81776bf450847


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Thu Nov 28 11:47:39 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Nov 2019 16:47:39 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1574959659.18.0.516438950412.issue38920@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38920>
_______________________________________

From report at bugs.python.org  Thu Nov 28 12:11:33 2019
From: report at bugs.python.org (kiranmai velishala)
Date: Thu, 28 Nov 2019 17:11:33 +0000
Subject: [issue38936] fatal error during installation 0x80070643 during python
 installation
Message-ID: <1574961093.76.0.301097731298.issue38936@roundup.psfhosted.org>


New submission from kiranmai velishala <kiranmai.velishala at gmail.com>:

Installing Python 3.8, Windows 10 64bit, exits installer and dumps the following error code to log.

[3D8C:422C][2019-11-28T22:23:28]e000: Error 0x80070643: Failed to run maintanance mode for MSI package.
[3D8C:422C][2019-11-28T22:23:28]e000: Error 0x80070643: Failed to configure per-user MSI package.
[3D8C:422C][2019-11-28T22:23:28]i319: Applied execute package: tcltk_JustForMe, result: 0x80070643, restart: None
[3D8C:422C][2019-11-28T22:23:28]e000: Error 0x80070643: Failed to execute MSI package.
[3D8C:422C][2019-11-28T22:23:28]i301: Applying rollback package: tcltk_JustForMe, action: Modify, path: C:\Users\kivelish\AppData\Local\Package Cache\{978278A0-0090-4A9C-8610-001061A495AF}v3.8.150.0\tcltk.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Users\kivelish\AppData\Local\Programs\Python\Python38-32" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.8-32\InstalledFeatures" REMOVE="AssociateFiles"'
[3D8C:422C][2019-11-28T22:23:30]e000: Error 0x80070643: Failed to run maintanance mode for MSI package.
[3D8C:422C][2019-11-28T22:23:30]e000: Error 0x80070643: Failed to configure per-user MSI package.

0x80070643 - Fatal Error during installation

----------
components: Windows
files: FATAL_ISSUE.zip
messages: 357622
nosy: kiranmai velishala, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: fatal error during installation 0x80070643 during python installation
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file48746/FATAL_ISSUE.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38936>
_______________________________________

From report at bugs.python.org  Thu Nov 28 12:25:46 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Nov 2019 17:25:46 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1574961946.79.0.168492059319.issue38916@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> How about note it in the documentation and logging rather than removing them?

Yep, docs and raising DeprecationWarning should be good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Thu Nov 28 12:29:59 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Nov 2019 17:29:59 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1574962199.63.0.861838118444.issue35003@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I've personally never come across Scripts in any other situation than virtual environments, but that isn't saying much about my Windows exposure either. :)

Basically activation is the biggest stumbling block I find with new users when it comes to trying to teach them about using virtual environments and this platform difference doesn't help. I would like to come up with _some_ solution to make it easier, even if it's something I have to put into the Python Launcher (although trying to get people to even agree on a name for virtual environments created beside the code turns out to be a hot topic). I would consider trying to come up with code so we have a `pipenv shell`/`conda shell` equivalent, but I've been told it is not pleasant to try and make work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Thu Nov 28 12:45:44 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 28 Nov 2019 17:45:44 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1574963144.44.0.364426988855.issue35003@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Basically activation is the biggest stumbling block I find with new users

Surely "on native Windows you run venv-path\Scripts\activate[.ps1], on POSIX you use source venv-path/bin/activate" isn't *that* hard for new users to grok, and would cover the vast majority of users? (i.e. not including the other, less-common POSIX shells.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Thu Nov 28 13:22:18 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 28 Nov 2019 18:22:18 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1574965338.86.0.123363253012.issue35003@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

> Surely "on native Windows you run venv-path\Scripts\activate[.ps1], on POSIX you use source venv-path/bin/activate" isn't *that* hard for new users to grok [...]?

The if-Windows-X-else-Y part isn?t that hard; it?s the activate part that is :p

I think Brett is thinking about eliminating the manual activate part entirely, but any tool trying to automate that needs to do a lot of platform-specific checks.

---

> I've personally never come across Scripts in any other situation than virtual environments [...].

Windows use a Scripts directory to store? scripts (Setuptools terminology, i.e. console and gui script entry points). So e.g. the global pip.exe would be at "{sys.prefix}\Scripts\pip.exe" (or is it sys.exec_prefix?) `pip install --user` would also install scripts into `%APPDATA%\Programs\Python\PythonXY\Scripts`. So venv?s setup is consistent with the rest of Python.

This directory structure can be expanded from sysconfig. So the proposal in my previous comment is to record the scheme in pyvenv.cfg, so you can have something like

def read_venv_scheme(env_dir):
    with open(os.path.join(env_dir, 'pyvenv.cfg')) as f:
        for line in f:
            key, value = (p.strip() for p in line.split('='))
            if key == 'scheme':
                return value

def get_venv_environ_patch(env_dir):
    scheme = read_venv_scheme(env_dir)
    bin_dir = sysconfig.get_path('scripts', scheme=scheme, expand=False).format(base=env_dir)
    return {'VIRTUAL_ENV': env_dir, 'PATH': bin_dir}

and this would give you the appropriate value on any platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Thu Nov 28 13:44:10 2019
From: report at bugs.python.org (Chris Billington)
Date: Thu, 28 Nov 2019 18:44:10 +0000
Subject: [issue38937] NameError in list comprehension within .pth file
Message-ID: <1574966650.18.0.796869926864.issue38937@roundup.psfhosted.org>


New submission from Chris Billington <chrisjbillington at gmail.com>:

The following one-liner works fine in a regular Python interpreter:

$ python -c 'import sys; x = 5; [print(x + i) for i in range(5)]'
5
6
7
8
9

But in a .pth file, it raises a NameError:

$ echo 'import sys; x = 5; [print(x + i) for i in range(5)]' | sudo tee /usr/lib/python3.8/site-packages/test.pth
$ python
Error processing line 1 of /usr/lib/python3.8/site-packages/test.pth:

  Traceback (most recent call last):
    File "/usr/lib/python3.8/site.py", line 169, in addpackage
      exec(line)
    File "<string>", line 1, in <module>
    File "<string>", line 1, in <listcomp>
  NameError: name 'x' is not defined

Remainder of file ignored
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Since site.py uses exec() to exec each line of a .pth file, I thought I'd compare with that. It also works fine:

$ python -c 'exec("import sys; x = 5; [print(x + i) for i in range(5)]")'
5
6
7
8
9

This slight modification (the variable being used in the next statement still, but not within the loop of the comprehension) does not raise a NameError:

$ echo 'import sys; x = 5; [print(i) for i in range(x)]' | sudo tee /usr/lib/python3.8/site-packages/test.pth
import sys; x = 5; [print(i) for i in range(x)]
$ python
0
1
2
3
4
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

I know .pth file processing is very early in interpreter startup such that many things aren't working yet, but I wouldn't expect using a name defined outside a list comprehension within the loop body of said list comprehension not to work.

The following is fine also, showing that using names from outside the list comprehension doesn't always break:

$ echo 'import sys; [print(sys) for i in range(5)]' | sudo tee /usr/lib/python3.8/site-packages/test.pth
import sys; [print(sys) for i in range(5)]
$ python
<module 'sys' (built-in)>
<module 'sys' (built-in)>
<module 'sys' (built-in)>
<module 'sys' (built-in)>
<module 'sys' (built-in)>
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

This is fine too:

$ echo 'import sys; [print(str(sys) * i) for i in range(5)]' | sudo tee /usr/lib/python3.8/site-packages/test.pth
import sys; [print(str(sys) * i) for i in range(5)]
$ python

<module 'sys' (built-in)>
<module 'sys' (built-in)><module 'sys' (built-in)>
<module 'sys' (built-in)><module 'sys' (built-in)><module 'sys' (built-in)>
<module 'sys' (built-in)><module 'sys' (built-in)><module 'sys' (built-in)><module 'sys' (built-in)>
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 


My use case is looping over subdirs of a directory and adding them all to sys.path to provide similar functionality to python setup.py develop, with all python vcs repositories within a specific directory being prepended to sys.path, rather than having to add them one-by-one. I probably won't end up doing what I'm doing this way, but in any case the above seems like it's a bug, unless I'm grossly misunderstanding something.

----------
components: Interpreter Core
messages: 357627
nosy: Chris Billington
priority: normal
severity: normal
status: open
title: NameError in list comprehension within .pth file
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38937>
_______________________________________

From report at bugs.python.org  Thu Nov 28 14:04:45 2019
From: report at bugs.python.org (Tim Peters)
Date: Thu, 28 Nov 2019 19:04:45 +0000
Subject: [issue38933] unusual behaviour on list of dependable lambdas
In-Reply-To: <1574889723.55.0.16614385889.issue38933@roundup.psfhosted.org>
Message-ID: <1574967885.52.0.911803138248.issue38933@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

This behavior is intended and expected, so I'm closing this.

As has been explained, in any kind of function (whether 'lambda' or 'def'), a non-local variable name resolves to its value at the time the function is evaluated, not the value it _had_ at the time the function was defined.

If you need to use bindings in effect at the time the function is defined, then you need to do something to force that to happen.  A common way is to abuse Python's default-argument mechanism to initialize a local argument to the value of a non-local variable at function definition time.  In practice, e.g., this means changing the

    lambda a:

in your first example to

    lambda a, i=i:

Then, when the lambda is defined ('lambda' and 'def' are executable statements in Python! not just declarations), the then-current binding of non-local variable 'i' is captured and saved away as the default value of the local argument name 'i'.

----------
nosy: +tim.peters
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38933>
_______________________________________

From report at bugs.python.org  Thu Nov 28 14:42:24 2019
From: report at bugs.python.org (Chris Billington)
Date: Thu, 28 Nov 2019 19:42:24 +0000
Subject: [issue38937] NameError in list comprehension within .pth file
In-Reply-To: <1574966650.18.0.796869926864.issue38937@roundup.psfhosted.org>
Message-ID: <1574970144.58.0.16375523531.issue38937@roundup.psfhosted.org>


Chris Billington <chrisjbillington at gmail.com> added the comment:

I see. site.py calls exec() from within a function, and therefore the code is executed in the context of that function's locals and the site module globals. This means the code in .pth files can access (but not add new) local names from the site.addpackage() function:

$ echo 'import sys; f.close()' | sudo tee /usr/lib/python3.8/site-packages/test.pth
import sys; f.close()
$ python
Fatal Python error: init_import_size: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
  File "/usr/lib/python3.8/site.py", line 580, in <module>
    main()
  File "/usr/lib/python3.8/site.py", line 567, in main
    known_paths = addsitepackages(known_paths)
  File "/usr/lib/python3.8/site.py", line 350, in addsitepackages
    addsitedir(sitedir, known_paths)
  File "/usr/lib/python3.8/site.py", line 208, in addsitedir
    addpackage(sitedir, name, known_paths)
  File "/usr/lib/python3.8/site.py", line 164, in addpackage
    for n, line in enumerate(f):
ValueError: I/O operation on closed file.

The example with the sys module worked because sys is in the globals the site module already.

Probably site.addpackage() should exec() code it its own environment:

if line.startswith(("import ", "import\t")):
    exec(line, {})
    continue

(added empty dict for exec() call)

or for backward compatibility for .pth files that are using globals from the site module without importing them (such as sys or os):

if line.startswith(("import ", "import\t")):
    exec(line, globals().copy())
    continue

This resolves the original issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38937>
_______________________________________

From report at bugs.python.org  Thu Nov 28 15:13:12 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Nov 2019 20:13:12 +0000
Subject: [issue38937] NameError in list comprehension within .pth file
In-Reply-To: <1574966650.18.0.796869926864.issue38937@roundup.psfhosted.org>
Message-ID: <1574971992.2.0.572968008775.issue38937@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38937>
_______________________________________

From report at bugs.python.org  Thu Nov 28 17:18:48 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 28 Nov 2019 22:18:48 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1574979528.51.0.778026235816.issue35003@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I think Brett is thinking about eliminating the manual activate part entirely, but any tool trying to automate that needs to do a lot of platform-specific checks.

If you have more than one venv then it seems like some manual step is required to switch between them. What about a tool like Pew (Python Env Wrapper), which from the README "is completely shell-agnostic and thus works on bash, zsh, fish, powershell, etc."

https://github.com/berdario/pew

I haven't used in under Windows, but it works a treat on POSIX for me, YMMV of course.

Of course, scripts installed in venvs never need activation to run - they pick up the correct interpreter from their venv automatically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Thu Nov 28 18:53:10 2019
From: report at bugs.python.org (Paulo Henrique Silva)
Date: Thu, 28 Nov 2019 23:53:10 +0000
Subject: [issue38500] Provide a way to get/set PyInterpreterState.frame_eval
 without needing to access interpreter internals
In-Reply-To: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>
Message-ID: <1574985190.44.0.793990777541.issue38500@roundup.psfhosted.org>


Change by Paulo Henrique Silva <ph.silva at gmail.com>:


----------
nosy: +phsilva

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38500>
_______________________________________

From report at bugs.python.org  Thu Nov 28 21:44:21 2019
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 29 Nov 2019 02:44:21 +0000
Subject: [issue38938] Iterable merge performance and inclusion in itertools
Message-ID: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

Although the implementation of the heapq.merge function uses an underlying heap structure, its behavior centers on iterators. For this reason, I believe there should either be an alias to this function in the itertools module or at least a recipe in the itertools docs describing the use of heapq.merge.

Furthermore, I have an implementation (attached) of heapq.merge that is twice as fast for two iterables (as used in mergesort and other common cases), and is faster for up to 6 or 7 iterables. I think it would be nice to special-case this for small numbers of iterables for this significant speedup.

----------
components: Library (Lib)
files: iter_merge.py
messages: 357631
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Iterable merge performance and inclusion in itertools
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48747/iter_merge.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Thu Nov 28 22:01:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Nov 2019 03:01:55 +0000
Subject: [issue38938] Iterable merge performance and inclusion in itertools
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1574996515.76.0.690379021244.issue38938@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Thu Nov 28 22:06:21 2019
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 29 Nov 2019 03:06:21 +0000
Subject: [issue38938] Iterable merge performance and inclusion in itertools
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1574996781.85.0.871691999615.issue38938@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

The following seems like it is a short, readable recipe for itertools.

----------
Added file: https://bugs.python.org/file48748/merge_recipe.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Thu Nov 28 23:04:27 2019
From: report at bugs.python.org (=?utf-8?b?SW9udcibIENpb2PDrnJsYW4=?=)
Date: Fri, 29 Nov 2019 04:04:27 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574832484.9.0.145743665934.issue38924@roundup.psfhosted.org>
Message-ID: <3bce3e39-b765-e781-4de4-b0861d0cad6f@gmail.com>


Ionu? Cioc?rlan <ionut.ciocirlan at gmail.com> added the comment:

> Can you please add an example of how normalize() should behave?

```
>>> mypath = PurePosixPath("foo/bar/bzz")
>>> mypath /= "../../"
>>> mypath
PurePosixPath('foo/bar/bzz/../..')
>>> mypath = mypath.normalize()
>>> mypath
PurePosixPath('foo')
>>> mypath /= "../../../there"
>>> mypath
PurePosixPath('foo/../../../there')
>>> mypath = mypath.normalize()
>>> mypath
PurePosixPath('../../there')
>>> mypath /= "../../and/back/again"
>>> mypath
PurePosixPath('../../there/../../and/back/again')
>>> mypath = mypath.normalize()
>>> mypath
PurePosixPath('../../../and/back/again')
```

> I assume you want the same behaviour as os.path.normpath which already accepts a pathlike object to be added to pathlib.

Yes, exactly the same behaviour, but arguing that normpath() can take a pathlib object is just saying that it saves you from doing an intermediate str(), which is, well, nice, but still not pretty. Consider `mypath = mypath.normalize()` vs. `mypath = PurePosixPath(normpath(mypath))`.

> Do note that Path inherits from PurePath, so providing a normalize() method on the latter means it will end up on the former.

That could be "circumvented" with a bit of code shuffling, e.g. moving everything from `PurePath` to a `PathBase` or `_Path` or somesuch, and forking the inheritance from there. On the other hand, it might be useful. I personally can't think of a scenario, but the GNU folk certainly think so, see `realpath --logical`: https://www.gnu.org/software/coreutils/manual/html_node/realpath-invocation.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38924>
_______________________________________

From report at bugs.python.org  Fri Nov 29 00:05:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Nov 2019 05:05:11 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1575003911.42.0.474402712239.issue38924@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> Yes, exactly the same behaviour, but arguing that normpath() can take a pathlib object is just saying that it saves you from doing an intermediate str(), which is, well, nice, but still not pretty. Consider `mypath = mypath.normalize()` vs. `mypath = PurePosixPath(normpath(mypath))`.

>From my experience in the past the intention has been to keep the API minimal and below are some recent additions. Many discussions lead to the answer over using a function that accepts a pathlike object already and if not add support for it than add the API to pathlib itself. I will leave it to the experts on this.

realink : issue30618
link_to : issue26978

----------
nosy: +pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38924>
_______________________________________

From report at bugs.python.org  Fri Nov 29 01:58:01 2019
From: report at bugs.python.org (Joel Rosdahl)
Date: Fri, 29 Nov 2019 06:58:01 +0000
Subject: [issue31456] SimpleCookie fails to parse any cookie if an entry has
 whitespace in the name
In-Reply-To: <1505328383.45.0.696771060303.issue31456@psf.upfronthosting.co.za>
Message-ID: <1575010681.19.0.908371583847.issue31456@roundup.psfhosted.org>


Change by Joel Rosdahl <joel.rosdahl at gmail.com>:


----------
nosy: +Joel Rosdahl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31456>
_______________________________________

From report at bugs.python.org  Fri Nov 29 02:23:34 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 29 Nov 2019 07:23:34 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1575012214.54.0.764293621254.issue38924@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I think the real issue here

> mypath = PurePosixPath(normpath(mypath))

is the PurePosixPath wrapper. It is nice that normpath _accepts_ pathlike objects, but it should then not return a generic str. It should try to return an object of the same type.

Of course it's harder to do, especially in presence of pathlike objects of unknown classes, but with some reasonable assumptions on the constructors, it can be done---and it's much more useful. The similar debate, with similar conclusions, has already happened with datetime-like objects.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38924>
_______________________________________

From report at bugs.python.org  Fri Nov 29 04:18:21 2019
From: report at bugs.python.org (Leif Middelschulte)
Date: Fri, 29 Nov 2019 09:18:21 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1575019101.51.0.345500684366.issue38893@roundup.psfhosted.org>


Leif Middelschulte <leif.middelschulte at gmail.com> added the comment:

@Christian Heimes: is there anything else you need from me? Is this the wrong forum?

As discussed in the referenced GitHub issue, some SELinux people suggest it might be a fault in how Python determines (?) it's running within a container environment and how to act upon it.

Does it determine it at all? Does it use libselinux[0]?

Background: I came across this issue by building a Linux distribution using Yocto in a Fedora:30 podman managed container with host volumes bound in. I guess that it is a fairly common scenario in the near future.

[0] https://danwalsh.livejournal.com/73099.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Fri Nov 29 05:08:16 2019
From: report at bugs.python.org (dongjs)
Date: Fri, 29 Nov 2019 10:08:16 +0000
Subject: [issue38939] Using Python as a Calculator
Message-ID: <1575022096.89.0.81734853604.issue38939@roundup.psfhosted.org>


New submission from dongjs <dongjssd at 163.com>:

>>> 17 / 3  # classic division returns a float
5.666666666666667

this example is error 

what i test is below

>>> 17.0 / 3
5.666666666666667
>>> 17 / 3
5

----------
messages: 357637
nosy: dongjs
priority: normal
severity: normal
status: open
title: Using Python as a Calculator
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38939>
_______________________________________

From report at bugs.python.org  Fri Nov 29 06:04:39 2019
From: report at bugs.python.org (=?utf-8?q?Cyril_Nicod=C3=A8me?=)
Date: Fri, 29 Nov 2019 11:04:39 +0000
Subject: [issue30988] Exception parsing invalid email address headers starting
 or ending with dot
In-Reply-To: <1500699002.76.0.343337119039.issue30988@psf.upfronthosting.co.za>
Message-ID: <1575025479.64.0.111734501172.issue30988@roundup.psfhosted.org>


Cyril Nicod?me <contact at cnicodeme.com> added the comment:

Hi!

I confirm this problem too, also with the SMTPUTF8 policy.

I was able to reproduce this error on my end (Python v3.7.5).

Note that when calling `message_from_bytes` without policy, there is no errors.

----------
nosy: +cnicodeme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30988>
_______________________________________

From report at bugs.python.org  Fri Nov 29 06:19:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Nov 2019 11:19:39 +0000
Subject: [issue38939] Using Python as a Calculator
In-Reply-To: <1575022096.89.0.81734853604.issue38939@roundup.psfhosted.org>
Message-ID: <1575026379.62.0.627580089135.issue38939@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Maybe you are looking for floor division?

https://docs.python.org/3.3/reference/expressions.html#binary-arithmetic-operations

> The / (division) and // (floor division) operators yield the quotient of their arguments. The numeric arguments are first converted to a common type. Division of integers yields a float, while floor division of integers results in an integer; the result is that of mathematical division with the ?floor? function applied to the result. Division by zero raises the ZeroDivisionError exception.

Python 3.8 

>>> 17 / 3
5.666666666666667
>>> 17.0 / 3
5.666666666666667
>>> 17 // 3
5

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38939>
_______________________________________

From report at bugs.python.org  Fri Nov 29 06:30:18 2019
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Fri, 29 Nov 2019 11:30:18 +0000
Subject: [issue38940] Add a new functools.cast() function
Message-ID: <1575027018.53.0.577122274637.issue38940@roundup.psfhosted.org>


New submission from Ugra D?niel <daniel.ugra at gmail.com>:

In some cases it would be really helpful to have a decorator which automagically casts returned value to a different type.

Particularly, instead of writing something like this:

def example():
    result = []

    for ...:
        result.append(item)

    return result

...this would do the magic:

@functools.cast(list)
def example():
    for ...:
        yield item

On the positive side (apart from its compactness) when an implementation changes from list to set, .append() does not need to be changed to .add().

Of course on the caller side one can always write list(example()) but sometimes this transformation needs to be done on implementation side for architectural reasons.

Pseudocode for proposed functools.cast():

def cast(type):
    def wrapper(func):
        @wraps(func)
        def newfunc(*args, **keywords):
            return type(func(*args, **keywords))

        return newfunc

    return wrapper

----------
components: Library (Lib)
messages: 357640
nosy: daniel.ugra
priority: normal
severity: normal
status: open
title: Add a new functools.cast() function
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38940>
_______________________________________

From report at bugs.python.org  Fri Nov 29 06:31:20 2019
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Fri, 29 Nov 2019 11:31:20 +0000
Subject: [issue38940] Add a new functools.cast() function
In-Reply-To: <1575027018.53.0.577122274637.issue38940@roundup.psfhosted.org>
Message-ID: <1575027080.87.0.730809471631.issue38940@roundup.psfhosted.org>


Ugra D?niel <daniel.ugra at gmail.com> added the comment:

Currently, the closest functionality I can think of (using standard library functions only):

@functools.partial(lambda func: functools.wraps(func)(lambda *args, **keywords: list(func(*args, **keywords))))

Or without proper wrapping:

@functools.partial(lambda func: lambda *args, **keywords: list(func(*args, **keywords)))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38940>
_______________________________________

From report at bugs.python.org  Fri Nov 29 08:21:05 2019
From: report at bugs.python.org (Philip Rowlands)
Date: Fri, 29 Nov 2019 13:21:05 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
Message-ID: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>


New submission from Philip Rowlands <pythonbugs at dimebar.com>:

Steps to reproduce:

$ python3.7
Python 3.7.2 (default, May 13 2019, 13:52:56)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> bool(ET.fromstring("<a><b><c></c></b></a>").find(".//c"))
False


$ python3.7
Python 3.7.2 (default, May 13 2019, 13:52:56)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['_elementtree'] = None
>>> import xml.etree.ElementTree as ET
>>> bool(ET.fromstring("<a><b><c></c></b></a>").find(".//c"))
__main__:1: FutureWarning: The behavior of this method will change in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.


This is (almost) the smallest test case, but in real code what I was trying to write was:
```
# check the result code is ok
if response.find("./result[@code='ok']"):
    return True
```

The unintuitive bool() behaviour was surprising, compared to other typical True / False determinations on objects, and I think what the FutureWarning is trying to avoid.

Please implement the same warning for bool(Element) in _elementtree.c as exists in ElementTree.py. bpo29204 was making similar alignments between the versions, but didn't consider this FutureWarning.

----------
components: Library (Lib)
messages: 357642
nosy: philiprowlands
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.Element inconsistent warning for bool
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38941>
_______________________________________

From report at bugs.python.org  Fri Nov 29 08:47:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Nov 2019 13:47:07 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575035227.49.0.467833284388.issue38941@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +XML
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38941>
_______________________________________

From report at bugs.python.org  Fri Nov 29 10:36:37 2019
From: report at bugs.python.org (Chris Billington)
Date: Fri, 29 Nov 2019 15:36:37 +0000
Subject: [issue38937] NameError in list comprehension within .pth file
In-Reply-To: <1574966650.18.0.796869926864.issue38937@roundup.psfhosted.org>
Message-ID: <1575041797.51.0.388884498792.issue38937@roundup.psfhosted.org>


Chris Billington <chrisjbillington at gmail.com> added the comment:

Sorry for the spamming, realised I misunderstood further.

The original behaviour isn't because the exec'd code can't create new local variables - it can - it's because of the documented behaviour of exec when it gets different dicts for globals and locals:

"If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition"

So the new scope made by the list comprehension can't access the enclosing scope in which the new variable was defined, because that's how scoping works in class definitions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38937>
_______________________________________

From report at bugs.python.org  Fri Nov 29 10:41:32 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 29 Nov 2019 15:41:32 +0000
Subject: [issue38940] Add a new functools.cast() function
In-Reply-To: <1575027018.53.0.577122274637.issue38940@roundup.psfhosted.org>
Message-ID: <1575042092.24.0.164577743979.issue38940@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38940>
_______________________________________

From report at bugs.python.org  Fri Nov 29 12:00:53 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 29 Nov 2019 17:00:53 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575046853.99.0.331744518675.issue38941@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Agreed that both should behave the same.

And, we should finally decide whether this should really be changed or not. The current behaviour is counter-intuitive, but it's been like that forever and lots of code depends on it in one way or another, so ?

----------
stage:  -> needs patch
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38941>
_______________________________________

From report at bugs.python.org  Fri Nov 29 12:14:26 2019
From: report at bugs.python.org (Philip Rowlands)
Date: Fri, 29 Nov 2019 17:14:26 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575047666.02.0.0620979452207.issue38941@roundup.psfhosted.org>


Philip Rowlands <pythonbugs at dimebar.com> added the comment:

It's easier to justify a change in behaviour if the warning is emitted. With no legacy concerns, I would be happy for bool() to change, but I'm not the one who would receive the grumbly tickets.

How about emitting the warning in the next release, then assessing the behaviour change for version n+2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38941>
_______________________________________

From report at bugs.python.org  Fri Nov 29 12:23:40 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Nov 2019 17:23:40 +0000
Subject: [issue38936] fatal error during installation 0x80070643 during python
 installation
In-Reply-To: <1574961093.76.0.301097731298.issue38936@roundup.psfhosted.org>
Message-ID: <1575048220.3.0.998774773117.issue38936@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It looks like you had a previous install that wasn't cleaned up properly (all the packages are still registered). Any idea what may have caused that?

The easiest workaround will be to use Programs and Features to find and repair the previous install ("Modify" in P&F and then "Repair" in the Python installer). You might be able to skip straight to Uninstall here, but sometimes that won't work without repairing first. After you've repaired it, your install/upgrade should be okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38936>
_______________________________________

From report at bugs.python.org  Fri Nov 29 12:57:16 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Nov 2019 17:57:16 +0000
Subject: [issue38939] Using Python as a Calculator
In-Reply-To: <1575022096.89.0.81734853604.issue38939@roundup.psfhosted.org>
Message-ID: <1575050236.78.0.335059132147.issue38939@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

If you're using Python 2.7 then that would explain what you're seeing. You can either upgrade to Python 3 or use `from __future__ import division` to get the result you're after.

----------
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38939>
_______________________________________

From report at bugs.python.org  Fri Nov 29 13:02:32 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Nov 2019 18:02:32 +0000
Subject: [issue38940] Add a new functools.cast() function
In-Reply-To: <1575027018.53.0.577122274637.issue38940@roundup.psfhosted.org>
Message-ID: <1575050552.96.0.395384382721.issue38940@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

First off, thanks for the suggestion!

But there are two things to say about this. One, that isn't actually casting as Python doesn't have the concept of casting like in statically typed languages since everything is dynamically typed.

Two, the solution is so short and simple but not widely needed enough that I don't think this warrants addition in the stdlib. And since you're changing what the function returns you probably need a new docstring anyway, which means having to do a normal wrapping of the function.

So thanks for the idea but I don't think we will be adding this to the stdlib (obviously feel free to put this up on PyPI or as a gist somewhere and share it in a blog post or something.

----------
nosy: +brett.cannon
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38940>
_______________________________________

From report at bugs.python.org  Fri Nov 29 13:38:57 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Nov 2019 18:38:57 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1575052737.89.0.605933008485.issue35003@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> Surely "on native Windows you run venv-path\Scripts\activate[.ps1], on POSIX you use source venv-path/bin/activate" isn't *that* hard for new users to grok, and would cover the vast majority of users?

Sure, but how many times do we need to make people type, write, or say that exact line instead of a single line of "you activate by doing <command>"?

> So venv?s setup is consistent with the rest of Python.

Right, it's a Python-on-Windows thing, not a Windows thing itself to my knowledge.

> I think Brett is thinking about eliminating the manual activate part entirely

I'm actually after a single command to handle activation of a virtual environment. It's a point of friction on your first day of learning Python and I have seen it solved multiple times at this point by multiple tools. This seemed like a potential simple way to solve it to me, but apparently not everyone agrees. ;)

Now I realize that if we don't worry about the prompt changing it's actually very straight-forward, and so maybe proposing a simple `venv --activate <path>` that does nothing more than set those key environment variables and prints out a message about what is happening is enough to do the trick (and if people want the prompt to change they can tweak their shell configs to detect something like `__VENV_PROMPT__` being set and use it appropriately).

> Of course, scripts installed in venvs never need activation to run

Sure, but then that doesn't mean activation isn't convenient. :) Otherwise what is the point of having the activation scripts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Fri Nov 29 13:47:22 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Nov 2019 18:47:22 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1575053242.4.0.841258843491.issue38924@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> From my experience in the past the intention has been to keep the API minimal

Correct, all of os.path and shutils does not need to end up in pathlib. :) Hence why the request to add things is always tough as we have to try and strike a balance of useful but not overwhelming/overdone (and what is "useful" varies from person to person).

> It is nice that normpath _accepts_ pathlike objects, but it should then not return a generic str. It should try to return an object of the same type.

It's an interesting idea, but it's also difficult to get right, even with assumptions as things that represent a path are nowhere near as unified as dates. There would also be a ton of converting back and forth in os.path as functions call other functions to get the path, manipulate it, and then wrap it back up.

But if someone can come up with a concrete proposal with some example implementation and brings it to python-ideas it could be discussed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38924>
_______________________________________

From report at bugs.python.org  Fri Nov 29 15:19:33 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 29 Nov 2019 20:19:33 +0000
Subject: [issue17068] peephole optimization for constant strings
In-Reply-To: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za>
Message-ID: <1575058773.27.0.4925769353.issue17068@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I think this operation is more suitable for AST optimizer then peephole but i'm still not sure if such a conversion gains anything compared to usage of old type string formattings.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17068>
_______________________________________

From report at bugs.python.org  Fri Nov 29 15:20:49 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 29 Nov 2019 20:20:49 +0000
Subject: [issue38942] Possible assertion failures in csv.Dialect()
Message-ID: <1575058849.67.0.456727251778.issue38942@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

dialect_new() in Modules/_csv.c calls PyObject_GetAttrString() repeatedly without
checking if an error occurred. If an exception (like MemoryError) is raised during one of the
PyObject_GetAttrString() calls, an assertion failure will occur during the next call.

----------
components: Extension Modules
messages: 357652
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Possible assertion failures in csv.Dialect()
type: crash
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38942>
_______________________________________

From report at bugs.python.org  Fri Nov 29 15:23:20 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 29 Nov 2019 20:23:20 +0000
Subject: [issue38942] Possible assertion failures in csv.Dialect()
In-Reply-To: <1575058849.67.0.456727251778.issue38942@roundup.psfhosted.org>
Message-ID: <1575059000.1.0.947398317792.issue38942@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38942>
_______________________________________

From report at bugs.python.org  Fri Nov 29 15:33:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Nov 2019 20:33:21 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1575059601.37.0.737216688978.issue38924@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There were reasons why something like PurePath.normalize() was not added at first place. os.path.normpath() is broken by design. It does not work as you expect in case when the .. component is preceeded by a symlink. Its behvior can lead to bugs and maybe even security issues. We did not want to add something so dubious in the pathlib module. Path.resolve() is the correct way.

So I suggest to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38924>
_______________________________________

From report at bugs.python.org  Fri Nov 29 16:14:46 2019
From: report at bugs.python.org (JohnnyNajera)
Date: Fri, 29 Nov 2019 21:14:46 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
Message-ID: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>


New submission from JohnnyNajera <JohnnyNajera at protonmail.com>:

In Ubuntu 19.10 and probably earlier versions of Ubuntu, the autocomplete window  doesn't show up when expected. This is probably due to wm_geometry called in a context in which it has no effect.

----------
assignee: terry.reedy
components: IDLE
messages: 357654
nosy: JohnnyNajera, terry.reedy
priority: normal
severity: normal
status: open
title: Idle autocomplete window doesn't show up
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Fri Nov 29 16:16:24 2019
From: report at bugs.python.org (JohnnyNajera)
Date: Fri, 29 Nov 2019 21:16:24 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575062184.77.0.937924671168.issue38943@roundup.psfhosted.org>


Change by JohnnyNajera <JohnnyNajera at protonmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Fri Nov 29 16:21:27 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Fri, 29 Nov 2019 21:21:27 +0000
Subject: [issue38902] image/webp support in mimetypes
In-Reply-To: <1574548382.26.0.67471558876.issue38902@roundup.psfhosted.org>
Message-ID: <1575062487.79.0.8896147652.issue38902@roundup.psfhosted.org>


Change by Florian Dahlitz <f2dahlitz at freenet.de>:


----------
nosy: +DahlitzFlorian

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38902>
_______________________________________

From report at bugs.python.org  Fri Nov 29 17:22:34 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 29 Nov 2019 22:22:34 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1575066154.37.0.890114710159.issue35003@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> so maybe proposing a simple `venv --activate <path>` that does nothing more than set those key environment variables

If venv is run in a child process of the shell, how does it set those variables in the parent shell? I thought that wasn't possible (on POSIX, anyway), which is why e.g. pew spawns a subshell.

> Sure, but then that doesn't mean activation isn't convenient

Indeed it is. But many less experienced users think that it's always a necessary step, when it isn't always so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Fri Nov 29 22:34:11 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Nov 2019 03:34:11 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575084851.65.0.00897827082071.issue38943@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IDLE completes global names, attributes, and file names with various invocation methods.  The main problem users have in editor windows is not running the module to update namespaces.  But the claim here (and in the PR) is that there is a timing problem. 

JN,  please post at least one minimal, specific, sometimes reproducible example, with code and user actions, that misbehaves.  Do you have any idea why a 1 millesecond delay helps?

(3.5 and 3.6 only get security fixes.)

----------
nosy: +taleinat
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Sat Nov 30 01:37:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Nov 2019 06:37:19 +0000
Subject: [issue17068] peephole optimization for constant strings
In-Reply-To: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za>
Message-ID: <1575095839.13.0.62822191942.issue17068@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
priority: normal -> low
versions: +Python 3.9 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17068>
_______________________________________

From report at bugs.python.org  Sat Nov 30 03:30:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Nov 2019 08:30:53 +0000
Subject: [issue37523] zipfile: Raise ValueError for i/o operations on closed
 zipfile.ZipExtFile
In-Reply-To: <1562656011.62.0.508019848995.issue37523@roundup.psfhosted.org>
Message-ID: <1575102653.78.0.0365329870296.issue37523@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 8d62df60d8733d0fa9aee14ef746d0009a7a9726 by Serhiy Storchaka (Daniel Hillier) in branch 'master':
bpo-37523: Raise ValueError for I/O operations on a closed zipfile.ZipExtFile. (GH-14658)
https://github.com/python/cpython/commit/8d62df60d8733d0fa9aee14ef746d0009a7a9726


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37523>
_______________________________________

From report at bugs.python.org  Sat Nov 30 03:32:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Nov 2019 08:32:21 +0000
Subject: [issue37523] zipfile: Raise ValueError for i/o operations on closed
 zipfile.ZipExtFile
In-Reply-To: <1562656011.62.0.508019848995.issue37523@roundup.psfhosted.org>
Message-ID: <1575102741.13.0.688673202505.issue37523@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37523>
_______________________________________

From report at bugs.python.org  Sat Nov 30 06:42:29 2019
From: report at bugs.python.org (JohnnyNajera)
Date: Sat, 30 Nov 2019 11:42:29 +0000
Subject: [issue38944] Idle autocomplete window doesn't close on Escape key
Message-ID: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>


New submission from JohnnyNajera <JohnnyNajera at protonmail.com>:

Tested on all major Ubuntu releases.

----------
assignee: terry.reedy
components: IDLE
messages: 357658
nosy: JohnnyNajera, terry.reedy
priority: normal
severity: normal
status: open
title: Idle autocomplete window doesn't close on Escape key
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Sat Nov 30 07:12:42 2019
From: report at bugs.python.org (JohnnyNajera)
Date: Sat, 30 Nov 2019 12:12:42 +0000
Subject: [issue38944] Idle autocomplete window doesn't close on Escape key
In-Reply-To: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>
Message-ID: <1575115962.96.0.527716465486.issue38944@roundup.psfhosted.org>


Change by JohnnyNajera <JohnnyNajera at protonmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Sat Nov 30 11:37:13 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 30 Nov 2019 16:37:13 +0000
Subject: [issue29598] Write unit tests for pdb module
In-Reply-To: <1487498006.13.0.101061903633.issue29598@psf.upfronthosting.co.za>
Message-ID: <1575131833.35.0.288982631174.issue29598@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

PR 218 is closed and this issue looks like just created for that PR. If that PR is closed and there are nothing to do with this issue, maybe this can also be closed?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29598>
_______________________________________

From report at bugs.python.org  Sat Nov 30 12:06:01 2019
From: report at bugs.python.org (stealthcopter)
Date: Sat, 30 Nov 2019 17:06:01 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
Message-ID: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>


New submission from stealthcopter <admin at stealthcopter.com>:

Filenames passed to the UU encoding methods (uu.py and uu_codec.py) that contain a newline character will overflow data into the UU content section. This can potentially be used to inject replace or corrupt data content in a file during the decode process.

Initially discussed via the PSRT but deemed low risk so suggested I create a PR with the changes and a BPO.

----------
messages: 357660
nosy: stealthcopter
priority: normal
pull_requests: 16900
severity: normal
status: open
title: Remove newline characters from uu encoding methods
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38945>
_______________________________________

From report at bugs.python.org  Sat Nov 30 14:10:41 2019
From: report at bugs.python.org (Ramon)
Date: Sat, 30 Nov 2019 19:10:41 +0000
Subject: [issue38946] IDLE not opening multiple .py files
Message-ID: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>


New submission from Ramon <r.garciaprieto30 at gmail.com>:

I'm running Python 3.8 and Mac Os Catalina 10.15.1 When I click a .py file, it will open the shell + editor, However if I try to open a new .py file from my finder window it won't open. The only way I can open another file is through the shell by clicking file - open. I downloaded a folder with containing .py files from the web and I have no issue opening those files from my finder window. It appear to be only files created in my computer.

----------
assignee: terry.reedy
components: IDLE
messages: 357661
nosy: RM, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE not opening multiple .py files
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Sat Nov 30 16:05:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Nov 2019 21:05:39 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575147939.25.0.177624383877.issue38941@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> And, we should finally decide whether this should really be 
> changed or not. The current behaviour is counter-intuitive,
> but it's been like that forever and lots of code depends on 
> it in one way or another, so ?

You make a good case to just leave it be.

+1 from me to leave as-is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38941>
_______________________________________

From report at bugs.python.org  Sat Nov 30 16:07:09 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Nov 2019 21:07:09 +0000
Subject: [issue38938] Iterable merge performance and inclusion in itertools
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1575148029.29.0.0470466707411.issue38938@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Nov 30 16:09:20 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 30 Nov 2019 21:09:20 +0000
Subject: [issue28833] cross compilation of third-party extension modules
In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za>
Message-ID: <1575148160.17.0.2550666722.issue28833@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +16901
pull_request: https://github.com/python/cpython/pull/17420

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28833>
_______________________________________

From report at bugs.python.org  Sat Nov 30 16:11:29 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 30 Nov 2019 21:11:29 +0000
Subject: [issue28833] cross compilation of third-party extension modules
In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za>
Message-ID: <1575148289.28.0.176920223174.issue28833@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

PR 17420 fixes cross-compilation of third-party extension modules.

The PYTHON_PROJECT_BASE environment variable is the path to the directory where Python has been cross-compiled. It is used by the native python interpreter to find the target sysconfigdata module.

For example the following command builds a wheel file to be transfered and installed with pip on the target platform, provided the native python interpreter and the cross-compiled one both have the wheel package installed:

  $ PYTHON_PROJECT_BASE=/path/to/builddir python setup.py bdist_wheel

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28833>
_______________________________________

From report at bugs.python.org  Sat Nov 30 16:43:10 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 30 Nov 2019 21:43:10 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575150190.44.0.393914494325.issue38673@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Sat Nov 30 16:57:30 2019
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 30 Nov 2019 21:57:30 +0000
Subject: [issue38938] Iterable merge performance and inclusion in itertools
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1575151050.59.0.152036292761.issue38938@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Disregard merge_recipe.py: it would skip over a value that had already been retrieved from the iterator when the loop finished.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Nov 30 17:10:16 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Nov 2019 22:10:16 +0000
Subject: [issue38938] Iterable merge performance and inclusion in itertools
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1575151816.7.0.147937905792.issue38938@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Several thoughts:

* heapq.merge() could have plausibly been in the itertools module instead of the heapq module.  However, since it already has a home, there is no reason to move it or to create duplication with an intermodule dependency.  We certainly don't have a rule that the itertools module must house everything accepts an iterator as an input and returns an iterator in the output.

* The iter_merge() recipe is a bit sprawling and IMHO not a useful teaching aid (a primary goal of the itertools recipe), so it doesn't have much documentation value.  Instead, consider submitting this to the "more-itertools" project which is referenced by the docs.  There it would likely be used directly rather than as a recipe.

* Over the next few days, I'll take a closer look at the binary tree approach versus a heap approach.  I like how it intrinsically avoids the overhead of the 4-tuple while maintaining order, but I want to test how well it does with slow comparison keys (i.e. does the total number of comparisons get worse).  Am not sure whether the tree needs to be rebalanced as some of the input streams become exhausted.  I have a vague recollection that Knuth's TAOCP deemed the heap approach to be algorithmically superior, but need to dig out my books to be verify that.

* We could just build-out the current heapq.merge() code to include a special case for only two input iterables.  That would speed-up a common case by avoiding the overhead of tracking a 4-tuple for each element.  If you want to submit a PR for that, I would be happy to take a close look and verify the timings.

* It might be interesting to time the pure python variants against "sorted(chain(a, b, c, d, e))".  It isn't quite an apples-to-apples comparison because the latter pulls all the data in memory and it doesn't the runs pre-segregated, but it might give a sense of how well merge() could do if we decided to go gonzo on optimizations.  Until now, we've been satisfied with letting the heap structure minimize the number of comparisons and there hasn't been a focus on reducing the constant factor overhead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Nov 30 17:10:36 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Nov 2019 22:10:36 +0000
Subject: [issue38938] Possible performance improvement for heaqq.merge()
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1575151836.59.0.286486798745.issue38938@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Iterable merge performance and inclusion in itertools -> Possible performance improvement for heaqq.merge()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Nov 30 17:13:46 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Nov 2019 22:13:46 +0000
Subject: [issue38938] Possible performance improvement for heaqq.merge()
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1575152026.91.0.118978136983.issue38938@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Nov 30 17:19:30 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Nov 2019 22:19:30 +0000
Subject: [issue17068] peephole optimization for constant strings
In-Reply-To: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za>
Message-ID: <1575152370.75.0.764292769514.issue17068@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Am thinking this should be closed.  It isn't clear that it can be done easily or that there would be a measurable impact.  Also, the advent of f-strings means that code like this will occur much less often -- both code examples presented would likely no longer be coded as they once were.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17068>
_______________________________________

From report at bugs.python.org  Sat Nov 30 17:23:55 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 30 Nov 2019 22:23:55 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>
Message-ID: <1575152635.73.0.650055175998.issue38946@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report.  If I understand correctly, the issue you are seeing is that, when IDLE is already launched and you double-click on a .py file in the Finder, that .py file does not open in IDLE, even though it will open in IDLE if IDLE is not already launched.  This does seem to be a change in behavior between macOS 10.14 Mojave and 10.15 Catalina. Further investigation is needed.

Of course, launching files in the right application is always somewhat dicey in macOS when there is more than one application claiming an association with a particular file type, like for .py files, so it is always safest to open files from with the app itself, for example, with IDLE's File -> Open menu option.

----------
assignee: terry.reedy -> ned.deily
nosy: +ned.deily
title: IDLE not opening multiple .py files -> IDLE on macOS 10.15 Catalina does not open double-clicked files if app already launched

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Sat Nov 30 18:52:56 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Nov 2019 23:52:56 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>
Message-ID: <1575157976.43.0.83484186821.issue38946@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With Mohave, double click on a file name in Finder Documents opens the file in an editor and then opens the shell.  Double click on another file opens the file in another editor (but not a duplicate shell).  These are .py files I saved from IDLE.

Ramon originally posted this on Stackoverflow, where it is slightly off topic.  I suggested posting it here to at least have it documented and see what Ned says and for the off chance that there is something we can do.

I wonder how a downloaded file could be different from a saved file.  Are file permissions as revealed by 'ls -l' in the directory in Terminal the same?

----------
components: +macOS
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Sat Nov 30 18:53:27 2019
From: report at bugs.python.org (Kevin Shweh)
Date: Sat, 30 Nov 2019 23:53:27 +0000
Subject: [issue38947] dataclass defaults behave inconsistently for
 init=True/init=False when default is a descriptor
Message-ID: <1575158007.0.0.672423182846.issue38947@roundup.psfhosted.org>


New submission from Kevin Shweh <kevin.shweh at gmail.com>:

The following code:

    from dataclasses import dataclass, field
    from typing import Callable
     
    @dataclass
    class Foo:
    	callback: Callable[[int], int] = lambda x: x**2
     
    @dataclass
    class Bar:
    	callback: Callable[[int], int] = field(init=False, default=lambda x: x**2)
     
    print(Foo().callback(2))
    print(Bar().callback(2))

prints 4 for the first print, but throws a TypeError for the second. This is because Foo() stores the default callback in the instance dict, while Bar() only has it in the class dict. Bar().callback triggers the descriptor protocol and produces a method object instead of the original callback.

There does not seem to be any indication in the dataclasses documentation that these fields will behave differently. It seems like they should behave the same, and/or the documentation should be clearer about how the default value/non-init field interaction behaves.

----------
components: Library (Lib)
messages: 357669
nosy: Kevin Shweh
priority: normal
severity: normal
status: open
title: dataclass defaults behave inconsistently for init=True/init=False when default is a descriptor
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38947>
_______________________________________

From report at bugs.python.org  Sat Nov 30 19:03:06 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Dec 2019 00:03:06 +0000
Subject: [issue17068] peephole optimization for constant string interpolation
In-Reply-To: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za>
Message-ID: <1575158586.16.0.0987056625918.issue17068@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Counting Serhiy's de-priorizing, all five core devs find this a bit dubious, so yes, let's close.

----------
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed
title: peephole optimization for constant strings -> peephole optimization for constant string interpolation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17068>
_______________________________________

From report at bugs.python.org  Sat Nov 30 22:05:25 2019
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 01 Dec 2019 03:05:25 +0000
Subject: [issue38938] Possible performance improvement for heaqq.merge()
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1575169525.1.0.478672333428.issue38938@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Nov 30 22:40:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 01 Dec 2019 03:40:07 +0000
Subject: [issue38947] dataclass defaults behave inconsistently for
 init=True/init=False when default is a descriptor
In-Reply-To: <1575158007.0.0.672423182846.issue38947@roundup.psfhosted.org>
Message-ID: <1575171607.76.0.655669602234.issue38947@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38947>
_______________________________________

From report at bugs.python.org  Sat Nov 30 22:59:27 2019
From: report at bugs.python.org (bbayles)
Date: Sun, 01 Dec 2019 03:59:27 +0000
Subject: [issue38938] Possible performance improvement for heaqq.merge()
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1575172767.3.0.448374334677.issue38938@roundup.psfhosted.org>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Nov 30 23:01:35 2019
From: report at bugs.python.org (bbayles)
Date: Sun, 01 Dec 2019 04:01:35 +0000
Subject: [issue38200] Adding itertools.pairwise to the standard library?
In-Reply-To: <1568736008.51.0.85414927582.issue38200@roundup.psfhosted.org>
Message-ID: <1575172895.67.0.335324536712.issue38200@roundup.psfhosted.org>


Change by bbayles <bbayles at gmail.com>:


----------
nosy: +bbayles

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38200>
_______________________________________

From report at bugs.python.org  Sat Nov 30 23:23:09 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 01 Dec 2019 04:23:09 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1575174189.52.0.427280357232.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Regarding "is_running()", notice that it relies almost entirely on "frame->f_executing".  That might not be enough (or maybe the behavior there changed).  That would be worth checking out.

Based on the above hint, I was able to make some progress on a potential solution. Thanks Eric.

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

The above fix seems to completely remove the test failure that occurs in "interpreters.destroy(interp)" in "test_already_running" after running it several times, but I'm able to consistently reproduce the following:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "/home/aeros/repos/aeros-cpython/Lib/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/home/aeros/repos/aeros-cpython/Lib/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/home/aeros/repos/aeros-cpython/Lib/test/test__xxsubinterpreters.py", line 51, in run
    interpreters.run_string(interp, dedent(f"""
RuntimeError: unrecognized interpreter ID 46
test test__xxsubinterpreters failed -- Traceback (most recent call last):
  File "/home/aeros/repos/aeros-cpython/Lib/test/test__xxsubinterpreters.py", line 492, in test_subinterpreter
    self.assertTrue(interpreters.is_running(interp))
AssertionError: False is not true

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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Sat Nov 30 23:26:21 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 01 Dec 2019 04:26:21 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1575174381.23.0.359938333269.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> so that operations (such as running scripts, destroying the interpreter, etc) can't occur during finalization

Clarification: by "destroying the interpreter" I am specifically referring to calling `interp_destroy()` after finalization has already started.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________