Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

On 2021-06-15 17:18, Dieter Maurer wrote: Chris Angelico wrote at 2021-6-15 19:08 +1000: On Tue, Jun 15, 2021 at 6:32 PM Dieter Maurer wrote: Chris Angelico wrote at 2021-6-15 05:35 +1000: >On Tue, Jun 15, 2021 at 5:12 AM Jach Feng wrote: >> >> >>> n = [(1,2) for i in range(3)] >> >>> n >>

Re: Where did the message go?

On Wed, Jun 16, 2021 at 2:41 AM Grimble wrote: > Thanks for reminding me of the log files. I've worked out that the > message on machine H (for haydn, which shows my preferred music genre) > was bouncing because haydn.. was not a registered subdomain with > my ISP, whereas bach..

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

here are some (partially documented) implementation details > for CPython (which is just one possible implementation). Yes there are - plenty of them :) The example I gave is a language guarantee. Object identity is maintained in various places, and MUST be; in fact, I've heard tell that PyPy actually has to do some shenanigans to ensure that identities can be tracked across certain types of optimizations (where the object mightn't actually exist temporarily). ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Where did the message go?

"sysname" as sysn...@sysname.. i.e a valid addr4ess. Where do I look now, please? That's machine B, but the issue is with machine H. Have you compared the contents of the two machines' /var/log/maillog? Thanks for reminding me of the log files. I've worked out that the message on

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

Greg Ewing 在 2021年6月15日 星期二下午3:01:46 [UTC+8] 的信中寫道： > On 15/06/21 3:18 pm, Jach Feng wrote: > > From a user's point, I don't really care how Python creates thoseinstances, > > > either using an already exist one or create a new one, as > > long as each element (and its sub-element) are

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

Chris Angelico 在 2021年6月15日 星期二上午5:23:12 [UTC+8] 的信中寫道： > On Tue, Jun 15, 2021 at 7:11 AM Rob Cliffe via Python-list > wrote: > > > > This puzzled me, so I played around with it a bit (Python 3.8.3): > > > > n = [] > > for i in range(3): > > n.append((1,7,-3,None,"x")) > > for i in

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

Chris Angelico wrote at 2021-6-15 19:08 +1000: >On Tue, Jun 15, 2021 at 6:32 PM Dieter Maurer wrote: >> >> Chris Angelico wrote at 2021-6-15 05:35 +1000: >> >On Tue, Jun 15, 2021 at 5:12 AM Jach Feng wrote: >> >> >> >> >>> n = [(1,2) for i in range(3)] >> >> >>> n >> >> [(1, 2), (1, 2), (1, 2)]

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

On 15/06/21 3:18 pm, Jach Feng wrote: From a user's point, I don't really care how Python creates thoseinstances, > either using an already exist one or create a new one, as long as each element (and its sub-element) are independent from each other so a modification of one will not influence

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

On Tue, Jun 15, 2021 at 6:32 PM Dieter Maurer wrote: > > Chris Angelico wrote at 2021-6-15 05:35 +1000: > >On Tue, Jun 15, 2021 at 5:12 AM Jach Feng wrote: > >> > >> >>> n = [(1,2) for i in range(3)] > >> >>> n > >> [(1, 2), (1, 2), (1, 2)] > >> >>> id(n[0]) == id(n[1]) == id(n[2]) > >> True >

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

Chris Angelico wrote at 2021-6-15 05:35 +1000: >On Tue, Jun 15, 2021 at 5:12 AM Jach Feng wrote: >> >> >>> n = [(1,2) for i in range(3)] >> >>> n >> [(1, 2), (1, 2), (1, 2)] >> >>> id(n[0]) == id(n[1]) == id(n[2]) >> True > >This is three tuples. Tuples are immutable and you get three

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

On Tue, Jun 15, 2021 at 7:11 AM Rob Cliffe via Python-list wrote: > > This puzzled me, so I played around with it a bit (Python 3.8.3): > > n = [] > for i in range(3): > n.append((1,7,-3,None,"x")) > for i in range(3): > n.append((1,7,-3,None,"x")) > print([id(x) for x in n]) > > a = 4

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

This puzzled me, so I played around with it a bit (Python 3.8.3): n = [] for i in range(3):     n.append((1,7,-3,None,"x")) for i in range(3):     n.append((1,7,-3,None,"x")) print([id(x) for x in n]) a = 4 n = [] for i in range(3):     n.append((1,7,-3,a,None,"x")) for i in range(3):    

