[issue1294959] Problems with /usr/lib64 builds.

Change by Carlos Velasco : -- nosy: +carlos.velasco ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in PyGC_Head structure

Inada Naoki added the comment: https://github.com/python/cpython/blob/95905ce0f41fd42eb1ef60ddb83f057401c3d52f/Include/cpython/objimpl.h#L89 _Py_AS_GC and all APIs to get PyGC_Head from PyObject* are not only unstable, but also private. I thought PyGC_Head must not be used directly from

[issue39474] col_offset for parenthesized expressions looks weird

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in PyGC_Head structure

Mark Dickinson added the comment: [Julien Danjou] > As you said, if it's not part of the stable ABI it makes sense. I think this is a misunderstanding of what the stable ABI is for. I'm not sure whether this is spelled out explicitly anywhere, but my understanding was that ABI breakage

[issue39603] [security] http.client: HTTP Header Injection in the HTTP method

Amir Mohamadi added the comment: @vstinner sorry to bother you, I have a quick question. the request(...) method is like this: def request(self, method, url, body=None, headers={}, *, encode_chunked=False): """Send a complete request

python3 embedded in LibreOffice documents

Both Open- and LibreOffice use APSO.oxt to support py3 in Office .odt documents, such as HTML files et cetera. So one can make a web page with python and BASIC code essentially and save it as a document, possibly throw in some EMOTET as well. after import NNTPlib one can make a lil

[issue1812] doctest _load_testfile function -- newline handling seems incorrect

Change by Zachary Ware : -- nosy: +zach.ware ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Trac 1.4.1 Released

Trac 1.4.1 Released Trac 1.4.1, the latest maintenance release for the current stable branch, is available. You will find this release at the usual places: https://trac.edgewall.org/wiki/TracDownload#Trac14StableRelease You can find the detailed release notes for 1.4.1 on

[issue39605] Fix some casts to not cast away const

miss-islington added the comment: New changeset 0b8f738eb3ee0110461e7da28c0b6b452f91999d by Miss Islington (bot) in branch '3.8': bpo-39605: Remove a cast that causes a warning. (GH-18473) https://github.com/python/cpython/commit/0b8f738eb3ee0110461e7da28c0b6b452f91999d --

[issue39605] Fix some casts to not cast away const

Change by miss-islington : -- pull_requests: +17842 pull_request: https://github.com/python/cpython/pull/18474 ___ Python tracker ___

[issue39605] Fix some casts to not cast away const

Benjamin Peterson added the comment: New changeset 95905ce0f41fd42eb1ef60ddb83f057401c3d52f by Benjamin Peterson in branch 'master': bpo-39605: Remove a cast that causes a warning. (GH-18473) https://github.com/python/cpython/commit/95905ce0f41fd42eb1ef60ddb83f057401c3d52f --

[issue39595] Improve performance of importlib.metadata and zipfile.Path

Change by Jason R. Coombs : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39595] Improve performance of importlib.metadata and zipfile.Path

Jason R. Coombs added the comment: New changeset ed4d263e8767b0e4c47df99141b500d36ce0275d by Miss Islington (bot) in branch '3.8': bpo-39595: Improve zipfile.Path performance (GH-18406) (GH-18472) https://github.com/python/cpython/commit/ed4d263e8767b0e4c47df99141b500d36ce0275d --

[issue39605] Fix some casts to not cast away const

Change by Benjamin Peterson : -- pull_requests: +17841 pull_request: https://github.com/python/cpython/pull/18473 ___ Python tracker ___

[issue39595] Improve performance of importlib.metadata and zipfile.Path

Change by miss-islington : -- pull_requests: +17840 pull_request: https://github.com/python/cpython/pull/18472 ___ Python tracker ___

[issue39595] Improve performance of importlib.metadata and zipfile.Path

Jason R. Coombs added the comment: New changeset e5bd73632e77dc5ab0cab77e48e94ca5e354be8a by Jason R. Coombs in branch 'master': bpo-39595: Improve zipfile.Path performance (#18406) https://github.com/python/cpython/commit/e5bd73632e77dc5ab0cab77e48e94ca5e354be8a --

[issue39605] Fix some casts to not cast away const

miss-islington added the comment: New changeset 190433d8150bf719fa0ba972dbacf2214942f54e by Miss Islington (bot) in branch '3.8': closes bpo-39605: Fix some casts to not cast away const. (GH-18453) https://github.com/python/cpython/commit/190433d8150bf719fa0ba972dbacf2214942f54e --

[issue39605] Fix some casts to not cast away const

Change by miss-islington : -- pull_requests: +17839 pull_request: https://github.com/python/cpython/pull/18471 ___ Python tracker ___

[issue39605] Fix some casts to not cast away const

Benjamin Peterson added the comment: New changeset e6be9b59a911626d6597fe148c32f0342bd2bd24 by Andy Lester in branch 'master': closes bpo-39605: Fix some casts to not cast away const. (GH-18453) https://github.com/python/cpython/commit/e6be9b59a911626d6597fe148c32f0342bd2bd24 --

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 12:32 PM Michael Torrie wrote: > > On 2/11/20 6:15 PM, Chris Angelico wrote: > > On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote: > >> > >> On 2/11/20 5:55 PM, Chris Angelico wrote: > >>> But you CAN rewrite code such that it reduces technical debt. You can > >>>

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/20 6:15 PM, Chris Angelico wrote: > On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote: >> >> On 2/11/20 5:55 PM, Chris Angelico wrote: >>> But you CAN rewrite code such that it reduces technical debt. You can >>> refactor code to make it more logical. You can update things to use >>>

[issue15976] Inconsistent behavior of search_for_exec_prefix() results in startup failure in certain cases

STINNER Victor added the comment: This issue was reported on Python 2.7 eight years ago. getpath.c has been deeply reworked, especially by the PEP 587 (PyConfig) implementation. I consider that the issue is now fixed. If it's not the case, feel free to reopen it. -- nosy: +vstinner

[issue38180] Test pyexpat fails on Fedora 30

STINNER Victor added the comment: I'm unable to reproduce the issue on Fedora 31. We now have multiple Fedora buildbots (Stable and Rawhide flavors): test_pyexpat pass on all of them. Maybe you didn't use "./configure --with-system-expat". Reopen the issue if you can still reproduce it.

[issue19482] _pickle build warnings on Fedora 19

STINNER Victor added the comment: I don't get these warnings on Fedora anymore. I close the issue. -- nosy: +vstinner resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue32897] test_gdb failed on Fedora 27

STINNER Victor added the comment: test_gdb got multiple bugfixes since 2018. Please test Python 3.8.1 on Fedora 31. Your issue should be fixed. -- nosy: +vstinner resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: See also bpo-21016: "trace: $prefix and $exec_prefix improperly replaced on Fedora". -- ___ Python tracker ___

[issue18092] Python 2.7.5 installation broken on OpenSuse 12.2

Change by STINNER Victor : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Problems with /usr/lib64 builds. ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: I marked bpo-18092 ("Python 2.7.5 installation broken on OpenSuse 12.2") as a duplicate of this issue. -- ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: See also bpo-14791: "setup.py only adds /prefix/lib, not /prefix/lib64". -- ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: I marked bpo-34032 as a duplicate of this issue. It has an open PR written by Matěj Cepl (OpenSUSE): PR 8068. It looks similar to PR 3698. -- ___ Python tracker

[issue16529] Compiler error when trying to compile ceval.c on OpenSUSE 11.3

STINNER Victor added the comment: That's a GCC bug which has likely been fixed since 2014. -- nosy: +vstinner resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker

[issue34032] Add platlibdir to allow distinction between /usr/lib and /usr/lib64 for Linux

STINNER Victor added the comment: I mark this issue as a duplicate of bpo-1294959. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> Problems with /usr/lib64 builds. ___ Python tracker

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/20 5:53 PM, Python wrote: > If your hypothetical project was implemented perfectly from the > beginning, in Python2.x, it may never need updating, and therefore > there may well never be any reason to port it to python3. So doing so > would be neither "debt" nor "cost" but rather "waste."

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: See also bpo-34058 "Default Python 3.7 install broken on openSUSE Leap 42.3: $PYTHONHOME/lib64/python3.7/lib-dynload/ not linked to $PYTHONHOME/lib/python3.7/lib-dynload/": OpenSUSE and Centos are mentioned as being impacted. --

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote: > > On 2/11/20 5:55 PM, Chris Angelico wrote: > > But you CAN rewrite code such that it reduces technical debt. You can > > refactor code to make it more logical. You can update things to use > > idioms that better express the concepts you're

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/20 5:55 PM, Chris Angelico wrote: > But you CAN rewrite code such that it reduces technical debt. You can > refactor code to make it more logical. You can update things to use > idioms that better express the concepts you're trying to represent > (maybe because those idioms require

[issue39011] ElementTree attributes replace "\r" with "\n"

Change by Roundup Robot : -- pull_requests: +17838 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/18468 ___ Python tracker ___

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: I marked bpo-15631 as a duplicate of this issue. -- ___ Python tracker ___ ___

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 12:00 PM Michael Torrie wrote: > > On 2/11/20 5:42 PM, Chris Angelico wrote: > > Yes, if you consider the term to be synonymous with TCO, then > > naturally you'll see it as useless. But it isn't. Technical debt is a > > very specific thing and it CAN be paid off. > >

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/2020 3:09 PM, Chris Angelico wrote: What you're talking about is costs in general, but "debt" is a very specific term. You accrue technical debt whenever you "borrow" time from the future - doing something that's less effort now at the expense of being worse in the future. A prime

[issue39474] col_offset for parenthesized expressions looks weird

Lysandros Nikolaou added the comment: Are you going to work on a patch then, Batuhan? -- ___ Python tracker ___ ___

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 11:48 AM Michael Torrie wrote: > > On 2/11/20 5:37 PM, Chris Angelico wrote: > > On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote: > >> > >> On 2/11/20 2:25 PM, Barry Scott wrote: > >>> At Chris said moving to python3 will *reduce* your technical debt. > >>> You are

[issue15631] Python 3.3/3.4 installation issue on OpenSUSE lib/lib64 folders

STINNER Victor added the comment: I mark this issue as a duplicate of bpo-1294959. -- nosy: +vstinner resolution: out of date -> duplicate superseder: -> Problems with /usr/lib64 builds. ___ Python tracker

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/20 5:42 PM, Chris Angelico wrote: > Yes, if you consider the term to be synonymous with TCO, then > naturally you'll see it as useless. But it isn't. Technical debt is a > very specific thing and it CAN be paid off. We'll agree to disagree on the last bit. And I'm not the only one that

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 07:09:12AM +1100, Chris Angelico wrote: > On Wed, Feb 12, 2020 at 7:03 AM Michael Torrie wrote: > > Speaking about technical debt is certainly fashionable these days. As > > if we've somehow discovered a brand new way of looking at things. But > > it doesn't matter what

[issue1294959] Problems with /usr/lib64 builds.

STINNER Victor added the comment: I closed bpo-858809 as a duplicate of this issue. -- ___ Python tracker ___ ___

[issue858809] Use directories from configure rather than hardcoded

STINNER Victor added the comment: Start of this issue: "Current Makefile.pre.in contains paths like $(exec_prefix)/lib, which bad especially for mixed 32-bit and 64-bit systems, where 64-bit things should go to /lib64." That's a duplicate of bpo-1294959. This issue discuss also modifying

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/20 5:37 PM, Chris Angelico wrote: > On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote: >> >> On 2/11/20 2:25 PM, Barry Scott wrote: >>> At Chris said moving to python3 will *reduce* your technical debt. >>> You are paying off the debt. >> >> While at the same time incurring new debt.

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 11:39 AM Michael Torrie wrote: > > On 2/11/20 1:09 PM, Chris Angelico wrote: > > What you're talking about is costs in general, but "debt" is a very > > specific term. You accrue technical debt whenever you "borrow" time > > from the future - doing something that's less

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/20 1:09 PM, Chris Angelico wrote: > What you're talking about is costs in general, but "debt" is a very > specific term. You accrue technical debt whenever you "borrow" time > from the future - doing something that's less effort now at the > expense of being worse in the future. You pay

[issue39474] col_offset for parenthesized expressions looks weird

Guido van Rossum added the comment: This is also a 3.8 issue. We discovered this with pegen, and would love to see it fixed. -- nosy: +gvanrossum versions: +Python 3.8 ___ Python tracker

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote: > > On 2/11/20 2:25 PM, Barry Scott wrote: > > At Chris said moving to python3 will *reduce* your technical debt. > > You are paying off the debt. > > While at the same time incurring new debt. That's not an intrinsic part of the rewrite,

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/20 2:25 PM, Barry Scott wrote: > At Chris said moving to python3 will *reduce* your technical debt. > You are paying off the debt. While at the same time incurring new debt. > Not to mention that its harder to hire people to work on tech-debt legacy > code. > > Given the choice between

[issue39474] col_offset for parenthesized expressions looks weird

Change by Lysandros Nikolaou : -- nosy: +lys.nikolaou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39483] Proposial add loop parametr to run in asyncio

Yury Selivanov added the comment: Андрей, Here's how you can fix your example: import asyncio class Singleton: _LOCK = None _LOOP = None @classmethod async def create(cls): if cls._LOOP is None: cls._LOOP = asyncio.get_running_loop()

[issue39610] memoryview.__len__ should raise an exception for 0d buffers

Stefan Krah added the comment: The change looks reasonable, but unfortunately this is a long-standing behavior that originates from before the Python-3.3 memoryview rewrite. It is also present in 2.7 (the previous implementation) and documented in 3.3:

[issue37088] Add a way to schedule a function to be called from the main thread

Yury Selivanov added the comment: > I'm not strongly against the feature. I first proposed to expose it, but make > it private. Almost one year later, the PR was not updated. So I just closed > the PR and the issue. All clear, Victor. Let's keep this closed. The reason I didn't reply is

[issue37088] Add a way to schedule a function to be called from the main thread

STINNER Victor added the comment: > NP, here, but, hm, can you unilaterally reject features now? :) Eric Snow and me are basically against the idea of exposing the "pending calls" mechanism in Python, since it's fragile and dangerous. Andrew Sveltov wrote "@vstinner had objections, perhaps

[issue39614] Documentation of attribute reference is unclear

New submission from Dirk Herrmann : Trying to understand attribute reference in Python, I was lost: * In the "Python Language Reference" (I will refer to this as PLR, sorry if that is uncommon, did not find an abbreviation in the glossary): Chapter 6.3.1 is about attribute reference. How

[issue37088] Add a way to schedule a function to be called from the main thread

Yury Selivanov added the comment: > There is not clear rationale to justify the addition of the function Yeah, with the new threaded watcher being the default we don't need this anymore. > so I reject the feature NP, here, but, hm, can you unilaterally reject features now? :) --

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

> On 11 Feb 2020, at 20:01, Michael Torrie wrote: > > On 2/11/20 4:05 AM, Chris Angelico wrote: >> Or just the recognition that, eventually, technical debt has to be >> paid. > > Speaking about technical debt is certainly fashionable these days. As > if we've somehow discovered a brand new

[issue39601] brace escapes are not working in formatted string literal format specifications

JitterMan added the comment: Okay, I get it. Someone might be using two braces in the format specifier because they found that it is a way to both evaluate a sub-expression and get braces in the formatted result. I was thinking that they would just use three braces, but that does not appear

[issue39612] Python UnicodeDecodeError while using modulefinder

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39601] brace escapes are not working in formatted string literal format specifications

Change by Eric V. Smith : -- assignee: -> eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39601] brace escapes are not working in formatted string literal format specifications

Eric V. Smith added the comment: But you can't just change it without breaking the code of anyone who's relying on the current behavior. If we could say "no one relies on that", that's would let us move forward with such a breaking change. But I don't think we can make that determination.

[issue39521] reversed(mylist) much slower on Python 3.8 32-bit for Windows

STINNER Victor added the comment: > Just FYI, there is no PGO run on the official 32-bit builds. I only run it on > the 64-bit build. Aaaah :-) That's good to know ;-) It can explain the performance difference. -- ___ Python tracker

[issue39601] brace escapes are not working in formatted string literal format specifications

JitterMan added the comment: I believe it is worth fixing as it clears up some rather glaring inconsistencies␣ and enables a useful capability. Specifically, 1. Formatted string literals and the string format method are currently inconsistent in the way that they handle double braces in

Re: datetime seems to be broken WRT timezones (even when you add them)

> On 10 Feb 2020, at 23:01, Python wrote: > > As best I can tell, Python has no means to make use of the system's > timezone info. In order to make datetime "timezone aware", you need > to manually create a subclass of datetime.tzinfo, whose methods return > the correct values for the

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 7:03 AM Michael Torrie wrote: > > On 2/11/20 4:05 AM, Chris Angelico wrote: > > Or just the recognition that, eventually, technical debt has to be > > paid. > > Speaking about technical debt is certainly fashionable these days. As > if we've somehow discovered a brand new

Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 6:45 AM Python wrote: > > On Wed, Feb 12, 2020 at 05:38:38AM +1100, Chris Angelico wrote: > > > > Isn't it time to stop going to great effort to support Python > > > > > > If you live in a world where you get to decide that, sure. Not > > > everyone does. > > > > > > >

Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

On 2/11/20 4:05 AM, Chris Angelico wrote: > Or just the recognition that, eventually, technical debt has to be > paid. Speaking about technical debt is certainly fashionable these days. As if we've somehow discovered a brand new way of looking at things. But it doesn't matter what you do,

[issue39613] IsolatedAsyncioTestCase closes default event loop

New submission from Artur Rodrigues : This means that subsequent test cases executed within the same application that don't create the event loop will fail. This seems like a behaviour change that wasn't raised on the original PR. $ cat test.py from unittest import IsolatedAsyncioTestCase,

Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 05:38:38AM +1100, Chris Angelico wrote: > > > Isn't it time to stop going to great effort to support Python > > > > If you live in a world where you get to decide that, sure. Not > > everyone does. > > > > Everyone gets to decide how much time and effort they put into >

[issue38324] [Windows] test_locale and test__locale failures on Windows

Eryk Sun added the comment: It is not a duplicate of bpo-37945. The tests in test/test__locale.py need to be fixed to work with Windows. In msg354021, I discussed the problem reported with test_lc_numeric_localeconv. The "ps_AF" (Pashto, Afghanistan) item in known_numerics has to be

[issue39612] Python UnicodeDecodeError while using modulefinder

New submission from ArtOfCode Studio : I want to find all imported modules in a python program. I am using the ``modulefinder`` standard module for my job. I am trying to follow [this example](https://docs.python.org/3.8/library/modulefinder.html#example-usage-of-modulefinder) on docs, but I

Re: datetime seems to be broken WRT timezones (even when you add them)

On Wed, Feb 12, 2020 at 3:57 AM Python wrote: > > On Tue, Feb 11, 2020 at 12:42:26PM +1100, Chris Angelico wrote: > > > > I've been using the timestamp() method: > > > > > > That's the key piece of info. This does appear to work, though still > > > not on python2. That, as you say, is my

[issue39603] [security] http.client: HTTP Header Injection in the HTTP method

Amir Mohamadi added the comment: can I work on it?! -- nosy: +Amir ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue39521] reversed(mylist) much slower on Python 3.8 32-bit for Windows

Steve Dower added the comment: Just FYI, there is no PGO run on the official 32-bit builds. I only run it on the 64-bit build. It might be worth investigating differences between the 3.7 and 3.8 implementations of reversed(). -- ___ Python

[issue39601] brace escapes are not working in formatted string literal format specifications

Chris Wilcox added the comment: Thanks Eric. That is very handy. I had made a test case earlier on a branch. Attached as a patch here if helpful. I haven't tried to fix this yet, but would be interested if it is something that makes sense to address. -- keywords: +patch Added file:

Re: Documentation of __hash__

On 02/11/2020 02:23 AM, klau...@gmail.com wrote: On Friday, February 7, 2020 at 4:30:23 PM UTC+1, Random832 wrote: The purpose of this rule is to save you from having to override the default __hash__ with something that will only raise an exception when you do not intend your class to be

Re: datetime seems to be broken WRT timezones (even when you add them)

On Tue, Feb 11, 2020 at 12:42:26PM +1100, Chris Angelico wrote: > > > I've been using the timestamp() method: > > > > That's the key piece of info. This does appear to work, though still > > not on python2. That, as you say, is my problem. But thankfully Jon > > Ribbens has the save: > > Isn't

[issue39611] PyVectorcall_NARGS(): change return type to Py_ssize_t

New submission from STINNER Victor : I propose to change PyVectorcall_NARGS() return type from unsigned size_t to signed Py_ssize_t. Currently, the function is defined as: static inline Py_ssize_t PyVectorcall_NARGS(size_t n) { return n & ~PY_VECTORCALL_ARGUMENTS_OFFSET; } But in

[issue38644] Pass explicitly tstate to function calls

Petr Viktorin added the comment: New changeset f3fda374685dffa31ebda9e681e00ef7032b8a1d by Victor Stinner in branch 'master': bpo-38644: Rephrase What's New entry (GH-18461) https://github.com/python/cpython/commit/f3fda374685dffa31ebda9e681e00ef7032b8a1d -- nosy: +petr.viktorin

[issue39245] Public API for Vectorcall (PEP 590)

Petr Viktorin added the comment: New changeset ffd9753a944916ced659b2c77aebe66a6c9fbab5 by Petr Viktorin in branch 'master': bpo-39245: Switch to public API for Vectorcall (GH-18460) https://github.com/python/cpython/commit/ffd9753a944916ced659b2c77aebe66a6c9fbab5 --

[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()

Change by Petr Viktorin : -- pull_requests: +17837 pull_request: https://github.com/python/cpython/pull/18464 ___ Python tracker ___

[issue39417] Link to "Python Packaging User Guide: Creating and using virtual environments" is broken

Angel Cervera Claudio added the comment: Thanks for handling this. I'm sorry I didn't have a chance to create the pr. :( On Mon 10 Feb 2020, 23:51 Carol Willing, wrote: > > Carol Willing added the comment: > > > New changeset c4a65ed7fe342bd18b5a5b0eea3470dc4fc31160 by Ogi Moore in >

[issue39610] memoryview.__len__ should raise an exception for 0d buffers

Change by Eric Wieser : -- keywords: +patch pull_requests: +17836 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18463 ___ Python tracker ___

[issue39610] memoryview.__len__ should raise an exception for 0d buffers

New submission from Eric Wieser : Right now, the behavior is: >>> import numpy as np >>> arr_0d = np.array(42) >>> mem_0d = memoryview(arr_0d) >>> len(mem_0d) 1 >>> mem_0d[0] TypeError: invalid indexing of 0-dim memory It seems bizarre to have this object pretend to be a sequence when you ask

[issue39299] Improve test coverage for mimetypes module

Change by Karthikeyan Singaravelan : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39299] Improve test coverage for mimetypes module

miss-islington added the comment: New changeset d3f9fb2d28ceedb0a17a703338424ff284a578c8 by Miss Islington (bot) in branch '3.8': bpo-39299: Add more tests for mimetypes and its cli. (GH-17949) https://github.com/python/cpython/commit/d3f9fb2d28ceedb0a17a703338424ff284a578c8 --

[issue38243] [security][CVE-2019-16935] A reflected XSS in python/Lib/DocXMLRPCServer.py

STINNER Victor added the comment: CVE-2019-16935 has been assigned to this vulnerability. -- title: A reflected XSS in python/Lib/DocXMLRPCServer.py -> [security][CVE-2019-16935] A reflected XSS in python/Lib/DocXMLRPCServer.py ___ Python tracker

[issue39603] [security] http.client: HTTP Header Injection in the HTTP method

Max added the comment: I agree that the solution is quite restrictive. Restricting to ASCII characters alone would certainly work. -- ___ Python tracker ___

[RELEASE] Python 3.8.2rc1 is now available for testing

Python 3.8.2rc1 is the release candidate of the second maintenance release of Python 3.8. Go get it here: https://www.python.org/downloads/release/python-382rc1/ Assuming no critical problems are found prior to 2020-02-17, the scheduled

[issue39574] str.__doc__ is misleading

Steven D'Aprano added the comment: Sorry everyone, due to technology problems I am unable to comment on the github page, and due to ISP problems I've been off the internet for a few days. > pull_request: https://github.com/python/cpython/pull/18401 [Serhiy] > Is not "or both" redundant? I

[issue39500] Document PyUnicode_IsIdentifier() function

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39500] Document PyUnicode_IsIdentifier() function

STINNER Victor added the comment: New changeset f3e7ea5b8c220cd63101e419d529c8563f9c6115 by Victor Stinner in branch 'master': bpo-39500: Document PyUnicode_IsIdentifier() function (GH-18397) https://github.com/python/cpython/commit/f3e7ea5b8c220cd63101e419d529c8563f9c6115 --

[issue27657] urlparse fails if the path is numeric

Senthil Kumaran added the comment: Hi Lukaz / Ned: I will like to revert the backports done in 3.8 and 3.7. Preferably in 3.8.2 and 3.7.7, so that this undesirable behavior exists only for a single release. I have set this is a release blocker to catch your attention. -- nosy:

[issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in PyGC_Head structure

STINNER Victor added the comment: > The sad part if that my code does not access PyGC_Head at all. It's just a > side effect when loading the code that makes it crash. :( Python stores pointers to PyObject*. If your code doesn't access PyGC_Head directly, maybe it does acess it indirectly?

[issue38644] Pass explicitly tstate to function calls

Change by STINNER Victor : -- pull_requests: +17835 pull_request: https://github.com/python/cpython/pull/18461 ___ Python tracker ___

[issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in PyGC_Head structure

Julien Danjou added the comment: > If you want to ship wheel package, another compromise would be to require > Python 3.7.5 or newer, and check early the Python version. Yes, this is what I do now to avoid getting a segmentation fault. I'm fine with closing this as wontfix or reject, your

  1   2   >