[issue40365] argparse: action "extend" with 1 parameter splits strings into characters

Jonathan Haigh added the comment: The situation for type=int and unspecified nargs or nargs="?" is also surprising: Python 3.8.3 (default, May 21 2020, 12:19:36) [GCC 9.2.1 20191008] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import argparse >>> p =

[issue40643] Improve doc-strings for datetime.strftime & strptime

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 3.0 -> 4.0 pull_requests: +19892 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/20677 ___ Python tracker

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

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

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

Pablo Galindo Salgado added the comment: New changeset f7ed4d4e83f5d9e85e244a1cbc460f26436ab24d by Shantanu in branch '3.8': bpo-40614: Respect feature version for f-string debug expressions (GH-20196) (GH-20466)

[issue16125] open accepts arbitrary mode strings as long as they contain U

Serhiy Storchaka added the comment: Python 2.7 is no longer supported. -- nosy: +serhiy.storchaka resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue22666] email.Header no encoding of unicode strings containing newlines

Serhiy Storchaka added the comment: Python 2.7 is no longer supported. -- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue23019] pyexpat.errors wrongly bound to message strings instead of message codes

Serhiy Storchaka added the comment: Python 2.7 is no longer supported. -- nosy: +serhiy.storchaka resolution: wont fix -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue9196] Improve docs for string interpolation "%s" re Unicode strings

Serhiy Storchaka added the comment: Python 2.7 is no longer supported. -- nosy: +serhiy.storchaka resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue20686] Confusing statement about unicode strings in tutorial introduction

Serhiy Storchaka added the comment: Python 2.7 is no longer supported. -- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue2481] locale.strxfrm does not work with Unicode strings

Change by Serhiy Storchaka : -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue40762] Writing bytes using CSV module results in b prefixed strings

Eric V. Smith added the comment: I've created issue40825 for adding a "strict" parameter. -- ___ Python tracker ___ ___

[issue40762] Writing bytes using CSV module results in b prefixed strings