Re: Where did the message go?

t of the system is working (hence this message). > The message from machine B correctly interprets "sysname" as > sysn...@sysname.. i.e a valid addr4ess. > > Where do I look now, please? That's machine B, but the issue is with machine H. Have you compared the content

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

On Tue, Jun 15, 2021 at 5:12 AM Jach Feng wrote: > > >>> n = [(1,2) for i in range(3)] > >>> n > [(1, 2), (1, 2), (1, 2)] > >>> id(n[0]) == id(n[1]) == id(n[2]) > True This is three tuples. Tuples are immutable and you get three references to the same thing. > >>> m = [[1,2] for i in range(3)]

Where did the message go?

: queued as B57B42C042F') send: 'quit\r\n' reply: b'221 2.0.0 Bye\r\n' reply: retcode (221); Msg: b'2.0.0 Bye' The SMTP part of the system is working (hence this message). The message from machine B correctly interprets "sysname" as sysn...@sysname.. i.e a valid addr4ess. Where

Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

>>> n = [(1,2) for i in range(3)] >>> n [(1, 2), (1, 2), (1, 2)] >>> id(n[0]) == id(n[1]) == id(n[2]) True >>> m = [[1,2] for i in range(3)] >>> m [[1, 2], [1, 2], [1, 2]] >>> id(m[0]) == id(m[1]) == id(m[2]) False >>> --Jach -- https://mail.python.org/mailman/listinfo/python-list

[issue36027] Support negative exponents in pow() where a modulus is specified.

Change by miss-islington : -- nosy: +miss-islington nosy_count: 10.0 -> 11.0 pull_requests: +25288 pull_request: https://github.com/python/cpython/pull/26702 ___ Python tracker

[issue36027] Support negative exponents in pow() where a modulus is specified.

Change by Mark Dickinson : -- pull_requests: +25287 pull_request: https://github.com/python/cpython/pull/26703 ___ Python tracker ___

[issue36027] Support negative exponents in pow() where a modulus is specified.

Change by Mark Dickinson : -- pull_requests: +25277 pull_request: https://github.com/python/cpython/pull/26690 ___ Python tracker ___

[issue44270] shutil.which: does not find path/cmd.ext where ext is not given

Eryk Sun added the comment: Michael, thank you for the PR, but please associate it with the existing issue bpo-24505. -- nosy: +eryksun resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> shutil.which wrong result on Windows versions:

[issue44270] shutil.which: does not find path/cmd.ext where ext is not given

Michael Hirsch, Ph.D. added the comment: Correction: Example: on Windows if ./foo.exe exists, then shutil.which('./foo') returns None. -- ___ Python tracker ___

[issue44270] shutil.which: does not find path/cmd.ext where ext is not given

Change by Michael Hirsch, Ph.D. : -- keywords: +patch pull_requests: +25053 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26458 ___ Python tracker

[issue44270] shutil.which: does not find path/cmd.ext where ext is not given

') returns None. -- components: Library (Lib) messages: 394784 nosy: michael2 priority: normal severity: normal status: open title: shutil.which: does not find path/cmd.ext where ext is not given type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

[issue43980] netrc module looks for .netrc even on Windows where the convention is _netrc

Jerry Heiselman added the comment: The netrc file has no formal standard, but the following supports the claim of its conventional naming. Excerpt from https://curl.se/docs/manpage.html#-n: "Makes curl scan the .netrc (_netrc on Windows) file in the user's home directory for login name and

[issue43980] netrc module looks for .netrc even on Windows where the convention is _netrc

Steven D'Aprano added the comment: This is a behaviour change not a simple bug fix. 3.6 through 3.9 are all in feature-freeze, and we're days away from the same for 3.10. Not that I don't believe you about the _netrc convention on Windows, but do you have a link to a reliable source

[issue43980] netrc module looks for .netrc even on Windows where the convention is _netrc

Jerry Heiselman added the comment: Created a simple PR to correct this. -- keywords: +patch message_count: 1.0 -> 2.0 pull_requests: +24423 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25732 ___ Python tracker

[issue43980] netrc module looks for .netrc even on Windows where the convention is _netrc

supported platforms. -- components: Library (Lib) messages: 392348 nosy: jheiselman priority: normal severity: normal status: open title: netrc module looks for .netrc even on Windows where the convention is _netrc type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7

[issue13559] Use sendfile where possible in httplib

Christian Heimes added the comment: sendfile() only works for plain HTTP. For technical reasons it does not work for HTTPS (*). These days majority of services use HTTPS. Therefore the usefulness of sendfile() patch is minimal. (*) It is possible to use sendfile() for TLS connections, but

[issue13559] Use sendfile where possible in httplib

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

Re: Where is the problem?

RD wrote: > In article , cousinstan...@gmail.com says... > > [snip] > >> I have a couple of postscript saving examples >> that include the following geometry parameters >> which produce .ps files that render the same >> as the canvas drawings when viewed in ghostsript. > >>

Re: Where is the problem?

In article , cousinstan...@gmail.com says... [snip] > I have a couple of postscript saving examples > that include the following geometry parameters > which produce .ps files that render the same > as the canvas drawings when viewed in ghostsript. > retval = canvas.postscript( >

Re: Where is the problem?

RD wrote: > Python 3.4.3 on WinXP. > > I create a Tk canvas and draw on it with create_text(), > create_line(), and create_polygon with fill and stipple. > > So far, so good, looks fine on the screen. > > So I go to send it to a postsctript file: > > bmap.postscript(file="tmp.ps",

[issue13559] Use sendfile where possible in httplib

Senthil Kumaran added the comment: Yes, the point number 5. We will have to evaluate if sendfile side-steps and avoids the issues noted in issue23740 -- ___ Python tracker

[issue13559] Use sendfile where possible in httplib

Alex Willmer added the comment: To check my understanding Is the motivation for the closer to 1. using sendfile() will break $X, and we know X 2. there's high probability sendfile() will break something 3. there's unknown probability sendfile() will break something 4. there's low probability

[issue13559] Use sendfile where possible in httplib

Senthil Kumaran added the comment: Alex, https://bugs.python.org/issue23740 is identified as a dependency on this issue. We will have to resolve that first, and come back to this. And yes, if you contribute on other's patch, both the contributions will be included and appropriately

Where is the problem?

Python 3.4.3 on WinXP. I create a Tk canvas and draw on it with create_text(), create_line(), and create_polygon with fill and stipple. So far, so good, looks fine on the screen. So I go to send it to a postsctript file: bmap.postscript(file="tmp.ps", colormode='color') It generates a file,

[issue13559] Use sendfile where possible in httplib

Alex Willmer added the comment: I would like to take a stab at this. Giampaolo, would it be okay if I made a pull request updated from your patch? With the appropriate "Co-authored-by: Author Name " line. -- nosy: +Alex.Willmer ___ Python tracker

GridSearchCV generates unexpected different best parameters by only changing the parameters order in param_grid. Where did I make mistake and how to fix this unexpected results?

by GridSearchCV. Where did I make mistake and how to fix this unexpected results? Below is the code. The Debug class is used to save the output from 'reduce' step. This saved output is used in cv_silhouette_scorer() to calculate silhouette_score. I suspect Debug class and cv_silhouette_scorer

[issue42287] Use Py_NewRef & Py_XNewRef where applicable

STINNER Victor added the comment: > Didn't know that. Well if that's the case, then obviously there is no reason > to work specifically on this conversion. If people want to use Py_NewRef(), I suggest to do while modifying the code for another reason. But not propose PRs just to use

[issue42287] Use Py_NewRef & Py_XNewRef where applicable

the "end state" of having Py_NewRef() is desired, I think. It is more concise. It is less error prone because where you use it, you literally can't miss the "increment refcount" part when stealing a reference from another source. Py_INCREF has to come before/after stealing a

[issue42287] Use Py_NewRef & Py_XNewRef where applicable

STINNER Victor added the comment: > Following https://bugs.python.org/issue42262, I think it'd be nice to convert > existing C code to use the more concise Py_NewRef() and Py_XNewRef() where > possible. Increases readability and less bug prone. In general, we don't accept chan

[issue42287] Use Py_NewRef & Py_XNewRef where applicable

New submission from Yonatan Goldschmidt : Following https://bugs.python.org/issue42262, I think it'd be nice to convert existing C code to use the more concise Py_NewRef() and Py_XNewRef() where possible. Increases readability and less bug prone. Opening this new issue to track

[issue40592] `Shutil.which` incosistent with windows's `where`

miss-islington added the comment: New changeset c437fe39cf5318f27f3381a983fbf320f65064bc by Miss Skeleton (bot) in branch '3.9': [3.9] bpo-40592: shutil.which will not return None anymore if ; is the last char in PATHEXT (GH-20088) (GH-22912)

[issue40592] `Shutil.which` incosistent with windows's `where`

miss-islington added the comment: New changeset 8b4842b7a830299870067bba59f53529b13647a2 by Miss Skeleton (bot) in branch '3.8': [3.8] bpo-40592: shutil.which will not return None anymore if ; is the last char in PATHEXT (GH-20088) (GH-22913)

[issue40592] `Shutil.which` incosistent with windows's `where`

Steve Dower added the comment: Thanks for the contribution! Looking forward to your next one :) -- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.8, Python 3.9

[issue40592] `Shutil.which` incosistent with windows's `where`

Steve Dower added the comment: New changeset da6f098188c9825f10ae60db8987056b3a54c2e8 by Christopher Marchfelder in branch 'master': bpo-40592: shutil.which will not return None anymore if ; is the last char in PATHEXT (GH-20088)

[issue40592] `Shutil.which` incosistent with windows's `where`

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

[issue40592] `Shutil.which` incosistent with windows's `where`

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +21843 pull_request: https://github.com/python/cpython/pull/22912 ___ Python tracker

[issue40592] `Shutil.which` incosistent with windows's `where`

Christopher Marchfelder added the comment: @steve.dower Your advice did it, is fixed and green! :) Thank you again -- ___ Python tracker ___