Terry J. Reedy added the comment: I make 5 core developers who agree that csv should definitely *not* assume that bytes given to it represent encoded text, reverting to the confusion of Python 1 and 2. (And even it if did, it should not assume that the encoding of the given to it and the

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

Pablo Galindo Salgado added the comment: New changeset 9b83829e7d476acecc86d48978acc5813ec51e65 by Pablo Galindo in branch '3.9': [3.9] bpo-40614: Respect feature version for f-string debug expressions (GH-20196) (GH-20464)

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

Change by Shantanu : -- pull_requests: +19718 pull_request: https://github.com/python/cpython/pull/20466 ___ Python tracker ___ ___

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

Change by Pablo Galindo Salgado : -- pull_requests: +19716 pull_request: https://github.com/python/cpython/pull/20464 ___ Python tracker ___

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

Pablo Galindo Salgado added the comment: New changeset c116c94ff119485761460f1033cdee425bed0310 by Shantanu in branch 'master': bpo-40614: Respect feature version for f-string debug expressions (GH-20196) https://github.com/python/cpython/commit/c116c94ff119485761460f1033cdee425bed0310

[issue40762] Writing bytes using CSV module results in b prefixed strings

Skip Montanaro added the comment: I would also that tweaking Python to make this work with no change in Pandas would be a case of the tail wagging the dog. A big tail, but a tail nonetheless. -- ___ Python tracker

[issue40762] Writing bytes using CSV module results in b prefixed strings

Serhiy Storchaka added the comment: Since Pandas opens an output file it has control on what encoding is used. It is a Pandas' responsibility to decode bytes, or raise an exception, or just ignore the problem if it is pretty uncommon case. Pandas already have a complex code for formatting

[issue40762] Writing bytes using CSV module results in b prefixed strings

. Bytes aren't strings any longer. A huge effort was undertaken to clean up this aspect of Python's data model in the move to Python 3. Conflating bytes and strings at this point (no matter which way you try to accomplish that conflation) makes no sense to me. The current behavior should

[issue40762] Writing bytes using CSV module results in b prefixed strings

Eric V. Smith added the comment: > Short of outright banning the use of bytes (raise a TypeError), I think > the current behaviour is least-worst. I agree. I'd like to see the TypeError raised for everything that's not a string or number (since the docs say that's what's accepted), but at

[issue40762] Writing bytes using CSV module results in b prefixed strings

Steven D'Aprano added the comment: On further thought, no, I don't think it would be a reasonable feature. User opens the CSV file, probably using the default encoding (UTF-8?) but potentially in anything. They collect some data as bytes. Those bytes could be from any unknown encoding. When

[issue40762] Writing bytes using CSV module results in b prefixed strings

Steven D'Aprano added the comment: The csv file object knows the encoding it was opened with, I think? If so, we could add an enhancement that bytes objects are first decoded to str using the same encoding the file was opened with. That seems like a reasonable new feature to me. Everything

[issue40762] Writing bytes using CSV module results in b prefixed strings

Serhiy Storchaka added the comment: It would be confusing. There would be the encoding argument for open() to encode strings to bytes and the encoding argument for csv.writer() to decode bytes to strings. The latter will be ignored in all normal cases (for strings and numbers

[issue40762] Writing bytes using CSV module results in b prefixed strings

Rémi Lapeyre added the comment: I don't think this would be accepted but I think you could try to propose that on the python-ideas mailing list to get some feedback on your proposal. -- nosy: +skip.montanaro ___ Python tracker

[issue40762] Writing bytes using CSV module results in b prefixed strings

/csv.html#csv.writer) should look for my proposed change: -.. function:: writer(csvfile, dialect='excel', **fmtparams) +.. function:: writer(csvfile, encoding=None, dialect='excel', **fmtparams) Return a writer object responsible for converting the user's data into delimited strings

[issue40762] Writing bytes using CSV module results in b prefixed strings

: print(out.read()) ...: "Point(x=1, y=2)","Valar(name='Melkor', age=2900)",b'\x95g6\xa2' Here another would find three fields, all strings: "Point(x=1, y=2)", "Valar(name=

[issue40762] Writing bytes using CSV module results in b prefixed strings

Sidhant Bansal added the comment: Hi Remi, Currently a code like this: ``` with open("abc.csv", "w", encoding='utf-8') as f: data = [b'\x41'] w = csv.writer(f) w.writerow(data) with open("abc.csv", "r") as f: rows = csv.reader(f) for row in rows: print(row[0]) #

[issue40762] Writing bytes using CSV module results in b prefixed strings

Rémi Lapeyre added the comment: > As an example, if I write character "A" as a byte, i.e b'A' in a csv file But you can't write b'A' in a csv file, what you can't do is write `b'a'.decode()` or `b'a'.decode('latin1')` or `b'a'.decode('whatever')` but the string representation of a byte

[issue40762] Writing bytes using CSV module results in b prefixed strings

Sidhant Bansal added the comment: Yes, I do recognise that the current doc states that csv only supports strings and numbers. However the use case here is motivated when the user wants to write bytes and numbers/strings mixed to a CSV file. Currently providing bytes to write to a CSV

[issue40762] Writing bytes using CSV module results in b prefixed strings

Serhiy Storchaka added the comment: According to the documentation (https://docs.python.org/3/library/csv.html#writer-objects): """ A row must be an iterable of strings or numbers for Writer objects and a dictionary mapping fieldnames to strings or numbers (by passing th

[issue40762] Writing bytes using CSV module results in b prefixed strings

Change by Sidhant Bansal : -- keywords: +patch pull_requests: +19634 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20371 ___ Python tracker ___

[issue40762] Writing bytes using CSV module results in b prefixed strings

Sidhant Bansal added the comment: The following code ``` import csv with open("abc.csv", "w") as f: data = [b'\xc2a9', b'\xc2a9'] w = csv.writer(f) w.writerow(data) ``` writes "b'\xc2a9',b'\xc2a9'" in "abc.csv", i.e the b-prefixed byte string instead of the actual bytes. Although

[issue40762] Writing bytes using CSV module results in b prefixed strings

es: 369848 nosy: sidhant priority: normal severity: normal status: open title: Writing bytes using CSV module results in b prefixed strings type: behavior versions: Python 3.10 ___ P

Re: Strings: double versus single quotes

On 24/05/20 8:41 PM, Frank Millman wrote: On 2020-05-24 9:58 AM, DL Neil via Python-list wrote: On 24/05/20 5:43 PM, Frank Millman wrote: On 2020-05-23 9:45 PM, DL Neil via Python-list wrote: My habit with SQL queries is to separate them from other code, cf the usual illustration of having

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Andy Lester added the comment: I'd also like to suggest that the question not be "most efficient" but "fastest". I don't think it should treat "efficient" and "fast" as synonyms. "Efficient" can mean things other than execution speed, such as memory usage, or programmer time. Are there

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: -19625 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: +19625 pull_request: https://github.com/python/cpython/pull/20360 ___ Python tracker ___

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- pull_requests: -19624 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40344] Programming FAQ about "What is the most efficient way to concatenate many strings together?" -- Improving the example

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19624 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20360 ___ Python tracker ___

Re: Strings: double versus single quotes

Çok fazla mail geliyor abonelik iptal için ne yapmam gerekiyor Android için Outlook<https://aka.ms/ghei36>'u edinin From: Python-list on behalf of Frank Millman Sent: Sunday, May 24, 2020 11:41:36 AM To: python-list@python.org Subject: Re: Strings:

Re: Strings: double versus single quotes

On 2020-05-24 9:58 AM, DL Neil via Python-list wrote: On 24/05/20 5:43 PM, Frank Millman wrote: On 2020-05-23 9:45 PM, DL Neil via Python-list wrote: My habit with SQL queries is to separate them from other code, cf the usual illustration of having them 'buried' within the code, immediately

Re: Strings: double versus single quotes

On 24/05/20 5:43 PM, Frank Millman wrote: On 2020-05-23 9:45 PM, DL Neil via Python-list wrote: My habit with SQL queries is to separate them from other code, cf the usual illustration of having them 'buried' within the code, immediately before, or even part of, the query call. I like

Re: Strings: double versus single quotes

On 2020-05-23 9:45 PM, DL Neil via Python-list wrote: My habit with SQL queries is to separate them from other code, cf the usual illustration of having them 'buried' within the code, immediately before, or even part of, the query call. I like that idea, as I find that I am embedding more

Re: Strings: double versus single quotes

Kind Regards, Abdur-Rahmaan Janhangeer compileralchemy | blog github Mauritius On Sun, May 24, 2020 at 12:03 AM DL Neil via Python-list < python-list@python.org> wrote: > > I'm highly

Re: Strings: double versus single quotes

rophes) > > around the entire thing simplifies it all... (except for a need to > > separate the four ending quotes) > > Exactly, I also would opt for triple quotes in this case. > > > > > >>> """You said "No it doesn't" """ >

Re: Strings: double versus single quotes

opt for triple quotes in this case. > > >>> """You said "No it doesn't" """ > 'You said "No it doesn\'t" ' > >>> '''You said "No it doesn't"''' > 'You said "No it doesn\'t"' > >>&g

Re: Strings: double versus single quotes

This seems to be a life long debate... On Sun, 24 May, 2020, 5:25 am Tim Chase, wrote: > On 2020-05-23 14:46, Dennis Lee Bieber wrote: > > On Sat, 23 May 2020 11:03:09 -0500, Tim Chase > > >But when a string contains both, it biases towards single quotes: > > > > > > >>> "You said \"No it

Re: Strings: double versus single quotes

On 2020-05-23 14:46, Dennis Lee Bieber wrote: > On Sat, 23 May 2020 11:03:09 -0500, Tim Chase > >But when a string contains both, it biases towards single quotes: > > > > >>> "You said \"No it doesn't\"" > > 'You said "No it doesn\'t"' > > This is where using triple quotes (or

Re: Strings: double versus single quotes

to do with Emacs's Python mode behavior. Emacs wouldn't know what to do with spaces in the string, but knows where to put string literals within the open parens. I'm pretty sure I was doing this before triple quoted strings existed. Thankfully, I don't need to mess around with SQL anymore. :-) A. do

Re: Strings: double versus single quotes

with Emacs's Python mode behavior. Emacs wouldn't know what to do with spaces in the string, but knows where to put string literals within the open parens. I'm pretty sure I was doing this before triple quoted strings existed. Thankfully, I don't need to mess around with SQL anymore. :-) Skip > -- https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

Skip Montanaro schreef op 23/05/2020 om 13:03: I also agree about SQL. I found that something like this: stmt = ( """select foo from bar""" """ where a = 'bag'""" """and c = 'dog'""" ) worked pretty well, served to both satisfy my brain's desire for semantic indentation

Re: Strings: double versus single quotes

me } is top of the class' Never learning a language which distinguishes single character literals from strings, eg the C examples quoted earlier, such thoughts/distinctions don't 'exist'. (which makes me wonder why code reviews have never queried the point, or registered that I might seem to b

Re: Strings: double versus single quotes

ing delimiters. The older (and more professional?) RDBMS accept either/both as variable delimiters, per Python strings. My habit with SQL queries is to separate them from other code, cf the usual illustration of having them 'buried' within the code, immediately before, or even part of, the query

Re: Strings: double versus single quotes

Nice one, Was requoting: <>> "hello" 'hello'>> from R Hettinger Kind Regards, Abdur-Rahmaan Janhangeer https://www.github.com/Abdur-RahmaanJ Mauritius sent from gmail client on Android, that's why the signature is so ugly. -- https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

On 2020-05-24 01:40, Chris Angelico wrote: > On Sat, May 23, 2020 at 10:52 PM Abdur-Rahmaan Janhangeer > wrote: > > > > The interpreter prefers single-quotes > > > > >>> "single or double" > > 'single or double' > > > >>> 'not all that strongly, it doesn\'t' > "not all that strongly, it

Re: Strings: double versus single quotes

On Sat, May 23, 2020 at 10:52 PM Abdur-Rahmaan Janhangeer wrote: > > The interpreter prefers single-quotes > > >>> "single or double" > 'single or double' > >>> 'not all that strongly, it doesn\'t' "not all that strongly, it doesn't" ChrisA --

Re: Strings: double versus single quotes

com/raymondh/status/1259209765072154624?s=20 Guess a personal choice thing ~ Kind Regards, Abdur-Rahmaan Janhangeer Mauritius On Tue, May 19, 2020 at 10:20 PM Manfred Lotz wrote: > Hi there, > I am asking myself if I should preferably use single or double quotes > for strings? > > If I

Re: Strings: double versus single quotes

On 22/05/2020 20:57, Manfred Lotz wrote: I also believe that transferring habits from C, Rust or whatever to Python doesn't make much sense as Python does not distinguish between a character and string from a type perspective. From a logical perspective, you are correct. From the point of

Re: Strings: double versus single quotes

> Nothing strong. I tend to use double quotes because I have a > background in C (where double quotes are for strings, single quotes > for characters), and double quotes are the recommendation for > docstrings (see PEP 258). If you tend to work a lot with SQL, you > might prefer sin

Re: Strings: double versus single quotes

On Sat, 23 May 2020 09:36:13 +1200 DL Neil wrote: > >>> I am asking myself if I should preferably use single or double > >>> quotes for strings? > ... > > > I agree to the following: > > > > 1. Consistency is important. > > 2. Sin

[issue38693] Use f-strings instead of str.format within importlib

Cheryl Sabella added the comment: Did you want this one to land in 3.9? -- nosy: +cheryl.sabella ___ Python tracker ___ ___

Re: Strings: double versus single quotes

I am asking myself if I should preferably use single or double quotes for strings? ... I agree to the following: 1. Consistency is important. 2. Single quotes are less noisy. 3. Triple double quotes are to be preferred over triple single quotes. ... Of course, this is my subjective result

Re: Strings: double versus single quotes

On Tue, 19 May 2020 13:36:54 -0500 Tim Chase wrote: > On 2020-05-19 20:10, Manfred Lotz wrote: > > Hi there, > > I am asking myself if I should preferably use single or double > > quotes for strings? > > I'd say your consistency matters more than which one you choos

Re: Strings: double versus single quotes

I love and use only singel quotes. I think that looks clean... Nothing else. Souvik flutter dev On Tue, May 19, 2020, 11:50 PM Manfred Lotz wrote: > Hi there, > I am asking myself if I should preferably use single or double quotes > for strings? > > If I need a single quote in a

Re: Strings: double versus single quotes

On 5/19/2020 2:10 PM, Manfred Lotz wrote: Hi there, I am asking myself if I should preferably use single or double quotes for strings? If I need a single quote in a string I would use double quotes for the whole string and vice versa. For f-strings I mostly see double quotes but single quotes

Re: Strings: double versus single quotes

On 19/05/2020 19:10, Manfred Lotz wrote: > Hi there, > I am asking myself if I should preferably use single or double quotes > for strings? Personally laziness wins every time. Single quotes only require one finger from the home position using my right hand, double quotes require two

Re: Strings: double versus single quotes

On 19May2020 22:04, Manfred Lotz wrote: On Tue, 19 May 2020 13:36:54 -0500 Tim Chase wrote: On 2020-05-19 20:10, Manfred Lotz wrote: > I am asking myself if I should preferably use single or double > quotes for strings? I'd say your consistency matters more than which one you

Re: Strings: double versus single quotes

On Tue, 19 May 2020 13:36:54 -0500 Tim Chase wrote: > On 2020-05-19 20:10, Manfred Lotz wrote: > > Hi there, > > I am asking myself if I should preferably use single or double > > quotes for strings? > > I'd say your consistency matters more than which one

Re: Strings: double versus single quotes

On 05/19/2020 11:40 AM, Joel Goldstick wrote: I thought triple quotes are for docstrings? It's the recommendation, but double and single quotes work just fine, too -- at least for docstrings that fit an one line. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

On Wed, May 20, 2020 at 4:42 AM Joel Goldstick wrote: > > On Tue, May 19, 2020 at 2:27 PM Chris Angelico wrote: > > > > On Wed, May 20, 2020 at 4:21 AM Manfred Lotz wrote: > > > > > > Hi there, > > > I am asking myself if I should preferably

Re: Strings: double versus single quotes

On 2020-05-19 20:10, Manfred Lotz wrote: > Hi there, > I am asking myself if I should preferably use single or double > quotes for strings? I'd say your consistency matters more than which one you choose. According to a recent observation by Raymond H. """ Over tim

Re: Strings: double versus single quotes

On 20/05/20 6:26 AM, Chris Angelico wrote: On Wed, May 20, 2020 at 4:21 AM Manfred Lotz wrote: Hi there, I am asking myself if I should preferably use single or double quotes for strings? If I need a single quote in a string I would use double quotes for the whole string and vice versa

Re: Strings: double versus single quotes

On Tue, May 19, 2020 at 2:27 PM Chris Angelico wrote: > > On Wed, May 20, 2020 at 4:21 AM Manfred Lotz wrote: > > > > Hi there, > > I am asking myself if I should preferably use single or double quotes > > for strings? > > > > If I need a single q

Re: Strings: double versus single quotes

On Wed, May 20, 2020 at 4:21 AM Manfred Lotz wrote: > > Hi there, > I am asking myself if I should preferably use single or double quotes > for strings? > > If I need a single quote in a string I would use double quotes for the > whole string and vice versa. For f-string

Strings: double versus single quotes

Hi there, I am asking myself if I should preferably use single or double quotes for strings? If I need a single quote in a string I would use double quotes for the whole string and vice versa. For f-strings I mostly see double quotes but single quotes would work as well I think

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

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

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

Change by Shantanu : -- keywords: +patch pull_requests: +19496 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20196 ___ Python tracker ___

[issue37496] Support annotations in signature strings.

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40643] Improve doc-strings for datetime.strftime & strptime

Edison Abahurire added the comment: Oh! I realized that statement is there because the strftime method used is inherited from the date class. -- ___ Python tracker ___

[issue40643] Improve doc-strings for datetime.strftime & strptime

Edison Abahurire added the comment: Hi, An enquiry here: On the web documentation of strftime (https://docs.python.org/3/library/datetime.html?highlight=strftime#datetime.time.strftime), What does this mean? "Format codes referring to hours, minutes or seconds will see 0 values."

[issue40643] Improve doc-strings for datetime.strftime & strptime

Edison Abahurire added the comment: Thanks for the review @p-ganssle. I'll request that you assign it to me, counting on your guidance while changing it in the C implementation. -- ___ Python tracker

[issue40643] Improve doc-strings for datetime.strftime & strptime

Paul Ganssle added the comment: I agree, this can be improved (particularly the first one). I believe we'll need to change it in the C implementation as well as the pure python version. That said, the most useful thing for users would be a full formatting reference, which is too much to put

[issue37496] Support annotations in signature strings.

Eric Wieser added the comment: This seems somewhat related to https://bugs.python.org/issue31939 -- nosy: +Eric Wieser ___ Python tracker ___

[issue40643] Improve doc-strings for datetime.strftime & strptime

string (like time.strptime()).' I feel like both could use a better explanation for users who will access them using >>> help(datetime.strftime) and users using IDEs that provide doc-strings on-hover over a function. -- messages: 369040 nosy: edison.abahurire, nanjekyejoannah pri

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

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

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

STINNER Victor added the comment: New changeset 3d17c045b4c3d09b72bbd95ed78af1ae6f0d98d2 by Victor Stinner in branch 'master': bpo-40521: Add PyInterpreterState.unicode (GH-20081) https://github.com/python/cpython/commit/3d17c045b4c3d09b72bbd95ed78af1ae6f0d98d2 --

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

STINNER Victor added the comment: I wrote a draft PR to make interned strings per-interpreter. It does crash because it requires to make method cache and _PyUnicode_FromId() (bpo-39465) compatible with subinterpreters. -- ___ Python tracker

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

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

[issue40521] Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter

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

[issue40614] ast.parse doesn't respect feature_version for debug f-strings

nja priority: normal severity: normal status: open title: ast.parse doesn't respect feature_version for debug f-strings type: behavior ___ Python tracker <https://bugs.python.org/issue40614> ___ __

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

STINNER Victor added the comment: Thanks for the fix Serhiy! -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

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

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

Serhiy Storchaka added the comment: New changeset 5650e76f63a6f4ec55d00ec13f143d84a2efee39 by Serhiy Storchaka in branch 'master': bpo-40596: Fix str.isidentifier() for non-canonicalized strings containing non-BMP characters on Windows. (GH-20053) https://github.com/python/cpython/commit

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

Change by Serhiy Storchaka : -- pull_requests: +19362 pull_request: https://github.com/python/cpython/pull/20053 ___ Python tracker ___

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

Serhiy Storchaka added the comment: I am not sure that changes in issue39500 was correct. It is easier to catch a bug if crash consistently when you pass a non-canonicalized strings then if silently return a wrong result for specific input on particular platform. Alternatively, you could

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

STINNER Victor added the comment: My previous change on this function: commit f3e7ea5b8c220cd63101e419d529c8563f9c6115 Author: Victor Stinner Date: Tue Feb 11 14:29:33 2020 +0100 bpo-39500: Document PyUnicode_IsIdentifier() function (GH-18397) PyUnicode_IsIdentifier() does

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

STINNER Victor added the comment: It's maybe time to speed up the deprecation of the legacy C API using Py_UNICODE... -- ___ Python tracker ___

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +19345 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20035 ___ Python tracker

[issue40596] str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows

terpreter Core messages: 368637 nosy: serhiy.storchaka, vstinner priority: normal severity: normal status: open title: str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows type: behavior versions: Python 3.9 ___ Python tracker

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