[issue19438] Where is NoneType in Python 3?

Andrés Delfino added the comment: As per https://github.com/python/cpython/pull/22336 I believe this issue can be closed now. My PR is not relevant to the problem stated by OP, so I'm "unlinking" it. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue40592] `Shutil.which` incosistent with windows's `where`

Christopher Marchfelder added the comment: @steve.dower Added the changes in the PR - could you please re-check? Thank you! -- ___ Python tracker ___

[issue25912] Use __spec__.__name__ instead of __name__ in the docs where appropriate

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19438] Where is NoneType in Python 3?

Andrés Delfino added the comment: ammar2 found this mail mentioning the changes in that commit https://mail.python.org/pipermail/python-dev/2007-November/075386.html "I've removed the 'new' module from py3k and also removed a lot of types from the 'types' module in py3k. It only contains

[issue19438] Where is NoneType in Python 3?

Raymond Hettinger added the comment: Thanks for the link. It looks like NoneType got inadvertently caught up in the sweep of names that had direct synonyms. -- ___ Python tracker

[issue19438] Where is NoneType in Python 3?

Andrés Delfino added the comment: types.NoneType was removed here: https://github.com/python/cpython/commit/c9543e42330e5f339d6419eba6a8c5a61a39aeca#diff-0f021aec4e35b86a3160d44069dec997 The thing of adding NoneType to types that is somewhat unpleasing to me is that it's named exactly as the

[issue19438] Where is NoneType in Python 3?

Raymond Hettinger added the comment: I would support adding NoneType back to the types module. Am not sure why it was ever removed. It has a much reason to exists as types.FunctionType which is a clear, well-named short-cut for "type(lambda :None)". -- nosy: +rhettinger

[issue19438] Where is NoneType in Python 3?

Change by Andrés Delfino : -- keywords: +patch nosy: +adelfino nosy_count: 3.0 -> 4.0 pull_requests: +21235 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22161 ___ Python tracker

Re: Where read() is documented

Stefan Ram wrote: > Chris Green writes: > >I went to sys.stdin but it didn't really lead me easily to the read() > >method. All I actually wanted to know was what was the type of the > >return value of the read() method which is different in Python 2 and 3. > > |>>> import sys > |>>> >>>

Re: Where read() is documented

MRAB wrote: > On 2020-08-29 17:48, Chris Green wrote: > > Stefan Ram wrote: > >> Chris Green writes:I can't find the documentation for > >> >read(). It's not a built-in function and it's not documented with > >> >(for example) the file type object sys.stdin. > >> > >> |read()

Re: Silly question, where is read() documented?

s.stdin is of no particular type, but must at least have a .read method. > > > So where is it documented? :-) > > >>> import sys; sys.stdin > should give a hint. In the standard REPL, > > <_io.TextIOWrapper name='' mode='r' encoding='utf-8'> > > As o

Re: Silly question, where is read() documented?

method. So where is it documented? :-) >>> import sys; sys.stdin should give a hint. In the standard REPL, <_io.TextIOWrapper name='' mode='r' encoding='utf-8'> As others said, actually look in the io module doc. You might spend some time reading the doc to get an idea o

Re: Silly question, where is read() documented?

>Python read documentation) > >On 29/08/2020 17:18, Chris Green wrote: >>Well it sounds a silly question but I can't find the documentation for >>read(). It's not a built-in function and it's not documented with >>(for example) the file type object sys.stdi

Re: Where read() is documented

Chris Green writes: > Stefan Ram wrote: >> Chris Green writes:I can't find the documentation for >> >read(). It's not a built-in function and it's not documented with >> >(for example) the file type object sys.stdin. >> >> |read() (asyncio.StreamReader method), 894 >> |read()

Re: Where read() is documented

On 2020-08-29 17:48, Chris Green wrote: Stefan Ram wrote: Chris Green writes:I can't find the documentation for >read(). It's not a built-in function and it's not documented with >(for example) the file type object sys.stdin. |read() (asyncio.StreamReader method), 894 |read()

Re: Where read() is documented

Stefan Ram wrote: > Chris Green writes:I can't find the documentation for > >read(). It's not a built-in function and it's not documented with > >(for example) the file type object sys.stdin. > > |read() (asyncio.StreamReader method), 894 > |read() (chunk.Chunk method), 1385 > |read()

Re: Silly question, where is read() documented?

not a built-in function and it's not documented with (for example) the file type object sys.stdin. So where is it documented? :-) -- Ian Hobson -- This email has been checked for viruses by AVG. https://www.avg.com -- https://mail.python.org/mailman/listinfo/python-list

Silly question, where is read() documented?

Well it sounds a silly question but I can't find the documentation for read(). It's not a built-in function and it's not documented with (for example) the file type object sys.stdin. So where is it documented? :-) -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list

[issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not

Olivier Dony added the comment: Somehow the message identifiers in the code sample got messed up in previous comment, here's the actual code, for what it's worth ;-) https://gist.github.com/odony/0323eab303dad2077c1277076ecc3733 -- ___ Python

[issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not

Olivier Dony added the comment: Further, under Python 3.8 the issue is not fully solved, as other identification headers are still being folded in a non-RFC-conformant manner (see OP for RFC references). This was indicated on the original PR by the author:

[issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not

Olivier Dony added the comment: With regard to msg349895, is there any chance this fix could be considered for backport? I imagine you could view it as a new feature, but it seems to be the only official fix we have for the fact that Python 3 generates invalid SMTP messages. And that's not

[issue35975] Put back the ability to parse files where async/await aren't keywords

Guido van Rossum added the comment: Fixed again. Thanks Stefan for finding this! I apologize for the bug. -- stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue35975] Put back the ability to parse files where async/await aren't keywords

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

[issue35975] Put back the ability to parse files where async/await aren't keywords

Guido van Rossum added the comment: New changeset e653369e76d7da6bcbcf1f09a141f47fb77df6c3 by Guido van Rossum in branch '3.8': [3.8] bpo-35975: Only use cf_feature_version if PyCF_ONLY_AST in cf_flags (#21023)

[issue35975] Put back the ability to parse files where async/await aren't keywords

Guido van Rossum added the comment: New changeset 2a1ee1d970460047bd88da9638f8c1789431d9ab by Guido van Rossum in branch '3.9': [3.9] bpo-35975: Only use cf_feature_version if PyCF_ONLY_AST in cf_flags (#21022)

[issue35975] Put back the ability to parse files where async/await aren't keywords

Guido van Rossum added the comment: New changeset 9d197c7d48147a9ea2f7f7be917f35514a16524b by Guido van Rossum in branch 'master': bpo-35975: Only use cf_feature_version if PyCF_ONLY_AST in cf_flags (#21021) https://github.com/python/cpython/commit/9d197c7d48147a9ea2f7f7be917f35514a16524b

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

sorrow added the comment: >`iteritems()` I meant `iterdir()` of course. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

sorrow added the comment: Here's what I came up with: ```python class ZipPath(zipfile.Path): def __init__(self, root, at=""): super().__init__(root, at) if not at.startswith("/") and self.root.namelist()[0].startswith("/"): self.at = f"/{at}" def __repr__(self): return (

[issue35975] Put back the ability to parse files where async/await aren't keywords

Stefan Behnel added the comment: Feel free to use the patch in any way you like. -- ___ Python tracker ___ ___ Python-bugs-list

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

Jason R. Coombs added the comment: Yes, I generally agree with your assessment. Let me know if you have any questions about the implementation as you're exploring a solution. -- ___ Python tracker

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

Change by Jason R. Coombs : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue35975] Put back the ability to parse files where async/await aren't keywords

Guido van Rossum added the comment: Okay, I will add that diff (I'll probably add async def to the set of features tested). Do you mind if I just incorporate it in my diff? I could add an acknowledgment in the commit message. Otherwise you could send a separate PR. --

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

sorrow added the comment: >When the class is created? I mean the class instance -- ___ Python tracker ___ ___ Python-bugs-list

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

sorrow added the comment: >`Path` public AP. API of course -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

sorrow added the comment: >how common is this use-case I don't know about that. I just know that I have to make my program work with these files. Asking the clients to stop using this (presumably incorrect) format (or the program that makes it) is not an option. >It appears the file your

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

Jason R. Coombs added the comment: >>It seems you may have discovered a use-case that violates that expectation, a >>case where `/a.txt` is identical to `a.txt`. > The thing is: it's not. I think maybe you misunderstood. I mean that the zipfile you have seems to be t

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

Jason R. Coombs added the comment: I created [jaraco/zipp#56](https://github.com/jaraco/zipp/issues/56) to track the issue in the backport. -- ___ Python tracker ___

[issue35975] Put back the ability to parse files where async/await aren't keywords

Stefan Behnel added the comment: PRs look good to me. Here is a test that fails for me with the master branch and works with your fixes. It has a slightly odd place in the subinterpreter tests, but I would argue that it's not entirely misplaced there. You would want to know when

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

sorrow added the comment: >It seems you may have discovered a use-case that violates that expectation, a >case where `/a.txt` is identical to `a.txt`. The thing is: it's not. >Can you tell me more about your use-case and why zipp.Path/zipfile.Path should >support it? I rec

[issue35975] Put back the ability to parse files where async/await aren't keywords

Change by Guido van Rossum : -- pull_requests: +20195 pull_request: https://github.com/python/cpython/pull/21023 ___ Python tracker ___

[issue35975] Put back the ability to parse files where async/await aren't keywords

Change by Guido van Rossum : -- pull_requests: +20194 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/21022 ___ Python tracker ___

[issue35975] Put back the ability to parse files where async/await aren't keywords

Guido van Rossum added the comment: Hm, the backports have to be done manually, since the 3.8 parser and the 3.10 parser don't overlap, and 3.9 has both versions... -- ___ Python tracker

[issue35975] Put back the ability to parse files where async/await aren't keywords

Change by Guido van Rossum : -- status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35975] Put back the ability to parse files where async/await aren't keywords

Guido van Rossum added the comment: I'm fixing it -- can you verify? I have no easy way to test this. DO you think we should also add a note to the docs that this was broken in 3.8.0-3? -- ___ Python tracker

[issue35975] Put back the ability to parse files where async/await aren't keywords

Change by Guido van Rossum : -- pull_requests: +20193 pull_request: https://github.com/python/cpython/pull/21021 ___ Python tracker ___

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

that expectation, a case where `/a.txt` is identical to `a.txt`. My instinct is that `zipfile.Path` should support 99% of real-world use-cases and that other use-cases may not be supported or may require additional consideration (wrappers, subclasses) to support. Can you tell me more about your use

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

Change by Brett Cannon : -- nosy: +alanmcintyre, serhiy.storchaka, twouters ___ Python tracker ___ ___ Python-bugs-list mailing

[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

Change by Brett Cannon : -- nosy: +jaraco ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35975] Put back the ability to parse files where async/await aren't keywords

Stefan Behnel added the comment: I wasn't sure which is better – solve it or leave it. But it seems a) easy to adapt to on user side, and b) solvable in CPython in a way that allows code that wants to adapt to work across 3.8.x versions. Only code that does not get adapted would risk failure

[issue35975] Put back the ability to parse files where async/await aren't keywords

Guido van Rossum added the comment: But it's a bug, right? The intention for sure is that the cf_feature_version field is only used when the PyCF_ONLY_AST flags is set in cf_flags, per the docs you cite as [3]. Why wouldn't it be possible to fix that? -- status: closed -> open

[issue35975] Put back the ability to parse files where async/await aren't keywords

Stefan Behnel added the comment: I was made aware [1] that the addition of the "cf_feature_version" field broke the backwards compatibility of the "PyRun_StringFlags()" function [2]. Unlike what the docs of "PyCompilerFlags" [3] suggest, the new field is not ignored there but must now be

<    1   2   3   4   5   6   7   8   9   10   >